虽然我已经不太确定曾经多少次回答过这个问题，以及给出了多少个不同版本的答案，但可以确定的是，随着我在Google工作的时间越来越长，发现各种测试实践的不同之处也越来越多，答案一直在变化。这些测试实践总是浮现在脑海里，并幻想着有朝一日能够整理成书。直到有一天，Alberto （译注，Alberto Savoia，Google的测试总监，详细介绍参见本书序言中的Alberto部分），这个一贯认为所有测试相关的书籍都要为自己的存在找一个理由，否则就应该被扔掉做成纸尿裤的人，当他建议我应该写这样一本书的时候，我觉得时机已经成熟，是时候开始考虑写这样一本书了。
然而，我依旧还在等待。第一，我并非是写这样一本书的最佳人选。在Google，有很多我的前辈，我想先把机会让给他们来写；第二，我是Chrome和Chrome OS产品的测试总监（现在这个职位被我之前的一个下属担任着），我看到的只是Google所有测试实践中很小的一部分，我还需要去了解很多其他Google产品的测试方法。
在Google，软件测试团队归属于一个被称为"工程生产力"（译注：Engineering Productivity，也译为工程效率或工程生产率）的中心组织，这个部门的职责横跨开发测试人员使用工具的研发、产品发布和各种级别的测试，从单元级别的测试到探索性级别的测试。Google拥有大量针对互联网产品的共享工具与测试基础框架，服务于包括搜索、广告、apps、YouTube视频和其他我们在Web上提供的产品。Google已经成功解决了许多速度和扩展性方面的问题，使得Google作为一个大公司，却依然能以创业公司的速度来发布产品。正如 Patrick Copeland在本书的序言中所说的那样，拥有如此的魔力，Google的测试团队功不可没。
在Google, 软件测试团队是一个被称为工程生产力部门的中心组织的一部分。
Chrome OS在2010年12月发布以后，我把团队顺利地交接给我的一个直接汇报者，然后开始把自己的工作重点慢慢转移到其他产品上。在这本书刚开始准备的阶段，我使用博客的方式做了一些尝试，发布了第一篇"Google是如何测试的"的系列文章（注1：参见http://googletesting.blogspot. com/2011/01/how-google-tests-software.html）。六个月之后，本书终于完成，希望没有拖太长的时间。在这六个月的时间里，我了解到的Google测试实践比我过去两年在Google学到的都要多。现在有了这本书，谷歌的新员工们也可以通过阅读此书来熟悉Google的环境。
这并不是第一本介绍关于大公司是如何做测试的书籍。当我还在Microsoft的时候，Alan Page, BJ Rollison和 Ken Johnston合著了《微软测试之道》（译注，How We Test Software at Microsoft），我当时亲身经历了他们书中写的许多事情。Microsoft在测试领域独步全球，也是一个测试精英云集的圣地。Microsoft的测试工程师在各种技术大会中也是广受欢迎的演讲嘉宾。Microsoft的第一任测试总监--Roger Sherman，吸引了来自全球的测试精英加入到华盛顿的雷德蒙德（译注：微软总部所在地）。那是一个软件测试的黄金时代。
因此，Microsoft写了这样一本书来记录其发生的一切。
我没能赶上参与《微软测试之道》的编写，但是在Google却有幸得到这样的机会。我来Google的时候，其测试正处于一个蓬勃发展的上升期。工程生产力团队的员工数量正以火箭喷发般的速度增长，从几百人迅猛发展到今天的1200人。正如Patrick在本书序言中所说的那样，这种增速随之而来的是成长的烦恼，这也是他们最后的阵痛，此后这个组织开始了前所未有的井喷式增长。Google的测试博客每月吸引了成千上万的人来浏览阅读，GTAC（注2：GTAC 是Google Test Automation Conference的缩写，即Google测试自动化大会，参见http:// www.gtac.biz）大会也已经成了测试行业的旗帜性会议。在我来到Google不久之后，Patrick也得到了晋升，手下有十几个总监和工程经理直接汇报给他。如果你认为软件测试又进入到新的文艺复兴时期，那么Google一定就是位于中心的罗马。
这意味着Google背后的测试故事其实可以写成一本很厚的书。但问题是，我并不想这样做。Google之所以闻名一世，在于其软件实现的方法：简单和直截了当。或许这本书也可以保持这样的风格。
《Google软件测试之道》这本书的核心内容包括：详细讲述了作为一个Google的测试人员究竟意味着什么，同时也包含Google是如何解决软件在扩展性、复杂性和大并发方面的问题。如果想知道这些，阅读本书将是你的最佳获取途径。如果书中的内容还是不能满足你想要充分了解Google是如何测试的需求，互联网上还有更多的信息，你只需要"Google一下"。
关于本书由来的故事，不得不说的大概就是这些了。我也终于做好了准备，来讲述Google是如何进行测试的。随着越来越多的软件公司从桌面应用转向网络应用，Google测试软件的方法也很有可能成为其他公司的榜样。如果你已经读了《微软测试之道》，那么千万不要试图在这本书中找一些共同点。除了两本书的作者都是三个人，而且都是在讲述大型软件公司的测试实践之外，这两本书中所描述的测试方法可谓大相径庭。
书中关于谷歌的测试方法，很有可能成为其他公司竞相模仿的榜样，特别是那些从桌面应用转向网络应用的公司。
Patrick Copeland在本书的序言中解释了Google测试方法演变的历史，随着公司的不断成长，它也在不停地、有组织地进化着。Google是个大熔炉，许多来自其他公司的工程师被抛进来熔炼。在前雇主公司使用的技术，如果被证明效率低下，该技术要么被遗弃，要么通过Google的创新文化再进行改良。随着测试工程师队伍的不断膨胀，就有了许多新的想法和实践的尝试，那些在实践中被证明很有用的技术会被Google保留下来，并成为Google的一部分；另外一些被证明是负担的， 则会被抛弃掉。Google的测试者很愿意去尝试新技术，但有些技术一旦被发现并不实用，就会立刻被遗弃。
Google是一家以创新和速度为基础的公司，快速地发布有用的代码（如果失败，也只有少数早期用户会失望）、迭代地增加早期用户希望使用的功能（最大化用户反馈）。在这样的环境下，测试不得不变的异常灵活，并且在技能上要做许多前期的规划，只是不停地简单维护并不能真正解决问题。有时，测试和开发互相交织在一起，达到了无法区分彼此的程度，而在另外一些时候，测试和开发又是完全分离，甚至开发人员都不知道测试在做些什么。
有时，测试和开发互相交织在一起，达到了无法区分彼此的程度，而在另外一些时候，测试和开发又是完全分离的，甚至开发人员都不知道测试在做些什么。
贯穿Google的整个发展史来看，当前Google的发展速度只比创业初期慢了一点点而已。虽然Google创业已是很久以前的历史，但还是可以在一年内就做出一个操作系统、在几周就发布更新像Chrome这样的客户端应用、每天都在更新其网络应用程序。在这种环境下，很容易就可以说清楚测试并非"教条式的、强流程、体力密集型、耗时的"--这比定义测试是什么要简单的多，虽然本书一直在尝试解释测试是什么。有一件事是可以确定的，测试不能制造产生导致创新和开发过程变慢的阻碍。至少，这种情况不能出现两次。
Google在测试上的成功，不能简单地归结为其被测系统是小且简单的应用组合。Google软件应用的规模和复杂度与外面其他的公司一样。从客户端的操作系统到网络应用、移动端、企业级应用、商业应用、社交等各个方面，Google几乎无所不包。
Google的软件庞大且复杂，拥有数亿的用户，也是黑客们的攻击目标。绝大多数Google源代码都是开源的，这些代码对外公开，被外界所觊觎。多数代码是历史遗留代码，使用常规的代码审核来做代码评审。Google的代码服务于上百个国家，使用不同的语言，但是用户其实只是期望Google能够提供简单易用且"能够工作"的服务。Google的测试人员每天完成的工作，并非只是解决简单的问题，Google的测试人员每天都在面临不同的测试挑战。
