这个项目的数据还揭示出一些有价值的信息:

  1、开发人员可以有效地降低总缺陷率

  在为期27天的编码期(这个项目是瀑布式开发)中,千行代码的总缺陷率趋势从第的130/千行降低到后的60/千行,说明若开发人员能潜心消除缺陷,那么在很短的时间里能大幅降低自己代码的总缺陷率;极少有测试活动能做到类似的效果。

  2、“所有缺陷无需测试活动即可消除”

  下面是当时的“过程效益”分析,所谓过程效益,是某个过程对消除缺陷的能力。比如如果说“调试”的过程效益是40%,是说如果有100个缺陷到达调试环节,调试中会发现其中40个,而60个会被漏到后面去。图中的蓝线是“调试”的过程效益,注意前期的调试缺陷经常很低,表明“调试起来一切正常,但是一测试发现很多问题”;后期的调试效益经常是,这个意思是说在完成调试(是F5)后,之后再也没有任何人、任何活动从这天编写的代码中发现任何缺陷。

  确切说系统测试的6个缺陷,全部发现于前13天的代码中;换一种说法:如果全程都能像后13天一样编写代码,系统测试的缺陷将为0。

  “所有缺陷无需测试活动即可消除”这句话被打上引号,是因为它是一种很理想的状态。但是与“所有缺陷可以被某种测试活动消除”相比,我更相信前者。

  3、编程人员可以训练出行之有效的排除缺陷的手段

  “自查”的过程效益始终没有达到,但是它与调试的作用越来越互补。比如在初期自查+调试后,还有大量缺陷被发现(所以调试的效益很低);但如果每天仔细分析自己自查发现的缺陷和调试发现的缺陷,可能在短短一个半月的时间内大幅度提升自身发现缺陷的能力,乃至于到达不把缺陷留给测试环节,更不会留给客户的程度。

  从上面图中的数据可以看出来,这个项目的质量不是由一个“能力很强的人”保证的,因为刚开始调试后还是有很多缺陷会留给测试活动发现,只是后来的训练导致了能力的增强。因此人的因素有,但是不是的。

  总结

  这些项目揭示出来的规律是:程序员应该负责产品质量,他们有能力,也有时间。

  第一个项目并没有因为“程序员还要负责质量”而耽误进度或造成功能“太少”影响到市场竞争力;第二个项目甲方后来坦然说“原定计划一年,没想到三个半月结束了”(此前他们自己曾经尝试2个人研发过一年,此外也了解另外两家竞争对手投入的情况)。

  很多人一定认为上述经验有很大的局限性,比如对个人能力的要求很高,其实不然。第一个项目中,那些刚毕业的本科生和研究生与动辄工作5、6年乃至10年的程序员的水平不可同日而语;第二个项目中我本人当时工作经验也只有8年,其中做职业程序员的时间则只有4~5年左右,编码量仅在2万行左右。

  所以关键还是方法,而不是人;或者说是“使用正确方法的人”足够了,“使用正确方法的正确的人”不是一个强制条件。

  在后续的章节中,会谈到如何在一般情况下,推行这些方法。

  此外还会提到,在这种方法大行其道的时候,专业的测试团队是否还有必要存在,以及还有“什么用”,以及应该如何工作。