QA 部门将会消亡

工业革命始于 250 年前，在工厂中、农田里、矿井上，机器开始代替人类进行生产劳动。这在极大的促进了经济增长的同时，也深深的伤害了那些技能一般、无法找到新工作或者没有足够知识去转行的人，这与目前 QA 所处的境地有着惊人的相似。上世纪九十年代，由于互联网泡沫的出现，对软件开发的需求急速膨胀，这就需要大量 QA 来进行测试，以保证软件能够顺利发布。因此，像 Mercury Interactive 这样的测试公司便如雨后春笋般出现。然而，当互联网泡沫破裂时，公司纷纷消减预算，敏捷开发变得更加普及，自动化测试开始接手（QA 的手工测试）。就像工业革命时手工劳动者被机器所淘汰一样，以手工测试为生的 QA 也面临同样的困境。很多 QA 人员从质量保证转移到了需要编程技能的岗位上去，独立的 QA 团队消失，QA 融合到开发团队中产生了跨职能团队。柏林墙倒了。

让我们回过头来，看看以前我们是怎么开发软件的。自五十年代开始，瀑布模型被大多数软件开发团队所采用。开发人员首先对整个系统进行预先设计，然后集中编写代码，再把写好的软件交给 QA 进行测试，最后修复 QA 找到的缺陷。当进度压力总是伴随着开发人员，使得开发人员永远无法按时交付时，开发人员对 QA 的依赖也越来越强。恶性循环由此产生，雇佣的 QA 越多，开发人员就越多的依赖 QA，同时也越少对他们自己的代码进行测试，由此又需要雇佣更多的 QA……最后开发人员干脆就不测试自己的代码了。

这种方式对于开发人员和测试人员都是低效的，软件交付被拖延，最终产品无法及时交付到客户手中。

在互联网泡沫破裂的同时，2001 年 2 月敏捷宣言发布了，一种新的开发思想浮出水面。敏捷开发方法将开发人员带入了崭新的世界，适应变化和快速交付可工作的软件成为开发团队的关注点。敏捷还使得整个团队都参与到开发的各项工作中，特别是对开发人员测试的重视胜过 QA 的手工测试。随着敏捷更加普及，效率持续提高，对 QA 的需求变得更少，QA 已经有一只脚踏出了（软件行业）这扇们。

QA 越多，问题就越多

企业级软件开发是复杂并且昂贵的，管理层经常会发现无法达成计划的目标，从而需要决定如何应对这种情况。他们有三个选择来解决按时交付的问题。

1. 增加预算 —— 你不是每次都能给项目增加预算的，但如果可以，这或许可以帮助你按时完成项目，同时也需要考虑效果递减法则。
2. 减少特性 —— 开发人员和管理层一般都不倾向于让客户花同样的钱却买到更少的东西，对很多公司来说这不是一个可行的办法。
3. 降低质量 —— 虽然我们无法摆脱软件缺陷，但软件质量可能对任何产品来说都是最重要的部分，不幸的是，降低质量通常是人们最先选择的方案。

当开发人员面临压力（或者仅仅因为懒惰），而写出质量不高的代码时，管理层却在减少 QA 的数量。这就是问题的根本所在，也是敏捷将要解决的问题。

敏捷就是答案

随着敏捷方法的流行，开发人员和管理者似乎找到了构建高质量软件的钥匙。虽然两方之间仍有很多不同的观点，但至少大家都希望能够在最短的时间内将软件构建出来，当然管理者还希望尽可能少花钱。

互联网泡沫破裂后，随着经济形势的回落，企业也意识到他们需要降低软件开发的成本，但他们该如何减少 QA 部门的高昂花销呢？

敏捷软件开发让开发人员自己测试自己的代码，单元测试通过就表示单元级别的代码能够正确完成预期的功能，当然这还需要整个团队一起努力。产品经理负责保证产品能够满足客户的需要，开发人员和测试人员一起编写测试用例，然后开发人员编写单元测试来保证质量。构造良好的测试是保证软件交付的唯一方法，也是敏捷软件开发的核心，它可以保证代码按照开发人员的意图工作。在开发人员承担测试自己代码的职责后，QA 仍有存在的价值，他们需要寻找那些非常难以发现的问题。敏捷软件开发的一个支柱就是可以工作的软件，有些敏捷方法包含了测试驱动开发和开发人员执行的单元测试，而单元测试被用来检查你写的代码。通过这种保证局部的方式来让整体获益，以便得到持续的、及时的反馈，是一种快速、高效的抵御缺陷的方式。如果没有足够的单元测试覆盖，你很难敏捷起来，因为设计是在持续变化的，而变化会引入缺陷，如果无法在开发时发现这些缺陷，项目就会陷入困境。

单元测试－潜在的 QA 杀手

单元测试可以用来测试一小段代码，以保证代码做了正确的事，并能够被集成到整个软件系统中去。单元测试已经被证明可以达到 90% 以上的代码覆盖率，和 QA 使用的手工测试工具相比，构建良好、自动执行的单元测试可以随着代码一起演进，实时对代码进行测试。

我并不是说单元测试可以解决所有的开发问题，但作为测试代码（和促进设计）的工具，单元测试可以用更低的成本快速提升软件质量。自动化单元测试和测试驱动开发也是构建高质量软件所需要的，它们可以让开发人员更快速的适应新需求和其他的变化。

QA 手工测试可能是九十年代互联网泡沫时期的救世主，但公司纷纷意识到 QA 团队阻碍了对变化的适应。单独的 QA 团队只会拖延开发人员修复错误的时间，敏捷开发和单元测试则保证了开发人员写完代码时，软件就可以工作了。

我们将去往何处？

我打赌你一定很奇怪为什么我会选择这样一个标题，这可能与我是 Don McLean 的粉丝有关。此外，我觉得对于一篇关于 QA 是如何从软件开发的主力走向边缘的文章，这会是一个很贴切的标题，QA 即将消亡。可现实是，QA 部门依然存在于很多公司之中，这种情况还将持续多久？我个人认为这只是时间问题，测试的任务迟早会转移到开发人员身上，开发人员需要测试自己的代码，而不依赖于任何 QA 部门。

当然，还会有很多专业 QA 继续呆在这个行业之中，不同的是他们不再是独立的部门，而是成为开发团队的一分子。敏捷需要跨职能角色之间的沟通，推倒降低效率的部门隔阂。传统的 QA 部门只会降低开发速度，拉高开发成本，只有一种方法可以解决：开发人员测试。这不意味着不再需要 QA，而是需要 QA 重新定义自己的角色，与时俱进。不能再一成不变了，他们需要融入开发团队，在自动化单元测试中贡献价值；或者加入到产品管理中去，致力于定义让客户满意的产品。

当我们将（测试）职责转移到开发人员身上时，开发人员将会写出更干净的代码，构建出缺陷更少、质量更高的软件。这一切都取决于公司如何组织，以便在不降低质量的情况下降低成本。

关于作者

Eli Lopian是单元测试工具公司 Typemock 的创始人和首席执行官。在创建 Typemock 之前，Eli 曾在 AMDOCS（NYSE:DOX) 和 DEC 等国际公司工作，拥有 17 年的研发经验，并曾负责优化开发流程和改善开发环境与工具。

查看英文原文: http://www.infoq.com/articles/day-qa-dept-died

给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。