标签归档:质量内建

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

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

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

缺陷预防

说到缺陷预防,通常能够想到的就是测试前移(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个“为什么”来提问,以找出其根本原因。根据实际情况,问题的数量不一定要限制在五个,可多可少,适当调整。

聚焦测试,驱动卓越

在经历了“七年之痒”后,蓝鲸项目进入第八个年头,项目的一切趋于稳定。团队倡导持续改进,可大家的感觉是已经尽力做到最好,这个时候似乎没有什么可以改进的了。为了突破这个局面,项目重新聚焦测试,从质量和测试的角度对现状进行了一次评估。

评估采用的是基于软件测试原则的模型,本文就是跟大家分享一下这个模型。

测试原则

Testing principles

2012年澳大利亚敏捷大会(Agile Australia)上ThoughtWorks的非常资深的测试实践带头人Kristan Vingrys分享了如上测试原则,这些原则是ThoughtWorks的同事们在多年软件测试经验基础上总结出来的。

1. 质量内建(Build quality in)

You cannot inspect quality into the product; it is already there.
— W.Edwards Deming

著名的质量管理专家戴明指出:产品质量不是检测出来的,从产品生产出来后质量就已经在那了。这同样适用于软件产品。

缺陷发现的越晚,修复的成本就越高。质量内建要求我们做好软件开发每个环节,尽早预防缺陷产生,以降低缺陷出现后的修复成本,要减少对创可贴式的补丁(hotfix)的依赖。

Cost of change

推荐实践: TDD、ATDD等

2. 快速反馈(Fast feedback)

每个环节的任何变化都能最快的反馈给需要的人,从而可以基于当下最新信息做出明智的决定,降低风险。这要求我们对系统进行频繁的测试,缩短回归测试的周期。

推荐实践:

  • 符合测试金字塔结构的自动化测试,让每一层的测试都能发挥尽可能大的价值,给出最快速的反馈;
  • 持续集成,尽早排查集成引起的问题,降低集成所带来的风险。
3. 全员参与(Involve everyone)

— 这次上线好多bug,QA是怎么测的?!
— 那个xxx组在上线前发现了很多的bug,他们的QA真给力!

成也QA,败也QA…如果还是这样的认识,那是极为片面的。测试不仅仅是QA的事情,团队成员要一起为质量负责,软件开发生命周期的测试相关活动需要全员的参与。

全员参与的好处是利用不同角色的不同领域知识和不同的思维模式,不仅可以使得测试的质量更高,同时还能最优化利用测试资源,做到价值最大化。

推荐实践:

  • 自动化测试:QA和BA结对用DSL编写测试用例,QA和Dev结对编码实现测试,生成业务人员可读的测试报告;
  • Bug bash(bug大扫除):团队不同角色一起参与的一个找bug的测试活动
4. 测试作为资产(Tests as asset)

自动化测试帮助我们验证系统功能的正确性,好的自动化测试还有文档的功能,是宝贵的资产。如果每个项目都构建自己独立的自动化测试,没有跨项目共享,其浪费显而易见。

这个原则要求把自动化测试的代码跟产品开发的代码一起,当做资产管理起来,在不同项目间做到尽可能的复用。这笔宝贵的资产能帮助我们更好的统计跨项目的测试覆盖率,更好的优化测试。

推荐实践:利用版本控制管理工具把测试代码和产品构建代码一起管理,都作为产品的一部分。

5. 更快的交付(Faster delivery into production)

任何一个idea越快做成软件产品交付给用户,给企业带来的价值越大。

该原则要求我们把测试活动融入软件开发生命周期的每个环节,不要在后期进行长时间的集中测试;同时测试人员的关注点不再是发现更多的bug以阻止不符合质量要求的产品上线,而是把目标放在如何能够帮助团队尽快的让产品上线,让企业投资回报更早,也就是更快的赚钱。

推荐实践:自动化构建流水线、关注平均恢复时间、发布与部署解耦等。

Pipeline
6. 清晰一致的测试视图(Clear and consistent view of testing)

可视化的报告给客户和内部团队展示测试的状态和产品内外部的质量,对项目的质量和风险把控是非常有帮助的。不同项目各自采用五花八门的图表样式,将不利于项目间的信息共享和比较,无端增加复杂性,带来浪费。

因此,我们需要把状态报告做的尽可能简单、清晰,并且保持跨项目的指标一致性;同时,我们不应该为了让某个指标变得好看而改变我们的行为,整个报告要诚实开放,这样才能真实反映出项目的状况。

7. 优化业务价值(Optimize business value)

开发软件无疑是要给客户的业务带来价值,软件测试也需要为这个目标服务,测试要跟业务价值保持一致,帮助客户优化业务价值。要求做到:

  • 测试不仅是保险,不仅是保证软件质量的;
  • 要有目的的关注变化的特性,不要盲目的散弹枪式的对任何特性进行测试,要有优先级;
  • 要能帮助企业驱动新的特性和功能;
  • 帮助客户创造安全的尝试新点子的环境,提供快速的反馈。

推荐实践:

  • 基于风险的测试,根据业务优先级需要调整测试策略,在测试过程中尽可能规避给业务带来的风险;
  • 生产环境下的QA,通过收集生产环境的真实用户行为和应用使用数据,对业务的优化做出贡献。

评估模型以及在项目中的应用

评估模型就是将上述七条原则的每一条细化,列出该原则对应的实践和行为,并给每个实践或行为设定0-5分的不同评分标准,最后统计各个原则的总分,形成类似下图的结果报告:

Result Model

在项目中的应用

以Cristan分享的模型为基础,由Tech Lead和几个DEV、QA成立一个评估小组。

第一步:分别根据各自的理解给项目打分,结果是很有意思的,请看下图:

结果对比图

根据这些结果,可以看出大家的认识是不太一致的。

第二步:评估小组对模型中的每条细节进行review,做适当修改以更符合项目情况,并且在评估小组内大家达成共识。其中,所做的修改包括修改原有的实践评分指标、增加新的更适合项目和当前技术趋势的实践、删除过时的或者不符合项目特点的实践。

第三步:根据更新过后的模型指标对项目上的一个Team做评估试点,详细分析该team对应到测试原则各个维度的well和less well部分,由评估小组成员一起打分,得到该team的评估结果图。

第四步:根据评估结果并结合项目目标排定需要改进的优先级,制定出改进action,并更新给试点team执行。

后续:试点一个周期后再次评估,并重新review评估模型,再推行到整个项目。同时,周期性的进行新的评估和制定新的action,以做到持续的改进和优化。

总结

图片来自网络

应用程序的质量、测试的快速性、以及上线后轻松自信的更新服务的能力,是帮助企业业务价值最大化的关键因素之一,一直是我们所追求的。

基于测试原则的评估模型,可以帮助我们在追求这个目标的道路上少走弯路,帮助我们持续的改进,以驱动出更加卓越的软件。