在任何软件生命周期中，软件缺陷的出现几乎是不可避免的。建立一套有效的缺陷管理流程的目的是为了减少软件缺陷出现的几率，并且大幅度降低由于软件缺陷带来的负面影响。对于缺陷管理流程的投资，可以大幅度的降低由于返工/修复缺陷导致的人力，财力和时间浪费，同时提升用户的体验或者更多用户留存与产品口碑，并且可以保障产品更准时的交付。

在正式开始谈论产品缺陷管理流程建设之前，我们首先介绍下一些基本概念：

软件Bug和缺陷有什么区别？

什么是Bug?

Bug最初是在软件行业的计算机用语，是指由于错误编码导致的结果。

缺陷是什么?

缺陷的英文：Defect，缺陷是指不符合最初定义的业务需求，其覆盖范围高于Bug,除了错误编码外其他导致不符合最初定义的业务需求问题都属于缺陷范畴。

这两个术语Bug和Defect在英文中有非常细微的区别，但在行业中都是需要修复的错误，因此一些测试团队并不对这两个词语做细分。

当测试人员执行测试用例时，他可能会遇到与预期结果不一致的测试结果。

测试结果中的这种不一致被称为软件缺陷。这些缺陷在不同的团队中有不同的称呼，如错误，缺陷，Bug，问题等。

缺陷报告应该包括的信息：

当向开发人员反馈缺陷时，您的缺陷报告应该包含以下信息：

• 缺陷ID：缺陷的唯一标识号
• 缺陷描述：详细描述缺陷，包括发现缺陷的模块的信息。
• 软件版本：发现缺陷的软件程序的版本号。
• 复现步骤：详细的步骤，以及开发人员可以复现缺陷的屏幕截图。
• 缺陷提交日期：提交缺陷的日期
• 相关文档：通过相关的需求、设计、架构文档并对比，能够让人更容易理解，例如产品需求文档，相关产品原型或者用例文档等
• 提交人：由谁发现的缺陷。
• 缺陷的状态：缺陷当前的修复状态，我们稍后将详细介绍
• 修复人：修复缺陷的开发人员
• 缺陷关闭日期：缺陷被关闭/解决的日期
• 缺陷等级：描述缺陷对软件程序的影响的严重程度
• 缺陷优先级：优先级与缺陷修复的紧迫性相关。严重程度优先级可以是高/中/低，这取决于缺陷修复对应用影响的紧急程度

如果没有有效的缺陷管理流程会怎么样？

其实无论团队是否有花费时间和精力创建缺陷管理流程，缺陷管理流程总归是会存在的，但这一流程并不一定有效，我见过一些团队并没有一套有效的流程，而是通过口头或者邮件的方式进行着缺陷管理，这些方式可能会导致许多问题，下面我举一个简单的实例：

如果像上述的情况一样通过口头或者简单邮件沟通进行缺陷管理，很快事情会变得十分复杂，如果你作为产品经理，想要控制和有效管理缺陷问题，您需要了解一个缺陷的生命周期以及如何建立一套有效的缺陷管理流程。

缺陷管理的流程

为了能够有效的管理缺陷问题，你需要建设一套有效的缺陷管理流程，以避免上述示例中这种无序混乱的状态。 本部分将指导您如何将缺陷管理过程应用于项目中。管理缺陷可以分为以下步骤：

（1）发现缺陷：新建

一般缺陷问题有测试团队根据用例步骤进行测试，如果不能正常通过用例则转为缺陷问题。但是很多团队并没有专门的测试团队，因此创建问题缺陷的可能来自不同团队或者来自外部用户提交的反馈信息。这些缺陷反馈其缺陷状态应该为“新建”。

（2）开启

当QA测试团队或者其他相同职务的团队确认了反馈的缺陷问题后，比如可以复现，则确认反馈是一个缺陷，并等待分配给开发团队。

（3）分配

当测试团队确认缺陷后，应该将问题分配给开发团队进行缺陷定位和修复工作。

（4）拒绝

如果开发团队认为提交上来的缺陷并不是真正的缺陷，比如由于缓存，网络导致的部分文件加载失败导致的问题等，应将缺陷状态标记为“拒绝”并指派回测试团队。测试团队需要重新测试或者提供更多的缺陷信息。

（5）重复

如果开发团队收到的缺陷是重复的，或者与其他正在进行中的缺陷问题相似，应将缺陷状态修改为“重复”

（6）延期

部分不紧急的缺陷问题，可能会随着日后的产品迭代中进行修复。对于这类缺陷应当标注为“延期”。在这里要注意，并不是所有缺陷都需要立即进行修复。每个缺陷问题在严重程度，影响范围均有不同，因此优先修复的等级也不同。我会在下一篇文章中单独讲解制定优先级别的方法。

（7）等待测试

当开发团队修复缺陷后，应将缺陷状态标记为等待测试并由测试团队进行测试。

（8）关闭

在测试通过后，缺陷状态修改为“关闭”或者完成。

（9）重新开启

如果缺陷修复后并没有通过测试，应标记为重新开启，并重新启用分配流程。

重要的缺陷KPI指标

管理学大师德鲁克说过：你无法管理那些你无法衡量的事情。 缺陷管理也是一样，你需要有一些可供参考的指标，以便衡量管理效果. 您可以考虑使用以下两个简单的指标来衡量您测试团队的执行效果：

• 缺陷拒绝率 (Defect Rejection Ratio, 简称DRR)：（拒绝的缺陷数量/总测试团队报告的缺陷数量）*100%
• 缺陷遗漏率 (Defect Leakage Ratio, 简称DLR)：（遗漏的缺陷数量/总的缺陷数量）*100%

下面我举一个简单的实例：

Bugout的测试团队在Bugout的一次产品升级测试中，发现了50个Bug并反馈给开发团队，其中5个经过核实并不是Bug。新版本上线后，收到与本次升级相关的问题反馈10条并确认均为Bug。

缺陷拒绝率（DRR)=5/50=10%

缺陷遗漏率（DLR)=10/(50-5+10)=18.18%

DRR和DLR的值越小，测试执行的质量越好。 什么是可接受的比例范围？ 可以在项目目标中定义和接受此范围，也可以参考类似项目的指标。

相关阅读

从0到1创建高效的产品缺陷管理流程（2）：如何设置合理的Bug处理优先级

从0到1创建高效的产品缺陷管理流程（3）：如果选择一款Bug管理工具？

#专栏作家#

陈迪，人人都是产品经理专栏作家。Testin云测SaaS运营总监，Bugout缺陷管理产品运营负责人，增长黑客，多年国内和海外互联网公司运营经验，专注于SaaS和B2B企业服务行业。

本文原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 Pixabay，基于 CC0 协议