软件缺陷数据能够告诉你什么?今天,老大把我喊到办公室叮嘱我,“提测之后每天都要关注项目里的 bug,知道吧?”我说,“我知道,我每天肯定会及时跟进 Open Bug 的修复进度和 Fixed

xiaoxiao2021-02-28  32

软件缺陷数据能够告诉你什么?

今天,老大把我喊到办公室叮嘱我,“提测之后每天都要关注项目里的 bug,知道吧?”

我说,“我知道,我每天肯定会及时跟进 Open Bug 的修复进度和 Fixed Bug 的验证进度的。”

他说,“不仅仅是这两类的进度,从 bug 数据里能获取到的项目信息还有很多,我跟你说说,你自己记一下,然后再好好想想。”

根据每个需求模块待修复缺陷和待验证缺陷的数量变化,可以大致了解每个需求的测试进展;根据缺陷的分布模块,可以分析出问题多发的模块,以此来调整测试策略;根据每个人的有效缺陷数量,来观察工作量的饱和度;根据截止到某个时间点的待修复缺陷数量,来判断截止当下的产品质量;根据回归性缺陷的数量和被多次激活的缺陷数量,来判断开发的代码质量,从而调整测试策略;如果 Fixed/已修复 的缺陷数量过高,就说明测试工程师没有及时地做验证,那就需要关注一下某个测试工程师的工作状态了,或者看下测试流程是不是有问题。如果 Deferred/已推迟的缺陷数量过高,就需要检查一下当前项目的计划,是否在人力储备和相关资源储备上有不足之处,导致无法在当下解决。如果 OnHold/已挂起的缺陷数量过高,就需要安排相关的技术攻坚人员,去预研一下能否解决一些技术限制难题。如果 Designed/设计的缺陷数量过高,就说明需求评审做的不够好,或者需求文档还不够细,导致很多开发和测试在认知上不一致的问题;如果 CannotDuplicate/不能复现、NeedMoreInfo/需要更多信息和 NotABug/不是缺陷的数量过高,就说明缺陷报告的质量不高,需要对测试工程师做一些注意事项和执行层面的培训;

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

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

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

任何类型的缺陷都只能被测试工程师关闭。变更缺陷的优先级和严重级别需要经过产品经理或项目经理的确认,并由测试工程师修改。将缺陷改为 OnHold 状态,需要开发负责人或开发经理才能决定。
转载请注明原文地址: https://www.6miu.com/read-1950066.html

最新回复(0)