公司在DevOps转型，测试人员该如何发展……
如果你是测试人员，这篇文章会帮你看清软件工程的发展，是测试人员未来所需要的能力～
在谷歌，EP团队就是谷歌工程生产力部门，它由原来的谷歌测试团队发展而来。其发展历程如下图所示。
2001 年，谷歌有200多名软件开发工程师（SWE）时，但只有 3 个手工测试人员，主要做手工测试。
2005 年，谷歌有1000多名 SWE 时，一共有50 多个手工测试人员，并分散于各产品团队之串。而测试人员的定位是提供测试服务（ Test Service ），主要为手工测试。假如某个测试人员会写代码，最终也会被拉去做软件开发工作。测试人员虽然一直抱怨原有的工作方式（繁重且重复的手工测试），但却不愿意做出任何改变。产品开发团队决定“是否发布产品？什么时候发布产品？”。
2006年，谷歌开始了它的软件研发模式转型工作，也就是现在业界所说的测试左移活动，即 Shift Left 。所有的测试人员归属于同一部门，仅向谷歌重要的产品派遣测试人员，逐渐与产品开发团队成为共同保障产品质量的伙伴关系，在发布产品时，开发团队会征求测试人员的意见。此时，其定位是“QA”。
2007年，举办了首届GATC（谷歌自动化测试大会）。此时，测试人员的招聘标准已经完全改变了，即：候选人要具备代码开发能力。而团队的组成也发生了相应的变化，测试角色分为：测试开发工程师（Software Engineer for Test）和测试工程师（Testing Engineer）。其具体职责如下所示。
2010年（如果我们以软件产品发布时间点为分水岭的话）谷歌基本完成了发布前的研发模式转型（Testing Shift Left），其小型自动化测试用例数量巨大，所有项目的代码行覆盖率中位数也达到了65%左右。下面是2012年，对谷歌一名SET的访谈记录。你可以管中窥豹，了解一下当时SET所做的工作。
2013年，谷歌已建立了相对完整的自动化测试体系，工具基础设施覆盖了下图灰色方框中的内容：即提交/测试/发布活动。然而，他们发布，从Idea产生到功能上线的整个时间并没有缩短，所以他们把其视野放大到了产品研发的整个过程，如下图所示。
如果我们把2013年以前关注的内容叫做“EP1.0”的话，那么，2013年以后就是EP2.0时代。此时，谷歌原来的测试部门已经不存在，而是成为了工程生产力部门。
2016年，已主办十年之久的“GATC”大会也因工程生产力部门的定位发生变化而停更了。
谷歌测试人员两条最主要的职业发展路径如下所示。
喜欢软件开发工作的测试人员，从 TE 到 SET ，然后再转岗到 SWE。
喜欢解决产品问题的测试人员，从 SET 到 TE，然后再转到 PM。
在谷歌，TE 与 SET 在岗位上并没有非常严格的区别，只是工作重点不同，因为所有测试角色都必须有软件工程开发能力。
现在，谷歌也会招聘 TE ，大部分 TE 主要分布在硬件团队和安卓产品团队。而工程生产力部门全部是 SWE 了，只是，这些 SWE 的主要责任是开发提高SWE生产力的工具平台和基础设施，被叫做SETI，Software Engineer on Tooling and Infrastructure。
谷歌 SETI 岗位的招聘要求。
基本要求：
计算机科学或相关技术专业学士学位或同等实践经验。
某种或多种通用编程语言进行软件开发的经验。
具有以下一项或多项工作经验：
测试自动化
代码重构
测试驱动开发
构建基础设施
优化软件、调试、构建工具和测试框架。
加分项：
1. 计算机相关专业硕士或博士学位
2. 有一种或多种通用编程语言的经验，包括但不限于：java、C/C++、C语言、Object-C、Python、JavaScript或GO。
3. Python、Perl、Shell或其他通用语言的脚本技能。
工作职责
领导/参与从软件设计到交付这一过程中的相关工程工作，围绕开发人员和工程生产力和速度，解决相关的复杂技术挑战。
设计和构建高级的自动化构建、测试和发布基础设施。
推动代码健康、测试和可维护性方面的最佳实践的采用。
分析和分解复杂的软件系统，并与跨功能团队合作，从而影响可测试性的设计。
