早在2005年时，谷歌也存在大量的手工测试工作。由于团队规模快速增长，业务系统越来越复杂，测试工程师忙得不可开交。而且，生产问题也不断出现，很多开发工程师天天处于“救火”状态。于是公司开始建立工程师质量文化，它的做法也可以总结为
第一步：
定义想要做的事情提高代码质量，减少生产问题，减少手工测试工作量，快速发布软件。
(思考一：定义人是要写代码的人？还是需求方（产品）？由谁做审核？)

第二步：
定义期望的做事方法
开发团队编写自动化测试。
主动运行自动化测试用例。
做代码评审。

第三步：
提供相应的培训在公司范围内组织代码设计与自动化测试培训。
(思考二：以前端代码为例 eslint 的规范是由培训者定义还是由团队成员老决定？)
为每个团队指派自动化测试教练，帮助团队提高自动化测试技能。

第四步：
做些必需的事情来强化那些行为建立团队测试认证机制（test certified mechanism），共分3个大级别，12个子级，用于评估每个软件产品团队的测试成熟度。
通过每个季度统计各级别上的团队数量分布，来评估自动化测试文化在公司内部的进展程度。
建立自动化测试组（test group）和测试教练组（test mentor），帮助团队提升自动化测试能力。
建立代码评审资质证书。
(思考三：评审资质需要怎样的考核？)
代码合入版本仓库之前强制做代码评审。
代码评审之前，必须运行自动化测试用例，并提交报告给代码评审者。
(思考四：评审者来code自动化测试吗脚本？)

当然，这4步并不是非常容易。谷歌的执行过程也花费了4年的时间，其中还有很多非常具体的细节，在这里不再展开讨论。

										----------   摘自乔梁老师 《持续交付2.0》