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