提问：书中提到Google正走向“免费测试”的观点：测试的成本接近于零。这对Google的测试工程师意味着什么？这个想法离现实有多远？

　　这在很多团队是现实，但takes a lot of objectivity to attain it。有多少测试人员愿意把自己搞到失业？你的工作可以被自动化/众包，并不意味着you have the stones to go through with it（你能坚持到底？）。本书的最后一章对这个问题做了比较详细的回答，所以我就不赘述了。我只想说，任何对云/Web应用以及移动平台做大规模功能测试的人，都是在浪费时间，只会拖慢整个团队。

　　提问：贯穿本书始终，你建议“不要雇佣太多测试人员”，未来测试工程师的角色在减少。对那些坚称你需要更多的测试人员、明确划分开发和质量保证的界线的组织，你想说什么？

　　为什么需要这样一条界线呢？Google已经证明，当写代码和优化代码之间的界线模糊了之后，结果是开发的速度会更快、潜在的缺陷会更少。雇佣太多的测试人员等于给开发更多的（质量上的）依赖，这对产品非常糟糕。我对于人们过分局限于他们的角色深感烦恼。“我是一名测试人员”是一种不健康的态度，“我是一名开发人员”也一样。只要人们不再过分受限于他们的角色，而是开始以（最终）产品为导向的时候，奇迹就会发生，每个人都应该聚焦于尽其所能做任何有利于开发出最好的产品的事情。

　　提问：一些读者可能会认为书中描述的很多方法难以推广，因为他们觉得你们能做到这个的唯一原因是“因为你们是Google”。对这类说法，你怎么看？

　　Google是怎样成为今天这个样子的？通过更快的、更大规模的编写软件。并不是因为Google成就了好的测试，而是因为好的测试成就了Google。这仍然是Google的强项，它可以更快的开发Internet规模的产品。

　　提问：对那些希望从事测试工作的测试分析师或者新的毕业生，如何应对测试角色的不断变化的技能要求，你有什么好的建议？

　　把测试当开发。拿到CS学位，拿到好成绩。认证和培训只能教给你简单的东西。（自己）学习更难的东西并擅长之。那些投机取巧的测试人员注定只会抱怨被当成二等公民，毫无长进。不想被那样对待？那就去掌握一等的技能。

　　提问：对那些看了这本书以后“希望象Google一样测试”的组织，你有什么建议？

　　当规模还小的时候，就建立一个集中的测试组织。招聘拥有一等技术技能的人。复制Google所做的全部，使之成为你的软件工程DNA的一部分。关注产品，而不是你的角色。不断的思考如何自动化日常重复性的劳动。众包一切可能的工作。

　　提问：这本书的主要读者是谁？你希望他们在读完本书之后学到哪些重点内容？

　　软件开发相关的任何人、每个人。希望人们理解（通过实践本书所讲的技术）不会使你做到完美，但是可以做的更好。（OR：这本书难以做到完美，但本来可以写的更好）

　　本文出处：http://www.infoq.com/cn/articles/how-google-tests-software