敏捷开发团队管理系列:程序与测试团队(一)
作者:网络转载 发布时间:[ 2011/12/19 13:16:49 ] 推荐标签:
这个项目的数据还揭示出一些有价值的信息:
1、开发人员可以有效地降低总缺陷率
在为期27天的编码期(这个项目是瀑布式开发)中,千行代码的总缺陷率趋势从第的130/千行降低到后的60/千行,说明若开发人员能潜心消除缺陷,那么在很短的时间里能大幅降低自己代码的总缺陷率;极少有测试活动能做到类似的效果。
2、“所有缺陷无需测试活动即可消除”
下面是当时的“过程效益”分析,所谓过程效益,是某个过程对消除缺陷的能力。比如如果说“调试”的过程效益是40%,是说如果有100个缺陷到达调试环节,调试中会发现其中40个,而60个会被漏到后面去。图中的蓝线是“调试”的过程效益,注意前期的调试缺陷经常很低,表明“调试起来一切正常,但是一测试发现很多问题”;后期的调试效益经常是,这个意思是说在完成调试(是F5)后,之后再也没有任何人、任何活动从这天编写的代码中发现任何缺陷。
确切说系统测试的6个缺陷,全部发现于前13天的代码中;换一种说法:如果全程都能像后13天一样编写代码,系统测试的缺陷将为0。
“所有缺陷无需测试活动即可消除”这句话被打上引号,是因为它是一种很理想的状态。但是与“所有缺陷可以被某种测试活动消除”相比,我更相信前者。
3、编程人员可以训练出行之有效的排除缺陷的手段
“自查”的过程效益始终没有达到,但是它与调试的作用越来越互补。比如在初期自查+调试后,还有大量缺陷被发现(所以调试的效益很低);但如果每天仔细分析自己自查发现的缺陷和调试发现的缺陷,可能在短短一个半月的时间内大幅度提升自身发现缺陷的能力,乃至于到达不把缺陷留给测试环节,更不会留给客户的程度。
从上面图中的数据可以看出来,这个项目的质量不是由一个“能力很强的人”保证的,因为刚开始调试后还是有很多缺陷会留给测试活动发现,只是后来的训练导致了能力的增强。因此人的因素有,但是不是的。
总结
这些项目揭示出来的规律是:程序员应该负责产品质量,他们有能力,也有时间。
第一个项目并没有因为“程序员还要负责质量”而耽误进度或造成功能“太少”影响到市场竞争力;第二个项目甲方后来坦然说“原定计划一年,没想到三个半月结束了”(此前他们自己曾经尝试2个人研发过一年,此外也了解另外两家竞争对手投入的情况)。
很多人一定认为上述经验有很大的局限性,比如对个人能力的要求很高,其实不然。第一个项目中,那些刚毕业的本科生和研究生与动辄工作5、6年乃至10年的程序员的水平不可同日而语;第二个项目中我本人当时工作经验也只有8年,其中做职业程序员的时间则只有4~5年左右,编码量仅在2万行左右。
所以关键还是方法,而不是人;或者说是“使用正确方法的人”足够了,“使用正确方法的正确的人”不是一个强制条件。
在后续的章节中,会谈到如何在一般情况下,推行这些方法。
此外还会提到,在这种方法大行其道的时候,专业的测试团队是否还有必要存在,以及还有“什么用”,以及应该如何工作。
相关推荐
更新发布
功能测试和接口测试的区别
2023/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11