使用QA降低被交付产品的成本,提高编码生产力,识别质量变化动向,减少缺陷,但不要用QA提高质量。适用于雇用员工通过测试而不是通过编码来提高生产力的情况。总是通过QA从过去的失误中获取经验。当雇用一个QA人员得到的价值大于一个程序员工作的价值时,就应该雇用一个QA人员。
可以减少成本,提高交付的总量和速度,减少重复出现的缺陷数量。QA并不能提高系统的质量,因为不能在系统中测试质量。如果使用正确,QA可以提高生产力,同时降低成本,最重要的是,在组织的高速增长期,QA可以保证缺陷增长的速度比组织发展的速度慢。
标题很令人不快,还有点儿容易引起误解和争议,但目的是引起人们的思考和讨论。当然,有一个团队负责产品测试并识别产品中的缺陷是很有意义的。问题在于,不应该只依赖于这个团队来发现所有的缺陷,就像航空公司不能只依靠空乘人员确保飞机安全着陆一样这个观点的核心是一个简单的事实,即不能在系统内测试系统的质量。测试只能发现开发过程中制造的问题,它的结果是发现被你毁掉的价值。
找回这种价值从而要求重新编,增加交付的每个工作单元(功能)的边际成本。测试或执行测试的团队通常不会发现能够创造额外价值的潜在机会。
不要误会了,QA在编程组织内当然是个重要角色。当公司在超高速发展需要扩展系统时,QA的角色更加重要。QA的主要任务是帮助公司发现产品的问题,且花费的成本要比程序员执行同样任务的成本低。这个任务行生出的两点好处是,提高了编程的速度,增加了缺陷的识别率。实现这些好处的方式,与工业革命减少制造成本并提高单位生产力的方式类似。让编程过程流水化,让程序员主要专注于产品开发(当然还有单元测试),从而减少了每个程序员花费在设置和结東测试流程上的时间。
现在,程序员每天都有更多的时间专注于应用的开发了。通常这样做的结果就是可以发现每小时的产量和每天的产量都增加了。编程速度提高的结果是降低了单位成本。此外,一个好的的QA组织的单个人员成本通常比编程组织的单个人员成本低,从而可以进一步降低成本。最后,测试组织的重点在于发现缺陷,所以不会产生发现自己代码中的问题(很多程序员会这么做)或隔壁搭档的代码中的问题时那种纠结。
当雇用一个QA人员就能得到相当于一个或多个程序员的生产力的价值时,就应该雇用QA人员了。这个数学计算相当简单。如果你有11个程序员,每个人花费大约10%的时间执行测试活动,而这些活动完全可以由一个QA人员完成,那么雇用一个QA人员,就可以得到相当于1.1个程序员的生产力。通常,QA人员的成本比程序员低,这就相当于用一个程序员成本的80%或90%,得到了1.1个程序员的生产力。
不过有一点我们没有明确说明,即在超高速发展的公司中才会充分体现QA的价值。这并不是说在发展稳定的公司或低速发展的公司中QA没有价值,而是说在每年研发人员数量都会成倍或更快地扩展的情况下,QA更为重要。在这种情况下,很难强制性地实施标准。组织内在职时间较长的程序员没有时间保持并实施现有标准,更没有时间识别扩展、质量或可用性需求所产生的对新标准的需求。对于每年成员数量都会翻番的团队,第三年的开头,半数现有的“有经验”的团队成员入职时间其实只有一年或者更短
这就是这条规则放在吸取教训这一章中的原因。设想一下,部门经理要花费几乎一半的工作时间面试和雇用新程序员,而且每年都有一半或者更多的程序员入职不足一年。可以想象一下,现有的在职时间较长的程序员要花费多少时间培训新员工,如何使用源代码管理系统,编译环境是什么,生产环境是什么,等等。在这样的环境中,根本没有时间验证编写的东西是否正确,从而导致发布给QA(但希望不是生产部门)的错误量明显增加。
在这种情况下,培训程序员是QA的工作,要教会程序员从质量角度看发生了什么,是在哪里发生的,这样才能让他们信服并吸取经验。这时的QA就成了一种工具,帮助研发人员认识到哪些错误在反复出现,它们出现在什么地方,最重要的是让他们学会将来如何避免出现这些错误。QA可能是唯一一个能发现反复发生的问题的部门。
新的程序员,因为没有见过他们所犯的错误,也不了解这些错误的影响,所以可能不仅会继续犯错误,还会把这些错误的方法当成一种习惯。更糟的是,他们还可能把这些坏习惯教给那些新来的程序员。最初只是导致缺陷数量小幅增多,而最终会变成一种恶性循环。当噩梦注定要发生并且就在他们面前时,每个人都会忙于查找造成质量噩梦的根本原因。这说明他们没有从过去的错误中吸取教训
QA必须发现正在发展中的组织在哪些地方反复出现问题,并创建个环境,在这个环境中讨论并消除这些问题。最后要说的是,QA部门最重要的价值在于它可以帮助研发部门从失败中吸取教训。要明白,他们不能在系统内测试质量,也不愿意扮演棒球比赛中接球手身后的安全屏幕,站在接球手后面,让没被接到的球停住。优秀的QA部门会搜索研发部门制造的系统故障,这些故障会在将来造成质量问题。这不仅仅是创建网站制作燃尽图和创造发现修复率,而是深入探究,发现主要问题和它们的源头。一旦发现了这些问题,QA还要提出如何解决问题。
>>> 查看《不要依靠QA发现失误》更多相关资讯 <<<
本文地址:http://www.phpweb.com.cn/news/html/3480.html