在《漫谈软件缺陷管理的价值》一文中，文章分享了软件缺陷管理的过程价值和结果价值，并介绍了有哪些实践可以发挥这些价值。那么，这些实践落地到实际工作中可以是什么样子的呢？
一、缺陷管理的实践
如图 1-1 所示，图片展示的是钉钉 App 的消息机器人推送的缺陷过程数据。该信息展示的信息包括：当前时间、版本交付倒计时时间、版本 Bug 总数、待修复 Bug 数、已修复待验证 Bug 数和查看详情的链接入口。为什么设计要推送这些内容？如推送内容的标题所写：缺陷跟踪，这个消息推送的直接目的跟踪项目 Bug 的处理进度，并在项目工作群中和所有项目成员及时同步。那么，这个缺陷跟踪消息的设计有哪些缘由呢？文章源自玩技e族-https://www.playezu.com/188667.html
图 1-1 爱测角 - 缺陷跟踪 - 早文章源自玩技e族-https://www.playezu.com/188667.html
首先，消息内容包含了当前时间，这个是为了让消息内容能有一个时间点标识，方便以后回顾。文章源自玩技e族-https://www.playezu.com/188667.html
其次，消息包含了距离版本交付的倒计时，为什么要有这个信息呢？可以设想一下，如果没有这个信息，很多人其实对项目交付时间并不敏感，预期的设想是，通过这个倒计时信息，可以增加团队成员对 Bug 处理的紧迫感。当然还有另一个设计，那就是这个倒计时信息也是是否触发缺陷跟踪信息推送的一个过滤项，我们并不需要在项目一开始就每天推动缺陷跟踪数据，我们会设置一个阈值，这个值可以设置为 7，即当距离版本交付只有一周的时候，这个缺陷跟踪任务就启动了。文章源自玩技e族-https://www.playezu.com/188667.html
再次，消息展示了项目的 Bug 总数，大家能对项目质量有一个大体的认识。然后，消息展示了待修复 Bug 数和已修复待验证 Bug 数，其中待修复 Bug 信息就是要告诉开发人员：你们还有这么多 bug 还没修，离版本交付只有这么几天了，得抓紧时间！已修复待验证 Bug 信息就是要告诉测试人员：开发已经改好这些 Bug 了，得尽快验证了！文章源自玩技e族-https://www.playezu.com/188667.html
最后就是要在消息群中 @ all，让大家及时关注和评估风险。文章源自玩技e族-https://www.playezu.com/188667.html
最后的最后，就是查看详情的这个小设计，为了方便团队成员能够迅速查看 Bug 的详细情况，查看详情这里设计了一个跳转链接，点击查看详情，即可跳转到缺陷平台的详情页，如果平台链接允许，可以是直接跳到当前项目的缺陷详情列表。文章源自玩技e族-https://www.playezu.com/188667.html
分享完了缺陷跟踪的第一个设计，我们再来看下图 1-2，这里设计的消息和图 1-1 有哪些不同呢？我们先对比下消息的推送时间，没错，一个是刚开始上班的时间，一个是即将下班的时间。上班前推送的进度消息，给我们提供了今天开始工作前的 Bug 处理进度，而即将下班时候推送的进度消息，可以给我们提供今天这一天的 Bug 处理进度。文章源自玩技e族-https://www.playezu.com/188667.html
在图 1-2 中，除了展示 Bug 总数、待修复 Bug 数和已修复待验证 Bug 数外，还设计了展示今日这些指标变化的数据。Bug 总数的增加和待验证 Bug 数的减少，侧面反馈了测试的工作进度，待修复 Bug 的减少，则侧面反映了开发的工作进度。文章源自玩技e族-https://www.playezu.com/188667.html
图 1-2 爱测角 - 缺陷跟踪 - 晚文章源自玩技e族-https://www.playezu.com/188667.html
上文分享了缺陷跟踪中的早上和晚上消息内容的设计，接下来再分享下从开发人员维度去分析的设计思路。我们先看下这个设计的消息推送有哪些内容：当前时间、版本交付倒计时时间、待修复 Bug 总数、各开发人员待修复 Bug 数和查看详情的链接入口。
相比图 1-1 和图 1-3，这里减少了待验证 Bug 数，增加了各开发人员待修复 Bug 数，这个设计的缘由又是什么呢？通过当前迭代待修复 Bug 数，我们已经知道了当前待处理的 Bug 总数是 12，假如开发人员一共有 6 人，项目成员可能会这样想：还有两天，6 个开发改 12 个 Bug，应该没什么风险吧。但是，当我们从开发人员维度去观察这个缺陷处理进度时，我们会发现，Bug 竟然是集中在个别开发身上！而且还有存在一个开发身上还有较多待修复 Bug 的情况，这个风险程度可想而之了，是高风险！所以，这个时候，除了提醒对应开发抓紧修改 Bug 外，应该还需要提醒开发负责人及时了解情况，必要情况下要及时协调其他开发资源进行协助。
图 1-3 爱测角 - 缺陷跟踪 - 开发维度
上文分享了缺陷管理过程价值的实践内容，下文再简单介绍下缺陷管理结果价值的实践内容。如图 1-4 所示，该消息推送的是整个版本缺陷的统计数据，消息内容包含：版本周期、版本 Bug 总数、不同严重登记的 Bug 数，同比上个版本 Bug 总数和的变化、致命和严重类型 Bug 的占比、同比上个版本致命和严重类型 Bug 占比的变化、项目整体质量数据简要评估和查看详情的链接入口。
图 1-4 爱测角 - 缺陷跟踪 - 复盘
展示的内容可以简单概括为两点：一是本版本的缺陷情况，二是本版本和上个版本的缺陷对比情况。通过本版本的缺陷数量和各维度缺陷的占比情况，我们可以分析这个版本项目的最终质量。通过本版本和上个版本的缺陷对比情况，我们可以分析这个版本项目质量的变化情况，并找出导致整个项目质量发生变化的关键部分，进行复盘和持续改进。
二、总结
在缺陷管理中，对缺陷过程数据和结果数据的展现形式也并非只局限于本文分享的这些维度和形式，也可以从缺陷紧急程度、缺陷每日变化趋势和缺陷发现阶段等维度去总结内容，并将内容以折线图、柱状图和饼图等形式推送到团队群。至于要以哪种形式来推送哪些维度的缺陷数据，这个可以结合当前缺陷管理的现状来灵活调整。
原文地址：《漫谈软件缺陷管理的实践》
作者简介：Chaofan，爱测角成员之一，专注软件质量保障的探索和分享。
相关引文：
《漫谈软件缺陷管理的价值》
《漫谈软件缺陷管理》
《漫谈软件系统测试——问题解决》
《漫谈项目质量保障——协作流程优化》
硬件测试软件