我们为什么要在很短的时间内迅速地完成测试呢？ 我一直这么认为，对于一个坏点子或考虑欠周的产品，即便再多的测试，也无法把它变成一个成功的产品。但如果测试方法不当，却会扼杀一个本来有机会成功的产品或公司，至少会拖慢这个产品的速度，让竞争对手有机可乘。Google当时正处于这样的紧要关头，测试已经成为Google持续成功道路上的最大障碍。此时，我们需要正确的测试策略来满足产品、用户和员工快速增长的需要，不拖慢公司前进的步伐。这样的测试策略会涉及大量的创新性方法、非常规的解决方案和独特的工具。当然，并非所有的策略都生效了，但在这个过程中，我们得到了宝贵的经验和教训，这对于其他像Google一样快速成长的公司来说也是非常有帮助的。我们学会了如何在保持正常的开发速度的同时，让大家充分意识到质量的重要性。本书将要讲述的，正是这个过程中我们的所作所为、所思所想。如果你想要理解Google是如何面对21世纪最新的互联网、移动和客户端应用等方面的测试挑战的，读这本书就对了。我本想自己为大家讲述整个故事，但James Whittaker和他的伙伴却抢先了一步，他们已经摸索出了Google测试的精髓。
关于这本书，最后要说明一点：是James Whittaker造就了这本书。他加入Google，深入了解了Google的文化，参与了重要的项目，并发布了Chrome、Chrome OS和其他许多产品。有一段时间，他变成了Google测试的代言人。但是，这本书与他曾经出版过的其他书籍略有不同，里面的很多素材都不是来自于他个人。他本人在Google测试演化过程中的角色，更像是一个描绘记录者，而不是一个参与贡献者。在你阅读这本书时，一定要把这一点铭记于心，因为James Whittaker很有可能会把所有的功劳都归功于他自己。
在Google由200人变成2万人的过程中，有许多人在我们的测试战略的形成和实施中做出了杰出贡献。James Whittaker肯定了他们的贡献，在本书中以访谈的形式将他们引入书中。然而没有一个人，包括我、James Whittaker，或者本书中提到的其他任何人的影响力，比得上Patrick Copeland，他是我们今天组织结构的架构师和Google工程生产力部门的负责人，所有Google的测试人员最终都会汇报给Patrick。作为执行官，他以自己的想象力创造了James Whittaker在本书中描述和贡献的一切。如果非要把Google今天的测试成就归功于某人，那这个人一定是Patrick。我这么说的原因不仅在于他是我的老板，而且还在于，作为我的老板，是他命令我这么说的！
Alberto Savoia是Google的工程总监，同时也是一位创新鼓动者。Alberto于2001年加入Google，那个时候主要负责AdWords产品的发布，同时他也是Google"开发者/单元测试"这一文化的主要缔造者。他还是《The Way of Testivus》的作者，以及O'Reilly出版的《Beautiful Code》一书中"Beautiful Tests"一章的作者。
来自James Whittaker的说明：我完全同意Alberto所说的一切。作为这一过程的描绘记录者，绝大多数的材料都归功于Patrick创建的这个测试团队。还有，我这么说并不仅是因为Patrick授权我写这本书。作为我的老板，是Patrick命令我写了这本书。
Patrick Copeland
谷歌测试和部署技术的架构师
我在Google的旅程始于2005年3月。Alberto在前面的序中也介绍了一些当时Google的状况：虽然公司规模还比较小，但已开始感受到成长带来的烦恼。当时适逢快速的技术变革之际，Web世界正在迎接动态内容的到来，而云计算也正在逐渐成为一种新的选择，取代当时还占统治地位的客户机-服务器架构。
在加入Google的第一周里，我和其他Nooglers（译注：New Googler，新加入Google的员工）一起，戴着三色的螺旋桨帽，参加了称为TGIF的公司每周例会，听创始人介绍公司战略。我对彼时的工作情形还知之甚少，有些兴奋，也有些害怕。在我之前10年的研发模式经历中，一个典型的交付周期可长达5年，这种经历在Google的速度和规模面前显得毫无价值。更糟糕的是，我觉得自己是所有戴着Noogler帽子的人中唯一的测试人员。当然，其他地方一定还有更多的测试人员！
我加入Google的时候，工程团队还不足1000人。测试团队大概有50名全职人员和一些临时工，具体数量我一直没搞清楚。测试团队当时的称谓是"测试服务"，工作重点在UI的验证上，随时响应不同项目的测试需求。可以想象，这并不是Google最闪耀的团队。
但这在当时已经足够了。Google当时的主要业务是搜索和广告，规模要比今天小得多，一次彻底的探索式测试足以发现绝大多数的质量问题。然而，世界在变，Web点击量开始史无前例地爆发性增长，文档化的Web正在让位于应用化的Web。你可以感觉到势不可挡的成长和变化，在这种情况下，规模化和快速进入市场的能力变得至关重要和生死攸关。
在Google内部，规模和问题的复杂性给测试服务团队带来了巨大的压力。在之前小型的、类同的项目里的一些可行做法，现在却让优秀的测试人员感到筋疲力尽，疲于奔命在多个急需救火的项目之间。更加火上浇油的是，Google在项目快速发布方面的坚持。是时候采取措施了，我面临两个选择，要么沿用这种劳动密集型的流程增加更多的人手，要么改变整个游戏规则。为了适应业界和Google发生的巨变，测试服务团队需要根本性的变革。
我也很想说自己是借助于丰富的经验构思出了完美的测试组织模型，但实事求是地讲，我从过去的经历中，学到的只不过是一些过时的做法。我所工作或领导过的每个测试组织都有这样或那样的问题。有问题是常态，代码质量很糟糕，测试用例很差劲，团队也问题多多。我完全清楚那种被技术质量债压得喘不过气来的感受，在那种状态下，一切创新性的想法都会被遏制，以免不小心破坏了脆弱的产品。如果说我在以往的经历中有所收获的话，那就是经历了各种错误的测试实践。
那个时候，以我对Google的了解，有一件事情是确定无疑的，那就是Google对于计算机科学和编程能力非常重视。从根本上说，如果测试人员想加入这个俱乐部，就必须具备良好的计算机科学基础和编程能力。
变革Google测试的首要问题是重新定位身为测试人员的意义所在。我过去经常在头脑中想象理想团队的模型，想象这样的团队是如何肩负起质量重任的，每次我都会得到相同的结论：一个团队能编写出高质量软件的唯一途径是全体成员共同对质量负责，包括产品经理、开发人员、测试人员等所有人。我认为，达到此目标的最好方式是使测试人员有能力将测试变成代码库的一个实际功能，而测试功能的地位应该与真实客户看到的任何其他功能同等重要。我所需要的能够实现测试功能的技能，也正是开发人员需要具备的技能。
招聘具备开发能力的测试人员很难，找到懂测试的开发人员就更难，但是维持现状更要命，我只能往前走。我希望测试人员能为他们的产品做更多的事情，同时，我希望演变测试工作的性质和从属，要求开发团队更大地投入。这种组织结构在当时的业界尚未实现，但我坚信它非常适合Google，我相信在这家公司，时机到了。
不幸的是，这种如此深刻、根本性的变革在公司里极度缺乏认同，极少有人能分享我的激情。当我开始推销这种关于软件测试角色的地位平等而作用不同的愿景时，我发现竟然难以找到一个人一起共享午餐！开发工程师们好像被他们将要在测试上发挥更大的作用这个想法吓着了，他们指出"这是测试人员的职责"。而测试人员也不买账，因为很多人已经习惯了当前的角色，维持现状的惯性导致任何变革都变得非常困难。
我毫不松懈地继续努力着，主要是出于对Google的研发过程深陷技术和质量债的困境的恐惧，一旦如此，长达5年的开发周期又会成为现实，而我本来已经很高兴地把它们留在客户机-服务器的世界里了。Google是一家由天才组成的公司，以创新为灵魂，这种企业文化与冗长的开发周期是不相容的。这是一场值得打的战斗，我说服自己，一旦这些天才理解了这种旨在打造一个生产线式的、可重复的"技术工厂"的开发和测试实践 ，他们就会改变看法。他们就会理解我们不再是一个初创公司，快速成长的用户群、不断累积的bug和糟糕结构的代码形成的技术债将会导致开发过程的崩溃。
我逐个接触各产品团队，寻找优秀的案例，试图为我的立论找到比较容易的切入点。在开发人员面前，我描绘了一个持续构建、快速部署的蓝图，一个行动敏捷、省下更多时间用于创新的开发过程；在测试人员面前，我激发他们对于成为同等技能、同等贡献和同等薪酬的完全的工程合作伙伴的渴望。
开发人员的态度是，如果我们招聘到有能力做功能开发的人，那么，我们应当让他们做功能开发。其中一些人对我的想法非常反感，甚至发信给我的主管，非常直率地建议如何来处理我的疯狂之举，这些信塞满了我的主管的邮箱。幸运的是，我的主管并没有采纳那些建议。
令我吃惊的是，测试人员的反应竟然与开发人员类似。他们沉湎于老的做事方式，抱怨自己在开发面前的地位，但又不想去改变。
我的主管对这些抱怨只有一句话："这里是Google，如果你有想法，尽管去做就是。"
于是我开始付诸行动。我召集了一批志同道合的骨干分子，组成了一个面试团队，开始招聘。事情进行得比较艰难，我们寻找的人要兼具开发人员的技能和测试人员的思维，他们必须会编程，能实现工具、平台和测试自动化。我们必须对招聘和面试的标准与流程做出一些调整，并向已经习惯了既有模式的招聘委员会做出合理解释。
