QA已死,QA万岁

本文是翻译,版权归原作者所有


这不是针对刚开始,而是针对已经在应用写的。我最近经常被问到关于从两星期冲刺到一星期的建议,这样的对话发生了好多次。

客户:我们在用scrum模式,冲刺需要两周。我们想发布得快些,有建议吗? 我:QA也配备在冲刺里了? 客户:当然,冲刺里有基本的瀑布模型。 我:有建议了! 客户:太好了! 我:开掉你的测试人员。 客户:……

我是半开玩笑的。

我过去认为QA人员是第四个必要的技术岗位,随着组织成长还要添加更多名额。近10年我管理团队,都会确保每个团队至少有一名,去年我的观点发生改变了。我们的一个客户要求越来越快的发布,因此有些事情感觉不对劲。当我们保持填满QA角色时会遇到麻烦,问题还会随着发布时间表爆发。需要停一停了。

我们召开了一系列会议讨论我们的需要,以及告诉他们什么是应该做的。我们一致认为我们需要测试,我们也一致同意需要一个人来负责测试,也同意开发人员应该自己做单元测试,但是,关于设想或者他们应该做多少来集成测试的问题,引起了激烈的讨论。我们应该有个只做抽查的QA吗?人可以亲自重复测试吗?我们应该放弃手动测试,转而用一名首先是程序员的QA工程师代替?如果是这样,那么我们又该如何清楚地区分和其他工程师的工作?

这很难理解。我们花时间研究了大量的测试资源、书籍、blog和tweet。我们偶然遇到了关于Google早期形成的测试的《How Google Tests Software》,给了我们想要的答案,算是大获成功。天空开阔许多,我们过去一直错误地对待着测试。

我正在思索,但问题是有必要考虑QA的任何部分工作也是其他人的工作。目前我们还没有开始考虑工程师没有负责这部分工作,而是在考虑我们当然没有负责到底。工程师写一些单元测试,认为这就好了。管理人员把QA人员塞到工程师和每一次发布中间,并让他们完成工作。现实是,如果你把测试完全融入了代码的过程,那么你是否想完全避免瀑布模型——没有测试、但又都是测试。代码没有等到开始测试就完成了。

我们最初也是持怀疑态度的,当你走高空钢丝看到下面有张网时,这是令人不安的,对吧?一旦我们意识到,开发自己主导整个过程意味着钢丝实际上就变成了一座桥,没有什么好怕的。需要安全网的想法只是我们自己坏习惯带来的让人难忘的错觉。

当这样做的时候,你怎么知道是对的?你不需要任何测试人员,拥有测试人员将增加让其他人为你做测试工作的依赖,同样给版本过程增加了不必要的步骤。你首先成为测试人员。当QA需求属于战略规划组成的一部分、而不能被其他开发组分担时,单独的QA角色才应该存在。这多多少少取决于开发团队和产品,但大部分情况下,在四年当中的前三年都不是这样的。

自己做,设计一个工作流,让开发人员写自动化测试来测试自己的代码。开发人员会做出聪明的决定,你能够停止不必要的付出,最终你能够做完你的scrum当中的瀑布过程。我仍然建议持续发布不能没有这个方法,你可以不用专门的QA,从现在开始,你的代码、流程、开发、时间点,还有预算,都将因此而受益。

原文地址:http://css.dzone.com/articles/qa-dead-long-live-qa

译文:QA已死,QA万岁 》| 腊八粥