谷歌如何测试翻译版（2）

前言（二）Forword by Patrick CopeLand

　　我是2005年来谷歌的。那个时候正好是互联网技术快速变革来临的时候，并且云开始通知客户端-服务端的世界。那个时候的谷歌也是高速发展的时代。

　　我加入谷歌时，工程师只有1000来人。测试团队大概有50名全职员工和一些临时员工。该团队主要集中在UI的验证，并且根据需要进入各个项目。你能想象在谷歌，它并不是一个光荣的队伍。

　　但在那个时候，它已经够用了。谷歌的主要业务是搜索和广告。那时候的谷歌比现在的规模小很多，功能测试基本就能涉及大多数质量的角落。但是世界是在慢慢变化的。用web的用户越来越多，基于文本的web逐渐被基于应用的web取代。你能感觉到必须需要改变。

　　谷歌内部，复杂的和具有一定规模的问题都被认为和测试团队相关的。各种小的同类项目需要工作的很好，导致出好的测试人员不停地从一个项目迁到下一个项目。由于谷歌一贯坚持快速发布，就不得不在扩大手工测试或者是改变测试的规则中做选择。测试团队需要一个激进的变革来适应正在发生激烈变化的谷歌。

　　我很想说我借鉴了大量的经验，同时想象出了完美的测试组织；但是事实上是我的经验反而让我更多的用错误的方式做事情。我工作过的每个测试组织都或多或少的不正常。东西总是出错。代码出错、测试出错，整个团队在出错。我意识到在质量和技术债务下，每个有创意的想法都会无法实现，因为他可能打破他依赖的脆弱的产品。如果要说我的经验告诉我什么，那就是怎样不做测试。

　　但是，在谷歌，我们是尊重计算机科学和编程技巧的。所以加入谷歌的测试人员，他们必须具有良好地计算机基础和一些编码的实力。如果我在谷歌要改变测试，我就需要改变一个测试人员的定义。我尝试想象这个完美的团队和这个团队如何在以下前提下：只有当整个团队是对质量负责的时候，一个团队才能写出高质量的软件，承担产品质量。这意味着产品经理，程序员、测试人员，每个人，都要对产品质量负责。在我看来，最好的方式是测试人员能够对一个代码的特性进行测试。而这个测试特性应该和用户能看到的特性是等价的。这项技能，导致我需要能编码的测试。然而雇佣会写代码的测试是很困难的，而要能找到能进行测试的开发者就更困难了。我想要测试人员能为产品做更多的测试，同时我想改进测试工作的特性和所有权，这就意味着要从开发团队那里寻求更多的投入。

　　不幸的是公司里很少有人支持我的想法。当我开始实施我的关于测试的平等但是却不同的观点时，我发现很难找到一个伙伴。需要工程师投入更多的测试，这个观点，让工程师们吓到了，他们说“这是什么的测试啊”。而在测试团队里，也同样难以接受，很多人已经习惯了他们的角色。因而要想改变，变得非常困难。

　　我想推动这件事情，是源于害怕谷歌的开发流程会因为技术债务和质量问题而陷入困境，那样我就得重回我痛恨的老的每次需要5年一个周期的客户端-服务器的开发模式。谷歌是一个非常专注于创新的公司，并且创业时期是不适宜长的开发周期的。因而这是一场值得拼搏的战场，我相信自己，只要这些天才们理解了开发和测试的实践是为了一个精简的可以重复的技术工厂，他们会回到我身边的。他们将发现这不仅仅是一个开始，特别是随着我们的用户越来越多，bug越来越多的时候。

　　我参观各项目，试图找到一个切入点。对于开发者来说，我描绘了一幅持续集成、快速部署和开发的蓝图，可以进行更多的创新。而对于测试人员，我提倡他们有和开发一样的技能、一样的贡献和一样的补救措施。

　　然而开发者觉得如果我们要雇佣的人有熟练的技能能够开发功能，那么我们应该让他们开发功能。因而有些人发了很多邮件给我的经理，来反对这件事，认为我疯了。幸运的是，我的经理忽略了些看法。

　　不过，出乎我意料的是，测试人员也是类似的反应。他们是这件事的既得利益者，埋怨他们的处境，但是却基本上不采取任何行为来改变。我的经理面对这些投诉的回应是：这就是谷歌，如果想做什么事情，那么你就做吧。

　　因而我就去做了。我召集了一大批志同道合的骨干来做这事，同时我们开始面试报考的人。这是很艰难的一个过程。我们寻找有开发技巧，但是有测试思想的人。我们想要的是能编程、愿意应用开发工具、基础设施和测试自动化的人。我们不得不重新考虑招聘和面试，并把这一过程解释给已经习惯了旧有模式的招聘委员会的同事听。

