漫谈软件缺陷管理的实践

爱测角

修改于 2022-08-25 16:19:37

2950

修改于 2022-08-25 16:19:37

文章被收录于专栏：爱测角的专栏

在《漫谈软件缺陷管理的价值》一文中，文章分享了软件缺陷管理的过程价值和结果价值，并介绍了有哪些实践可以发挥这些价值。那么，这些实践落地到实际工作中可以是什么样子的呢？

一、缺陷管理的实践

如图1-1所示，图片展示的是钉钉App的消息机器人推送的缺陷过程数据。该信息展示的信息包括：当前时间、版本交付倒计时时间、版本Bug总数、待修复Bug数、已修复待验证Bug数和查看详情的链接入口。为什么设计要推送这些内容？如推送内容的标题所写：缺陷跟踪，这个消息推送的直接目的跟踪项目Bug的处理进度，并在项目工作群中和所有项目成员及时同步。那么，这个缺陷跟踪消息的设计有哪些缘由呢？

首先，消息内容包含了当前时间，这个是为了让消息内容能有一个时间点标识，方便以后回顾。

其次，消息包含了距离版本交付的倒计时，为什么要有这个信息呢？可以设想一下，如果没有这个信息，很多人其实对项目交付时间并不敏感，预期的设想是，通过这个倒计时信息，可以增加团队成员对Bug处理的紧迫感。当然还有另一个设计，那就是这个倒计时信息也是是否触发缺陷跟踪信息推送的一个过滤项，我们并不需要在项目一开始就每天推动缺陷跟踪数据，我们会设置一个阈值，这个值可以设置为7，即当距离版本交付只有一周的时候，这个缺陷跟踪任务就启动了。

再次，消息展示了项目的Bug总数，大家能对项目质量有一个大体的认识。然后，消息展示了待修复Bug数和已修复待验证Bug数，其中待修复Bug信息就是要告诉开发人员：你们还有这么多bug还没修，离版本交付只有这么几天了，得抓紧时间！已修复待验证Bug信息就是要告诉测试人员：开发已经改好这些Bug了，得尽快验证了！

最后就是要在消息群中@all，让大家及时关注和评估风险。

最后的最后，就是查看详情的这个小设计，为了方便团队成员能够迅速查看Bug的详细情况，查看详情这里设计了一个跳转链接，点击查看详情，即可跳转到缺陷平台的详情页，如果平台链接允许，可以是直接跳到当前项目的缺陷详情列表。

分享完了缺陷跟踪的第一个设计，我们再来看下图1-2，这里设计的消息和图1-1有哪些不同呢？我们先对比下消息的推送时间，没错，一个是刚开始上班的时间，一个是即将下班的时间。上班前推送的进度消息，给我们提供了今天开始工作前的Bug处理进度，而即将下班时候推送的进度消息，可以给我们提供今天这一天的Bug处理进度。

在图1-2中，除了展示Bug总数、待修复Bug数和已修复待验证Bug数外，还设计了展示今日这些指标变化的数据。Bug总数的增加和待验证Bug数的减少，侧面反馈了测试的工作进度，待修复Bug的减少，则侧面反映了开发的工作进度。

上文分享了缺陷跟踪中的早上和晚上消息内容的设计，接下来再分享下从开发人员维度去分析的设计思路。我们先看下这个设计的消息推送有哪些内容：当前时间、版本交付倒计时时间、待修复Bug总数、各开发人员待修复Bug数和查看详情的链接入口。

相比图1-1和图1-3，这里减少了待验证Bug数，增加了各开发人员待修复Bug数，这个设计的缘由又是什么呢？通过当前迭代待修复Bug数，我们已经知道了当前待处理的Bug总数是12，假如开发人员一共有6人，项目成员可能会这样想：还有两天，6个开发改12个Bug，应该没什么风险吧。但是，当我们从开发人员维度去观察这个缺陷处理进度时，我们会发现，Bug竟然是集中在个别开发身上！而且还有存在一个开发身上还有较多待修复Bug的情况，这个风险程度可想而之了，是高风险！所以，这个时候，除了提醒对应开发抓紧修改Bug外，应该还需要提醒开发负责人及时了解情况，必要情况下要及时协调其他开发资源进行协助。

上文分享了缺陷管理过程价值的实践内容，下文再简单介绍下缺陷管理结果价值的实践内容。如图1-4所示，该消息推送的是整个版本缺陷的统计数据，消息内容包含：版本周期、版本Bug总数、不同严重登记的Bug数，同比上个版本Bug总数和的变化、致命和严重类型Bug的占比、同比上个版本致命和严重类型Bug占比的变化、项目整体质量数据简要评估和查看详情的链接入口。

展示的内容可以简单概括为两点：一是本版本的缺陷情况，二是本版本和上个版本的缺陷对比情况。通过本版本的缺陷数量和各维度缺陷的占比情况，我们可以分析这个版本项目的最终质量。通过本版本和上个版本的缺陷对比情况，我们可以分析这个版本项目质量的变化情况，并找出导致整个项目质量发生变化的关键部分，进行复盘和持续改进。