提问：书中提到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：这本书难以做到完美，但本来可以写的更好）