文/秋之川
这是《落叶》文集里第 347 片落叶，希望你能喜欢，不为别的，只为这份坚持。
【提问】
在项目管理中，是不是所有状态的 Bug 都有用？
【旧识】
原来在项目里，我每天都会关注 bug 数据，但也仅限于每天待修复的缺陷（New Bug） 和待验证的缺陷（Fixed Bug），通过这两类数据，我可以跟踪观察到以下几点：
- 根据每个需求模块待修复缺陷和待验证缺陷的数量变化，可以大致了解每个需求的测试进展；
- 根据待修复缺陷的模块分布，可以分析出问题多发模块，基于此来调整测试策略；
- 根据每个人的有效缺陷数量，来观察工作的饱和度；
- 根据截止到某个时间点的待修复缺陷数量，来判断当下的产品质量；
- 根据回归性缺陷的数量和被多次激活的缺陷数量，来判断开发的代码质量，从而调整测试策略；
【新知】
随着在项目里所处位置的变化，原来只关注测试和产品质量，后来慢慢地开始关注测试团队和过程质量，所以对各种状态缺陷的数据有了不一样的认识。
- 如果 Fixed/已修复 的缺陷数量过高，就说明测试工程师没有及时地做验证，那就需要关注一下某个测试工程师的工作状态了，或者看下测试流程是不是有问题。
- 如果 Deferred/已推迟的缺陷数量过高，就需要检查一下当前项目的计划，是否在人力储备和相关资源储备上有不足之处，导致无法在当下解决。
- 如果 OnHold/已挂起的缺陷数量过高，就需要安排相关的技术攻坚人员，去预研一下能否解决一些技术限制难题。
- 如果 Designed/设计的缺陷数量过高，就说明需求评审做的不够好，或者需求文档还不够细，导致很多开发和测试在认知上不一致的问题；
- 如果 CannotDuplicate/不能复现、NeedMoreInfo/需要更多信息和 NotABug/不是缺陷的数量过高，就说明缺陷报告的质量不高，需要对测试工程师做一些注意事项和执行层面的培训；
除了缺陷的不同状态之外，我们还需要关注缺陷在某些状态上的停留时长，比如：
- 高优先级和严重的 Open/待修复的缺陷，如果停留时间超过2天，就需要过问一下 fix 进度了，是不是有技术难点需要支援，还是别的原因，导致 fix 延迟。
- Fixed/已修复的缺陷如果停留时间过长，就需要过问一下，一直不能验证的原因是什么，有什么 block issue 吗？还是任务安排有问题。
最后，我们还需要明确缺陷状态的变更规则和责任人，比如：
- 任何类型的缺陷都只能被测试工程师关闭。
- 变更缺陷的优先级和严重级别需要经过产品经理或项目经理的确认，并由测试工程师修改。
- 将缺陷改为 OnHold 状态，需要开发负责人或开发经理才能决定。
作者简介：14 年测试 + 11 年项目管理 + 11 年团队管理 = 一个测试老兵
