大叔大婶带你走一条接地气的测试进阶之路

【周问日答】(9)在项目管理中,是不是所有状态的 Bug 都有用?

上一篇 / 下一篇  2017-10-31 14:48:24 / 个人分类:自问自省

【提问】

项目管理中,是不是所有状态的 Bug 都有用?

【旧识】

原来在项目里,我每天都会关注 bug 数据,但也仅限于每天待修复的缺陷(New Bug) 和待验证的缺陷(Fixed Bug),通过这两类数据,我可以跟踪观察到以下几点:

  1. 根据每个需求模块待修复缺陷和待验证缺陷的数量变化,可以大致了解每个需求的测试进展;
  2. 根据待修复缺陷的模块分布,可以分析出问题多发模块,基于此来调整测试策略;
  3. 根据每个人的有效缺陷数量,来观察工作的饱和度;
  4. 根据截止到某个时间点的待修复缺陷数量,来判断当下的产品质量;
  5. 根据回归性缺陷的数量和被多次激活的缺陷数量,来判断开发的代码质量,从而调整测试策略;

【新知】

随着在项目里所处位置的变化,原来只关注测试和产品质量,后来慢慢地开始关注测试团队和过程质量,所以对各种状态缺陷的数据有了不一样的认识。

  1. 如果 Fixed/已修复 的缺陷数量过高,就说明测试工程师没有及时地做验证,那就需要关注一下某个测试工程师的工作状态了,或者看下测试流程是不是有问题。
  2. 如果 Deferred/已推迟的缺陷数量过高,就需要检查一下当前项目的计划,是否在人力储备和相关资源储备上有不足之处,导致无法在当下解决。
  3. 如果 OnHold/已挂起的缺陷数量过高,就需要安排相关的技术攻坚人员,去预研一下能否解决一些技术限制难题。
  4. 如果 Designed/设计的缺陷数量过高,就说明需求评审做的不够好,或者需求文档还不够细,导致很多开发和测试在认知上不一致的问题;
  5. 如果 CannotDuplicate/不能复现、NeedMoreInfo/需要更多信息和 NotABug/不是缺陷的数量过高,就说明缺陷报告的质量不高,需要对测试工程师做一些注意事项和执行层面的培训;

除了缺陷的不同状态之外,我们还需要关注缺陷在某些状态上的停留时长,比如:

  1. 高优先级和严重的 Open/待修复的缺陷,如果停留时间超过2天,就需要过问一下 fix 进度了,是不是有技术难点需要支援,还是别的原因,导致 fix 延迟。
  2. Fixed/已修复的缺陷如果停留时间过长,就需要过问一下,一直不能验证的原因是什么,有什么 block issue 吗?还是任务安排有问题。

最后,我们还需要明确缺陷状态的变更规则和责任人,比如:

  1. 任何类型的缺陷都只能被测试工程师关闭。
  2. 变更缺陷的优先级和严重级别需要经过产品经理或项目经理的确认,并由测试工程师修改。
  3. 将缺陷改为 OnHold 状态,需要开发负责人或开发经理才能决定。

TAG: 测试知识 测试问答

 

评分:0

我来说两句

日历

« 2024-03-18  
     12
3456789
10111213141516
17181920212223
24252627282930
31      

数据统计

  • 访问量: 71339
  • 日志数: 82
  • 建立时间: 2017-09-03
  • 更新时间: 2018-01-11

RSS订阅

Open Toolbar