标签归档:缺陷管理

缺陷分析如何帮助质量内建

质量内建的关键是缺陷预防

近几年,软件开发过程中的质量内建正在逐渐被大家所重视。越早发现的软件缺陷,修复成本越低。质量内建要求在软件开发生命周期的每个阶段做好质量保障工作,预防缺陷的产生。

缺陷预防

说到缺陷预防,通常能够想到的就是测试前移(QA从需求阶段开始介入、TDD/ATDD等)、Code Review等实践,正向的来预防缺陷的产生。

但是,软件系统的生态环境越来越复杂,不确定性增加,缺陷预防的难度也在增加。如果缺陷已经产生,是否还能被利用来帮助质量内建呢?

在《软件缺陷的有效管理》一文中介绍了基本的缺陷分析方法,接下来我们一起探讨一下如何利用缺陷分析来帮助质量内建。

缺陷分析与质量内建

缺陷分析最为关键的是根因分析,找到根因,能够减少缺陷重复出现的可能性,在后续阶段做到缺陷预防,帮助质量内建。

分析根因

引起缺陷的原因主要有下面这几个方面:

  • 需求缺失或者需求不清晰
  • 设计问题
  • 编码错误
  • 测试不够
  • 环境相关(硬件、软件、配置等)

利用5 Why分析法[1]根据缺陷的表象,多问几个为什么,找出根因。下面是一个真实生产环境缺陷的根因分析过程:

上图的根因还可以继续细分,比如为什么这么设计,可能还会有更深层次的问题;同样的,进度紧张导致的需求没有实现,也可能还有更详细的内情可以分析的。最好能一直分析,直到找出真正的根本原因。

定位阶段

找出根本原因之后,同样利用5 Why分析法,基于软件开发生命周期由外往内的问为什么,从而定位引发问题的薄弱环节,找出是哪个环节做的不好导致的问题。拿生产环境的缺陷为例,下面是可能(不限于)的问题列表:

1. 为什么在预生产环境没有发现这个问题?
2. 为什么测试环境没有测出这个问题?
3. 为什么Desk Check没有发现这个问题?
4. 为什么Code review没有发现这个问题?
5. 为什么单元测试没有覆盖到这个问题?
6. 为什么在需求评审的时候没有发现这个问题?
7. ……

定义改进action

找出了根因,并且定位了引发缺陷的最可能阶段,接下来就是通过“What”问题来确定对应的action,预防类似缺陷再次发生,从而帮助质量内建。

不同的根因对应的可能actions有:

总结

质量内建的关键是缺陷预防。

除了正向的考虑加强每个环节的质量保障工作可以预防缺陷,通过分析缺陷的根因、定位问题出现的薄弱环节、制定可行的对应改进措施,可以帮助我们更有的放矢的做好缺陷预防工作,更有效的做好质量内建。


注1:5 Why分析法
所谓5 Why分析法,又称“5问法”,也就是对一个问题点连续以5个“为什么”来提问,以找出其根本原因。根据实际情况,问题的数量不一定要限制在五个,可多可少,适当调整。

软件缺陷的有效管理

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

缺陷记录

曾经有个项目是在QC(Quality Center)里记录缺陷,需要填写很多必填属性字段,加上QC服务器在国外,访问速度非常的慢,每次记录缺陷成为了大家极其痛苦的一件事情。于是,很多时候,发现了缺陷也不愿意往QC里填,而是直接写个纸条简单记录下,验证完了它的生命周期就结束了,这样后面就没办法去很好的跟踪和分析了。(题外话:当时采用脚本稍微减轻了点痛苦。)

也有的项目对缺陷的格式和属性没有严格要求,记录的时候很简单也很自由,这样记录的缺陷由于很多必要信息的缺失,对后续的跟踪和分析也是极为不利。

还有一种情况就是记录缺陷时同样有一些属性要求填写,但是这些属性值可能不是那么有意义,导致存储的信息不仅没用,反而添加混乱,也是不利于跟踪和分析的。比如,其中的“根源(root cause)”属性的值如下图1所示,这些值根本就不是根源,这是一个没有意义的捣乱属性。

图1.某项目缺陷根源属性值

缺陷记录应该做到尽量简单,且包含必要的信息。

1. 标题:言简意赅,总结性的语句描述是什么缺陷

2. 详情:包括重现步骤、实际行为、期望结果等,根据具体情况确定其详细程度,必要时可以添加截图、日志信息等附加说明。

3. 重要属性:优先级、严重性、所属功能模块、平台(OS、浏览器、移动设备的不同型号等)、环境、根源等,这些属性对应的值需要根据不同项目的情况自己定义,其中“根源”是相当关键的一个属性,后面有示例可以参考该属性对应的值有哪些。

4. 其他:每个项目对应的还会有其他信息需要记录的,自行定义就好。

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

缺陷分析

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

图2. 鱼骨图缺陷分析法

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

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

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

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

分析完得到统计的结果就要采取对应的措施,从而防范更多的缺陷产生。比如:修缺陷(上面示例中的“bug fixing”)引入的新缺陷比较多,可以在修复缺陷后添加对应的自动化测试;浏览器兼容性问题相关的缺陷较多的话,可以在开发完成验收的时候在多种浏览器上验收,等等。

什么时候该进行缺陷的分析呢?通常,推荐每个迭代周期分析一次,并且跟以往各个迭代进行对比,进行趋势对比。当然,有时候可能一个迭代发现的缺陷非常少,分析的周期可以根据具体情况做出调整。

总结

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

(此文发表于TW洞见