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

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

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

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

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

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

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

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

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

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

　　总结

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

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

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

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

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

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