• 0
  • 0
分享

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

一、缺陷管理的实践

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

11.png

图1-1 爱测角_缺陷跟踪_早编辑

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

其次,消息包含了距离版本交付的倒计时,为什么要有这个信息呢?可以设想一下,如果没有这个信息,很多人其实对项目交付时间并不敏感,预期的设想是,通过这个倒计时信息,可以增加团队成员对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的减少,则侧面反映了开发的工作进度。

2.png

图1-2 爱测角_缺陷跟踪_晚编辑

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

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

3.png

图1-3 爱测角_缺陷跟踪_开发维度编辑

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

4.png

图1-4 爱测角_缺陷跟踪_复盘编辑

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

二、总结

在缺陷管理中,对缺陷过程数据和结果数据的展现形式也并非只局限于本文分享的这些维度和形式,也可以从缺陷紧急程度、缺陷每日变化趋势和缺陷发现阶段等维度去总结内容,并将内容以折线图、柱状图和饼图等形式推送到团队群。至于要以哪种形式来推送哪些维度的缺陷数据,这个可以结合当前缺陷管理的现状来灵活调整。


作者简介Chaofan,爱测角成员之一,专注软件质量保障的经验分享。

相关引文

《漫谈软件缺陷管理的价值》

《漫谈软件缺陷管理》

《漫谈项目质量保障——协作流程优化》



  • 【留下美好印记】
    赞赏支持
登录 后发表评论
+ 关注

热门文章

    最新讲堂

      • 推荐阅读
      • 换一换
          • 一、前言1.1 数据库概念及分类首先,我们经常说的MySQL是一个数据库管理系统,而非数据库。数据库是组织、存储和管理数据的仓库,存储数据的容器。 而数据库管理系统是操纵和管理数据库的大型软件,建立、使用和维护数据库。 数据表是真正的数据存储单元,其他对象的基础。 三者之间的关系为:一个数据库管理系统维护了多个数据库,一个数据库包含若干数据表。关于数据库的分类,可能有很多种分类。一般来说,我们用到最多的就是关系型数据库和NoSQL数据库。 而其中关系型数据库又是应用最为广泛的。1.2 SQL语句概念及分类SQL:一种结构化查询语句,用于访问和操作数据库的标准计算机语言。 通常用途为操作数据库对...
            15 20 5062
            分享
          • 一. 我们没有已经部署的环境,其他团队会做这件事情你星期一早上来办公室。您注意到生成拦截器有几个问题。您需要从构建存储库构建新版本。您提出请求或联系您的开发团队或部署团队。哦,他们都在忙些其他的事情。但他们在一段时间后就可以做到了。现在告诉我,为什么会这样?它并不像看上去那么复杂。当采取新的构建时,开发人员肯定肯定可以修复好。但是,当您只需触发并部署它时,为什么要等待或依赖某个人呢?有能力和权限随时部署,使您的工作更容易,没有任何等待。你看到了吗?它也会增加你每天测试的周转时间。尽管它正在使用添加的记录器调试某些缺陷,或者使用新的构建来验证已解决的错误。或者是进行新的构建并开始测试新...
            0 0 977
            分享
          • 在我们测试过程中,需要把发现的bug纳入系统,并指派给对应的开发人员修改,开发修改完成后更新bug状态,bug回到测试手中,进行验证,验证完毕关闭bug或重新打开bug。在这个过程中就需要借助bug管理工具,目前常用的是tapd软件缺陷管理系统。点开缺陷详情,右侧更多里面有针对这个缺陷的一系列功能,比如重新编辑缺陷,删除缺陷,复制缺陷,移动缺陷,合并缺陷,关联缺陷,转需求,转用例等。常用的是复制,移动和关联缺陷,当提交完bug发现bug对应的项目选错了,这个时候我们可以用移动功能把bug移动到对应的项目中,当发现的问题与之前提交的一个问题比较类似,这个时候就可以用复制功能,把问题的主体复制过去...
            1 1 23235
            分享
          • 成熟的沟通技巧对于软件测试工程师在竞争激烈的软件测试领域中发挥作用至关重要。虽然软件测试职业需要编程技术和业务能力等硬技能,但优秀的测试人员是全面的,并且掌握了人际沟通的艺术。能够有效在团队以及与外部进行交流的测试人员通常会让团队更容易成功。沟通不畅可能导致缺陷与错误编码一样昂贵)。沟通不畅不仅会导致缺陷,还会导致相互指责、关系降低和项目延迟。要使软件测试人员取得成功,必须掌握沟通技巧,尤其是积极倾听、非语言沟通和压力管理。积极倾听人们无法沟通的原因有很多,但一个糟糕的倾听者是最令人沮丧的一种。糟糕的倾听者试图终止他人的发言,在他们说完之前做出回应,或者试图在谈话中保持主导地位。但是这非常不重...
            0 0 2012
            分享
          • 每当一个系统上线开始运维以后,项目组就会进行到一个阶段,不断的收到从线上反馈回来的生产事件,对生产事件进行有效的深度挖掘、分析,形成正确的改进项,可以持续的完善系统和研发管理过程。常用的缺陷分析方法有:根本原因缺陷分析法、四象限缺陷分析法、ODC 缺陷分析法、Rayleigh缺陷分析法和Gompertz 缺陷分析法。ODC(Orthogonal Defect Classification,正交缺陷分类)是获取缺陷的一种分类方案,但它不仅仅是一个分类方案,还是一个软件过程的度量系统,它是建立在包含于缺陷流中的语义信息基础上的,可以帮助评估测试效率,对错误进行跟踪,通过方案的分析机制可以评估客户的...
            0 1 4949
            分享
      • 51testing软件测试圈微信