在软件生命周期中，软件缺陷的产生无可避免，但是我们可以利用规范的产品缺陷管理流程，最大限度地降低缺陷出现的几率，减少由于标准流程缺失造成的人力、财力和时间的浪费。同时，做好缺陷管理也能有效保障产品最终的质量交付，提升客户的满意度。
缺陷是什么
软件缺陷常常被称为 Bug，Bug 是指由于程序错误而导致的故障。事实上，软件缺陷的覆盖范围要高于 Bug，除了程序错误之外，其他任何导致软件不符合最初需求定义的问题都属于缺陷范畴。比如，当测试人员在执行测试用例时发现测试结果与预期结果不符，这种不一致我们就会将它称之为软件缺陷。
在软件开发过程中，如果没有一套有效的流程，而是仅仅通过口头通知或邮件沟通的方式进行缺陷管理，就会导致产品经理、测试人员与开发人员之前产生沟通障碍，减缓缺陷修复的进程，造成项目成本的浪费，甚至影响项目交付。
建立规范的缺陷管理流程
1. 预防缺陷
「预防重于检查」是缺陷管理中的常见观点。通常情况下，越早发现缺陷，缺陷造成的影响就越低。因此，在缺陷管理的过程中，我们在需求分析阶段就要做好「事前预防」，准确识别需求本身是否存在风险或疏漏、是否存在描述不清等情况，还要保证开发团队和测试团队对需求有相同的理解，澄清所有的疑问，在第一阶段发现隐藏的缺陷。
2. 识别缺陷
除了「事前预防」，「事中检查与控制」对于缺陷管理来说也十分重要。
在研发过程中，开发人员可以通过代码评审、单元测试、静态代码检查等方法尽早发现软件缺陷。
在测试过程中，测试人员可以根据测试计划与测试用例进行测试，若测试结果不通过则可将其转为缺陷提交给开发人员。
在运营过程中，运营人员发现或是接到用户的问题反馈后，也可以通过统一的缺陷管理平台提交缺陷，缩短开发人员注意到缺陷的时间。
当来自各方的缺陷汇总到统一的缺陷管理平台后，开发团队还要对其进行评估，识别真正的缺陷。因为不同角色对软件系统的理解存在差异性，有些「缺陷」可能只是由于缓存、网络、操作失误等造成的，并不是真正的缺陷。
3. 设置缺陷优先级
在着手修复缺陷之前，我们还需要考虑这些缺陷的优先级——项目资源是有限的，我们需要优先将资源集中在价值更高的缺陷修复上。
我们通常会从以下两个维度来判断缺陷的优先级：
- 影响范围：受影响的用户数量或者受影响的系统功能数量
- 严重级别：缺陷的重要性，例如：数据丢失、系统损坏等等
综合影响范围和严重级别，我们可大致分出4大类优先级：
- P0：最高优先级，必须立即处理，高于其他开发需求
- P1：优先级较高，需要快速处理，可插入当前迭代，但低于本次迭代中优先级更高的任务
- P2：优先级一般，需要处理，可放入下一次产品迭代进行处理
- P3：优先级较低，可选择性处理，根据迭代进度可放入之后的迭代中进行处理
4. 同步缺陷流转及处理状态
软件缺陷的优先级排好之后，项目团队可以按优先级将缺陷添加到迭代待办事项中，开发人员再针对缺陷进行修复。当修复完成时，要及时将修复信息同步给相关的测试人员，回归测试通过后则表示缺陷修复完成，若测试不通过，则需重新提交缺陷。
5. 输出缺陷分析报表
在项目报表组件下，ONES 提供了四种常用的缺陷分析报表类型，包括：缺陷平均生成时长分布、缺陷创建量和解决量趋势、缺陷探测率和逃逸率分布和重开缺陷分布，测试人员也可以自行配置报表展示的数据维度、排序方式、数据范围等等，满足不同业务场景的评估需求。
缺陷分析报表可以帮助团队评估项目和迭代的质量情况，持续地改进缺陷管理流程。
建立一套规范的缺陷管理流程，可以对缺陷实现有效的追踪和管理，提高缺血修复效率和客户满意度。在研发过程中，ONES 支持缺陷收集—缺陷跟踪—缺陷分析的流程闭环。如果您对 ONES 缺陷管理流程感兴趣，欢迎点击文章右上角的「免费试用」，或直接与我们的解决方案专家沟通，了解和评估 ONES 如何帮助您的团队更进一步。
