对亚马逊与微软不同的软件测试方法,我已经在之前的文章中做了一些比较。本文会再做深入对比。
在2005年,我作为软件开发测试工程师加入到亚马逊之前,在面试时得知:测试正处于改进提升之中。你或许会问:之前是怎样的?好吧,答案是,测试一直被冷遇:1对10(1对7,或0对无穷多)的测试开发比,证明了这点。
测试开发比
“正在提高,恩?”我应该同意么?未必,但是我快速地意识到:我之前曾经常使用亚马逊网站,并跨越华盛顿湖[1]
2009年,我从亚马逊的西雅图总部横跨华盛顿湖,加入了微软。微软尊重测试,且认为软件质量高于一切亚马逊vs微软:一对一
在微软,我管理着一个测试开发比在1~1.5之间的测试团队。在亚马逊,一个测试对7个甚至更多的开发和微软相对,亚马逊只用几个小时来做测试,他们是怎么做到的?
1. 在亚马逊公司,并非所有的功能、服务、代码路径都会被测试到。原因是,它们必须精心安排、使用测试稀缺资源。但在微软,除了原型或“车库”项目之外的所有项目,都可以在每一阶段中,都经过完整的开发-测试-产品“三权对立”的团队管理模式。
不测试的代码降低了对测试人员的需求。相比较测试开发比例,或许,软件开发测试工程师们与被测代码的行数之比更有趣。如果排除亚马逊未经过测试的功能模块,它的测试开发时间比就非常接近微软的水平。
2. 亚马逊有“质量保证”团队,而微软拥有”测试“团队。然而,在亚马逊,质量保证除了测试外不参与任务其它事情。也就是说,微软和亚马逊应该互换各自质量保证团队的名称,因为亚马逊是更倾向于只“测试”的团队,而在微软,我们似乎更接近实际意义上的质量保证。以不参加设计或可测性设计的评审来节约时间,实际上却是一点也没有节约时间。
3. 在亚马逊,只做功能测试是非常普遍的,然而,性能测试也并非不做,或者由开发执行,或者优先级次之。
性能测试经常由开发团队来做,因此这些测试时间确实是有,只是不占用测试团队的时间而已。
4. 使用了一个较高运营成本的方法(开发随时携带一个寻呼机),一旦在线上发现一个bug也实质是线上测试的形式,而且,统计时间并把这些时间放到开发名下。
5. 更好的自我服务分析工具。好工具能更易分析和快速确定产品中的任何争议,这些工具监控服务器和服务,并发出报警。
通过自动化(和工具)来降低消耗……这才是真正的节约。
6. 廉价的人工测试。在列出这点时,我感觉很复杂,因为我曾经花费了大量精力来鼓励这些手动测试者们自动化,但是亚马逊公司在用户使用产品前,聘用了海外团队,仅通过产品的黑盒界面来点击它们,并发现了一些问题。
隐藏测试时间。当人们谈论亚马逊公司的测试开发比时,他们并没有将这些海外团队纳入在内。
期望
我的一个朋友在亚马逊公司是质量保证团队的管理者之一,他最近感叹道:
测试开发比被过份强调……我们原本要去做很多的事情来保证质量,但为了追赶进度不得不放弃很多测试,而遗漏了bug的时候又会得到埋怨。
因此,或许我的“亚马逊与微软:一对一”比较没有完全列出亚马逊和微软的差异,但是,我想说的是测试开发比并不重要。我最初写下上面几点是为了回答一个开发管理者的问题:为什么我们不能像亚马逊在质量保障方面消耗更少?对于质量期望和风险承受力,亚马逊是一个标准,而微软是另一个标准——这就是原因。
不足
我已经对亚马逊和微软的测试方法做了大量归纳总结,也就意味着这不能完全被其它团队照搬应用。若有不同意见,请在评论时畅所欲言。但是请牢记,这些归纳总结并非放之四海而皆准。并且,我希望大家能了解到:测试开发比并不重要。