TW洞见〡软件缺陷的有效管理

文章作者来自ThoughtWorks:林冰玉,图片来自网络。

“这次发布之前怎么这么多的缺陷,是不是需要分析一下啊?” 答案是肯定的,可是这个时候才想起要分析已经有点晚了,有可能这些缺陷很难分析了。这是发生过的一个真实场景,所记录的缺陷包含信息很有限,很难有效的做好分析!本文就来聊聊如何有效的管理和分析缺陷。

缺陷记录

曾经有个项目是在QC(Quality Center)里记录缺陷,需要填写很多必填属性字段,加上QC服务器在国外,访问速度非常的慢,每次记录缺陷成为了大家极其痛苦的一件事情。于是,很多时候,发现了缺陷也不愿意往QC里填,而是直接写个纸条简单记录下,验证完了它的生命周期就结束了,这样后面就没办法去很好的跟踪和分析了。(题外话:当时采用脚本稍微减轻了点痛苦。) 也有的项目对缺陷的格式和属性没有严格要求,记录的时候很简单也很自由,这样记录的缺陷由于很多必要信息的缺失,对后续的跟踪和分析也是极为不利。 还有一种情况就是记录缺陷时同样有一些属性要求填写,但是这些属性值可能不是那么有意义,导致存储的信息不仅没用,反而添加混乱,也是不利于跟踪和分析的。比如,其中的“根源(root cause)”属性的值如下图1所示,这些值根本就不是根源,这是一个没有意义的捣乱属性。

图1 某缺陷根源属性值 缺陷记录应该做到尽量简单,且包含必要的信息。

  1. 标题:言简意赅,总结性的语句描述是什么缺陷
  2. 详情:包括重现步骤、实际行为、期望结果等,根据具体情况确定其详细程度,必要时可以添加截图、日志信息等附加说明。
  3. 重要属性:优先级、严重性、所属功能模块、平台(OS、浏览器、移动设备的不同型号等)、环境、根源等,这些属性对应的值需要根据不同项目的情况自己定义,其中“根源”是相当关键的一个属性,后面有示例可以参考该属性对应的值有哪些。
  4. 其他:每个项目对应的还会有其他信息需要记录的,自行定义就好。

在敏捷开发环境中,测试人员可能随时在测试、随时都会发现缺陷,包括还在开发手里没有完成的功能。什么时候发现的缺陷需要记录呢?通常情况下,开发还没完成的用户故事(story),测试人员发现缺陷只需要告诉开发修了,在该故事验收的时候一起检查就好了,无需单独记录;在开发已经完成,交到测试人员手里正式测试的故事,再发现缺陷就需要记录来跟踪了;后续的所有阶段发现的缺陷都需要记录。

缺陷分析

比较推荐的一种缺陷分析方法是鱼骨图分析法,可以将跟缺陷相关的各个因素填写到鱼骨图里,对缺陷进行分析,如下图2示:

图2. 鱼骨图缺陷分析法

缺陷相关的各属性拿到了,就可以用表格、曲线图、饼图等统计各个属性对应的缺陷数量,分析缺陷的趋势和原因。下面是我在项目上做过的分析报告图:

图3. 功能与环境对应缺陷数量统计表和缺陷根源比例图

图4. 缺陷根源统计表和比例图

图5. 缺陷迭代趋势分析图

分析完得到统计的结果就要采取对应的措施,从而防范更多的缺陷产生。比如:修缺陷(上面示例中的“bug fixing”)引入的新缺陷比较多,可以在修复缺陷后添加对应的自动化测试;浏览器兼容性问题相关的缺陷较多的话,可以在开发完成验收的时候在多种浏览器上验收,等等。 什么时候该进行缺陷的分析呢?通常,推荐每个迭代周期分析一次,并且跟以往各个迭代进行对比,进行趋势对比。当然,有时候可能一个迭代发现的缺陷非常少,分析的周期可以根据具体情况做出调整。

总结

缺陷记录是为更好的跟踪和分析缺陷做准备的,而缺陷分析是软件质量保证的重要环节,对于软件过程的改进,软件产品的发布来说具有十分重要的参考价值,建议各项目定期都要做做缺陷分析。

原文发布于微信公众号 - 思特沃克(ThoughtWorks)

原文发表时间:2015-08-01

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏开源优测

积微速成计划第一期第一次总结

经过昨天启动发布说明及第一次任务,今天做一下启动总结说明 从总体上来看存在以下几个主要问题: 比较缺乏知识的梳理能力,尤其是把零散的知识点梳理成解决某一应用场景...

2906
来自专栏黑泽君的专栏

软件开发文档介绍

3982
来自专栏WeTest质量开放平台团队的专栏

一分钟读懂兼容测试报告(一):概况篇

? WeTest 导读 在WeTest深度兼容测试上线之后,为大量手游及应用挖掘了兼容问题,为测试开发同学提供了极大的便利。为了能够让测试开发同学能够迅速的了...

1532
来自专栏北京马哥教育

系统吞吐量、TPS(QPS)、用户并发量、性能测试概念和公式

PS:下面是性能测试的主要概念和计算公式,记录下: 一.系统吞度量要素: 一个系统的吞度量(承压能力)与request对CPU的消耗、外部接口、IO等等紧密...

1.1K5
来自专栏即时通讯技术

微信技术分享:微信的海量IM聊天消息序列号生成实践(算法原理篇)

对于IM系统来说,如何做到IM聊天消息离线差异拉取(差异拉取是为了节省流量)、消息多端同步、消息顺序保证等,是典型的IM技术难点。

2062
来自专栏ThoughtWorks

「微前端」- 将微服务理念扩展到前端开发 | 洞见

前言 在 ThoughtWorks 正式发布的最新一期技术雷达当中,「微前端(Micro Fontends)」已经进入到试验阶段,而试验环所列出的技术是我们认为...

4707
来自专栏SDNLAB

什么是开放网络?

网络行业的发展如果非要归纳出一个明确的发展趋势的话,那这个趋势无疑是“开放”。业界有一个奇怪的现象,但凡涉及到“开源、开放”的技术或者社区,好像都比较受到追捧,...

2835
来自专栏编程

什么是后端开发?

软件应用程序就像冰山一样。用户看到的只是应用程序的一部分——在大多数情况下应用程序的最大部分是看不到的,这就是令人难以捉摸又神秘的“后端”。 在 Web 开发的...

5097
来自专栏WeTest质量开放平台团队的专栏

一分钟读懂兼容测试报告(一):概况篇

原文链接:https://wetest.qq.com/lab/view/425.html

1171
来自专栏DevOps时代的专栏

无服务器化的微服务持续交付

前言 我在刚进入 ThoughtWorks 的时候就做微服务,当时不知道什么叫做微服务,只是我们通过一个小的技术应用替换原先的大应用的一个部分,当时只是做一个解...

3836

扫码关注云+社区

领取腾讯云代金券