在《漫谈软件缺陷管理》一文中，笔者通过梳理缺陷状态和协作过程简述了软件缺陷管理。那么，软件缺陷管理的价值有哪些？又有哪些实践可以发挥这些价值？
1. 价值类型
在分享软件缺陷管理的价值前，我们先考虑下：我们日常中是怎么样去思考做一件事的价值呢？如图 1-1 所示，大致可以分为两类，一种称之为过程价值，也就是通常说的 “参与就是收获”，做了一件事，可能并没达到目标，但是做事的过程让我们也有目标之外的收获。另一种就是结果价值，也就是目标导向，做了一件事，顺利达到了预定的目标。
图 1-1 价值分类文章源自玩技e族-https://www.playezu.com/180532.html
2. 缺陷管理的价值
回到缺陷管理价值的思考上，我们做软件缺陷管理的初衷是什么？引用网上的定义：“软件缺陷管理（Defect Management）是在软件生命周期中识别、管理、沟通任何缺陷的过程（从缺陷的识别到缺陷的解决关闭），确保缺陷被跟踪管理而不丢失”。从这个定义我们可以理解缺陷管理的最初目的只是为了确保缺陷被跟踪而不丢失。但是，如图 1-2 所示，当我们从整个软件项目的流程重新回顾缺陷管理的定义，我们可以发现上述的定义还是狭义的，仅从系统测试这个节点定义了缺陷管理的结果价值。广义地看，我们可以从整个项目的维度来思考缺陷管理的价值，从而重新定义软件缺陷管理。
图 2-1 软件项目流程图文章源自玩技e族-https://www.playezu.com/180532.html
这里，我们把缺陷管理的价值也划分为过程价值和结果价值。文章源自玩技e族-https://www.playezu.com/180532.html
如图 1-3 所示，我们把缺陷管理的过程价值归纳为强化团队质量意识、提升团队协作效率和提高团队风控能力。这些过程价值，乍一看感觉有点虚无缥缈，但是留心下你的工作环境你会发现，这些过程价值其实是在潜移默化地改变团队的行为习惯，这些习惯不单单会影响一个项目的质量，而是会无形中影响后续所有项目的质量。当团队养成了能够正向影响项目质量的习惯后，项目的迭代会变得越来越顺利，项目的质量也会逐步提升。相反，项目的开展则会是磕磕绊绊，项目的质量也总是难以把控。
图 2-2 缺陷管理的价值文章源自玩技e族-https://www.playezu.com/180532.html
至于结果价值，除了保证缺陷被跟踪而不丢失之外，这里再补充以下两点：体现项目最终质量和体现项目过程质量。体现项目最终质量这个应该比较好了解，在项目交付后，这些缺陷相关的过程数据和结果数据将会是项目质量保障成效的有力体现，同时，也将是挖掘项目质量问题的重要渠道。文章源自玩技e族-https://www.playezu.com/180532.html
3. 实践的探索
上文介绍了缺陷管理的过程价值和结果价值，那么，有哪些实践可以发挥这些价值呢？文章源自玩技e族-https://www.playezu.com/180532.html
3.1 过程价值的实践
上文提到缺陷管理的过程有强化团队质量意识、提升团队协作效率和提高团队风控能力的价值，这里分享下相关实践的探索。文章源自玩技e族-https://www.playezu.com/180532.html
首先，当项目接近交付阶段时，我们可以每日对待修复缺陷按开发人员维度进行统计并将结果同步到所有项目成员能知悉到的地方。为什么这么做？要强化团队质量意识，重中之重就是要强化开发的质量意识，对于开发质量比较差且质量意识不强的开发人员来说，光靠测试把控质量是把控不住的，这时候就应该在团队中暴露出开发质量比较差的问题。那怎么暴露呢，展示开发人员待修复缺陷 “排行榜” 可以是一种尝试。文章源自玩技e族-https://www.playezu.com/180532.html
其次，我们可以每日对待修复和待验证的缺陷按负责人角色（测试人员和开发人员）进行统计并同步信息。为什么如此分类统计？这里就涉及到缺陷的协作过程，及时让测试团队知道当前项目共有多少（待验证）缺陷要处理，让开发团队知道当前项目共有多少（待修复）缺陷要处理，让全体成员都能对项目缺陷处理进度心中有数，从而促进缺陷的高效流转，提高团队的协作效率。文章源自玩技e族-https://www.playezu.com/180532.html
最后，我们也可以每日对待修复的缺陷总数和占比、高优先级待修复的缺陷数进行统计，并在数量超过阈值的情况下增加风险提示。为什么需要增加阈值判断逻辑？这个做法的思路就是风险预警。对于缺陷来说，风险的评估也应该被量化。例如，距离项目交付的进入了最后阶段了，但是待修复缺陷总数和高优先级缺陷数仍然处于高位。再例如，同样是项目快交付了，但是某个开发身上还有较多且较复杂的缺陷需要处理。当这些风险能够被触发并在团队中预警，团队的风险控制能力也随之提高。
图 3-1 过程价值的实践思路文章源自玩技e族-https://www.playezu.com/180532.html
如图 3-1 所示，以上实践的关键实践思路是基于缺陷过程数据设置统计指标、完成数据统计和反馈数据结论。其目的就是要在团队中及时暴露个体和团队的问题，推动问题的解决，从而发挥缺陷管理的过程价值。
3.2 结果价值的实践
上文这样定义了缺陷管理的结果价值：“在项目交付后，这些缺陷相关的过程数据和结果数据将会是项目质量保障成效的有力体现，也将是挖掘项目质量问题的重要渠道”。从浅层方面理解，在完成整个项目的缺陷数据统计后，如果我们发现测试过程和线上用户反馈的缺陷都处于比较低的量级，这就可以反映整个项目的质量保障工作卓有成效。如果我们发现缺陷量级处于异常量级或者是缺陷变化趋势有明显异常，我们就需要分析和挖掘出现异常的根因并在后续加强管控。
如图 3-2 所示，基于完成的项目缺陷数据，我们可以评估开发质量、测试质量和项目质量。基于缺陷数据，我们可以通过缺陷修复率（已验证关闭缺陷数/缺陷总数）和缺陷重开率（重新打开过的缺陷数/缺陷总数）来评估开发对缺陷的处理质量，可以通过缺陷遗漏率（线上缺陷/项目总缺陷）来评估测试对项目的把控质量，也可以通过分析缺陷根因和发生阶段，识别需求分析、系统设计、系统开发、系统测试和系统发布等项目流程中的问题点，思考应对策略，并落地优化措施。
图 3-2 缺陷管理的结果价值
基于缺陷管理，不管是对开发质量、测试质量还是项目质量的评估，我们的目标是明确的：做好质量评估，加强团队和项目的质量建设。从提高个体的质量意识，到提高团队协作的过程质量，最后到项目质量的保障，从点到线，从线到面，从而把控好项目的最终质量，这也是缺陷管理结果价值的延伸。
4. 总结
本文分享了软件缺陷管理的过程价值和结果价值。从定义上看过程价值和结果价值是两个独立的内容，但是实际在缺陷管理中，过程价值会直接影响结果价值，结果价值也可以反过来影响后续的过程价值。所以我们的目标是：追求缺陷管理过程和结果的双重价值。
最后，回到缺陷管理定义上，广义地看，我们或许可以这样定义：“软件缺陷管理（Defect Management）是在软件生命周期中识别、管理、沟通、分析和总结任何缺陷的过程（从缺陷的识别，到缺陷的解决关闭，再到缺陷的复盘总结），确保缺陷被跟踪管理而不丢失，避免或减少同类的缺陷再次发生。”
作者简介： Chaofan，北交学子，专注思考和分享软件测试与质量保障。
如果对文章有任何疑问和见解，欢迎留言提问和指点。
相关引文：
《漫谈软件缺陷管理》
评论