《谷歌软件测试之道》作为测试入门书籍，里边有很多观念至今看来也不过时，今天小编带大家一起回顾谷歌的测试，相对显眼的质量管理理念是：

预防胜于检查和补救：本书第一章节就介绍到“质量不等于测试”，即强调软件质量是一种预防行为，而不是测试行为

一次性把事情做对：强调软件质量是所有人的事，而不仅仅只是测试团队的事！强调应该从设计之初就考虑到软件应用的业务逻辑、代码code规范、测试流程安排方法、以及在开发过程中不断变更需求的应对方案。进而引申出为了减少反复变更的代价，通过不同版本，不同的测试类型，来控制需求变更、代码变更对后续质量的影响，不断的对产品进行监控，开发与测试融合协作保障开发代码质量。同时对产品各个环节的人员均需对质量进行负责，即任何一个环节都需要对自己的输出进行负责

全面的质量管理：在本书中所有章节都在介绍Google的流程中，对于质量的管理，全过程，全员参与，确保软件快速的迭代情况下依然以质量为核心的管理途径

持续改进：本书也涉及到较多的与Google中高级测试员工的访谈中，均体现流露出对于流程中的不断改进实践，以达到当前的一套管理流程。在本书的最后，“Google软件测试改进”章节中，也依然对于当前流程中存在的较大的问题，提出改进的思考，作为持续改进的一个方向。

记忆颇深的是，在过往的工作经历中，这些质量管理理念从我们入职开始即被一直灌输，被要求。而我们值得学习借鉴的就是将质量融入到每个人的工作过程中，确保一次性把事情做对，预防远胜于检查和补救，从全流程上对质量进行管理。做好这些我们的质量才能进一步得到改善，在满足质量的同时，又能确保进度，提升用户满意度。

关于流程

除了重点讲质量和角色对于质量的把控之外，更着重地介绍了把人融合到流程中，从流程上对于质量的把控。

Google流程中，通过爬/走/跑的方式告诉介绍他们在流程上对于版本的控制，其主要目的就是给我们系统尽早提供一个测试验证的良好机会，与自动化测试那里得到的反馈一样，我们每天能从内部用户哪里得到关于这些版本的质量反馈。

针对这样的版本区分下，值得我们借鉴的是我们通过这些版本，从技术实现上，解决流程中无法快速迭代验收的问题；并且，除了流程源头上的帮助“测试尽早介入”（如HW软件流程中的TR2点即测试开始介入），也在版本开发阶段确保“测试尽早介入”，同时减少开发过程中的需求变更带来的影响，也就意味着开发计划和测试计划能跟随需求特性的实现实时更新，资源实时调整。

关于测试管理

首先关于工作方式。有幸，在初入职场的新员工培养中，我得到的一手培训就是先了解你所负责的任务。于是养成的习惯是，去到任何一个项目，首先都是先了解这个项目背景是什么，框架组网是怎样的，达到什么样的效果，目前存在什么样的问题等等由粗到细的了解。

之所以提起，是在关于“Gmail测试工程经理Ankit Metha的访谈”中，以之相契合的是，他的工作方式就是：开始接手一个新测试项目时，主要是倾听，了解整个项目，比如为什么你会进行这些测试，为什么你会想到这些用例，为什么你选择把这个任务自动化而不是那个任务，为什么我要投入做工具？。当然更重要的是，他提炼出的：“最有力的问题就是“为什么””，告诉我们在做项目的过程中，多问几个为什么，除了Why，还有What，When，Who，Where，How，How long，也就是5W2H，猛然惊吓：喔，又忘记这么做了。感叹：这种工作模式，在任何时候，任何岗位都适用，但往往我们在工作过程中，容易出现急于求成，而忽略这些细致的考虑

我们在技术岗位上做团队管理的时候，如何能让自己关注最重要的事情，如何让自己拥有合适技能的人，让团队成员保持正确的工作态度，并做正确的事情？以达到解决难题的能力呢？

谷歌的答案是：测试工程经理如果对产品有深入的理解，就能清楚地找到最高优先级的工作，对相关模块进行合理的覆盖。对成员足够了解，就能根据具体的测试问题安排具有最合适测试技能的员工。其简单分类为：

了解你的产品。从用户界面到后台数据中心实现，TEM都应该对自己负责的产品做到了如指掌。即相关项目中最强的产品专家。知人善用。测试工程经理是产品专家并理解要有哪些工作需要完成。但真正完成工作的人是TE和SET，因此了解这些人的能力很重要。