　　前几个季度进展艰难。好的候选人总是在审批过程中被筛掉。也许是因为他们解决一些神秘的编程问题比较慢，或者没有做好一些事情，而这些事情是某些人认为很重要但是和测试技能没有任何关系的的事情。我知道招聘会是很困难的，每个星期招聘完后都要写招聘的理由。这些最后都要获得谷歌联合创始人Larry Page的批准。他批准了足够多的同事加入，我们的团队开始成长。我常常猜想是不是每次Larry听到我的名字，他都在想，又要雇佣测试人员了！

　　当然，这次，我已经高调的做尝试，导致我们没有其他的选择，只能去努力表现。整个公司都在观望着，而失败会是灾难性的的。这对于一个小的测试团队，寄予了太多的期望。但是在我们努力聘请，并且我控制了临时工的数目后，我注意到变化在发生。稀缺的测试资源，导致开发者需要做更多的测试工作。很多团队都面临这个挑战。我想如果技术一直是一层不变的话，那么仅此这点也让我们离我们想要的更进一步了。

　　但是技术是不断更新的，开发和测试的规则需要快速的改变。静态web内容的时代已经过去了。浏览器仍然在持续更新。而围绕浏览器的自动化已经比浏览器的更新进度要落后一年。开发者们面临着巨大的技术变革，与此同时测试也成了一个开发的问题。我们缺乏正确的手动测试这些应用程序的能力，也非常缺乏自动化的能力。

　　开发团队的压力很大。谷歌开始购买有丰富动态web应用程序的公司。youtube，Google Docs等等来扩展我们内部的基础能力。我在测试领域面临的问题同样艰巨，就像比让开发团队写代码来测试同样困难。我试图解决一个测试问题，而这个问题却不能被孤立的来解决。测试和开发，当被当做是不同的学科，甚至是不同的问题时，这种观点是错误的，而固定的测试团队指挥让我们往这个错误的方向更近一步。

　　终于事情慢慢有进展了。而起因是因为雇佣了一群匆忙的人，他们在制造这些进展。到2007年，测试条款有了更好地定位。我们管理着发布周期的最后阶段。开发团队意识到他们能把我们当做是他们的合作伙伴。但是作为一个下游部门，我们一直被传统的QA模型给困扰。因为尽管我们执行的能力不错，但那不是我们想要的。我需要带领测试沿着正确的方向，但是我们开始测试时，总是开始的很晚。

　　我们弄了个“测试认证”的概念（这个书后面后续会有介绍），我们给开发团队做咨询，帮助他们写出更好地代码结构和单元测试。我们构建工具和教练团队来进行持续集成，以便于产品总是可测的。我们做了无数的小改进和调整，来去除早期的风险，这些做法书上以后会做介绍。然后，有个事情一直没有统一：开发还是开发，测试还是测试。Many of the ingredients for culture changewere present, but we needed a catalyst for getting them to stick.

　　当我环顾组建的测试团队，它的成员都是程序员；我意识到测试仅仅是我们做的一部分。我们有工具团队，负责从构建源码到构建基础设施报bug。我们是测试工程师、发布工程师、工具开发者和顾问。而让我印象深刻的是我们工作的很多非测试的部分，影响着生产效率。我们的名字虽然已经叫做测试服务团队，但是我做的其实更多。

　　因此我决定让它官方化，我把团队的名字改成为Engineering Productivity（工程部）。随着名字的变换，文化业发生了调整。人们开始谈论生产效率，而不是谈论测试和质量。生产率是我们的工作；测试和质量是开发过程中每个人都要涉及的工作。这意味着开发者要自己负责测试和质量。而工程部则负责让开发和这两件事情仅仅结合起来。

　　起初，这个想法更多的只是一种期望，我们的座右铭“accelerating Google”起先只是空洞的口号。但是随着时间的推移和通过我们的行动，我们兑现了这些承诺。我们的工具让开发者更快速的开发，同时我们也变化为帮助开发清除他们面临的障碍和问题。我们的工具能帮助开发自己写测试，并一次次的构建中看到测试结果。测试用例不再被隔离执行。测试结果会发布出来，并后续版本继续积累，这样他们就成了发布版本的公开的记录的一部分。我们不只是要求开发涉及测试，我们也让他们做起测试来变得更容易。生产率和测试的差异终于变为了现实：谷歌能更容易的创新，因为没有技术债务的积累。

　　那结果呢？本书后面会有介绍，我就不多做透露了。作者煞费苦心的总结了一套核心实践。但是我们很多方面都是成功的：从数量级、减少构建时间、测试自动化、开源测试工具。在我写这个前言时，工程部已经有1200个工程师，远远超过我2005年加入谷歌时的人数。我们的宗旨“accelerating Google”已经成为了工程师文化的一部分。

　　--完结--

　　*注：Patrick Copeland是谷歌测试老大。所有测试人员都要汇报给他。他的上级是Larry Page,Google’s Co-founder and CEO，他在谷歌之前，曾在微软做了近10年的测试经理。他是个频繁出席公众场所的演讲家。