《Google如何做测试》一书由James Whittaker， Jason Arbon 和 Jeff Carollo 三位作者合著而成，正如其封面上描述的那样，看起来充满了知识性和趣味性，在其背后则揭秘了大型技术公司Google，是如何应对和处理软件测试的复杂性的。

　　近此书的作者们关于此书与提问做了一次对话访谈。

　　提问：写著本书或与大家分享Google测试方法的主要动机是什么？

　　一群在Google工程生产力团队（测试人员属于这个团队）的人，一直在讨论如何出一本书。我们已经召开过一次会议并有一个博客，所以写书的需求非常清晰。但讨论如何写一本书总是比真正要去写一本要容易的多，因此我们一再推迟。终我们三个意识到问题的严重性，并开始去写。有趣的是，当我们快要完成的时候，更多的Google工程师也开始对如何参与进来产生了浓厚的兴趣，本书的“Google工程师访谈”部分是他们的贡献，许多工程师还成为出版社的官方审核人员。Google一直在云软件的测试方面处于，这本书的出版使得Google正式处于地位。

　　提问：本书重点详细地介绍了工程生产率和软件开发测试工程师这个角色， 这些从事这个角色的工程师工作在各自不同的项目中，主要从事可测试性和测试工具集的工作。你是否认为这是Google改善其测试实践的一项重要改变？

　　其实有两个重要的变化。第一，正如你指出的那样，测试角色在其产品项目自身的集中管理之下。这样可以保持测试不被沦为二等公民，在工程生产力形成之前。第二，是测试技术角色的集中管理。对于那些有这良好代码能力的人来说，Google使得测试成为一项开发任务，它得到开发者的尊重并让他们也参与进来。无论如何，在你离这种模式走太远之前，读一下后一章，一旦Google形成了面向质量的开发文化之后，工程生产力方面的需求会改变，去创建这种文化也不再重要。

　　提问：整书花费比较大的篇幅介绍不同的测试技术与测试工具（既有公司内部的，也有开源的）。对于一个团队来说，创建自己工具背后的动力是什么？ 对于测试工程师或软件工程师来说，怎样时刻保持对新测试方法和状态的了解？

　　背后的动力非常简单，市场上根本不存在可以满足我们在自动化测试方面需求的工具。Google全部从外界采纳的“工具”是众包。我认为获取工具的好途径是通过开源（Google也一直在支持开源）。商业的测试工具总是滞后半拍，因为其背后没有社区的强大支持。成为开源社区的一员，特别是要了解Selenium、Web Driver和uTest他们在测试工具方面正在做什么，这也是跟随新前沿测试状态的好方法。

　　提问：整书很少提及敏捷的概念，尽管许多Google的工程方法都基于敏捷原则与实践。Google是如何看待其工程方法与广大敏捷社区的对比？

　　Google不想成为敏捷社区的一员，也不没有使用Scrums，Scrum masters这些类似的术语。我们已经制定了快速变化的内部流程，这也是非常敏捷的流程，不能陷入别人关于什么是敏捷的想法中。当你必须停下来去定义什么是敏捷和你的敏捷是属于哪一种的时候，你已经变得不再敏捷了。

　　提问：书中讲到的测试认证项目（Test Certified Program）貌似混合了游戏化和测试成熟度模型。对于这类项目如何激发人们的兴趣而获得成功、如何跟踪新的测试技术和流程， 你有什么建议吗？

　　给开发提建议的风险几乎不亚于评价他们的工作。测试认证两者兼顾，必须要谨慎行事。做成这件事的关键是，首先要有一个正确的模型，例如我们在这本书里所提供的，经过实战、测试和优化的模型，可以作为你的起点。其次，确保用你们好的测试人员去推广和执行这个项目，因为如果在落地过程中（由于执行不力等原因而）失去开发团队的尊敬，那是我们所不能承受的。

　　提问：测试工程师可能是接近传统的、在很多组织中使用的测试分析师的角色，尽管有些人会提出反对意见，说这个角色仍然很技术化（所以和传统的测试分析师还是不同的）。会不会存在提高现有测试人员的技能去适应这个新角色的挑战，尤其是在技术技能方面？

　　问题在于规模。两类技能兼备的人才一定有，但当然不是要多少有多少。实际上，雇到愿意学习编码的测试人员，比雇到愿意学习测试的开发人员要容易。