原文链接：https://testing.googleblog.com/2016/03/from-qa-to-engineering-productivity.html
原作者：Ari Shamash

从质量保障到工程生产力——看谷歌 QA 的角色演进

在谷歌的早期，一小部分开发工程师建造、测试和发布了软件。但随着用户基础的增长和产品的激增，工程师们开始专注于各自的角色，在开发过程中不断地展现各自的创造力：

• 测试工程师 (TEs)——测试新产品和系统集成。
• 发布工程师 (REs)——将产品代码发布到生产环境。
• 现场可靠性工程师 (SREs)——7x24 小时管理系统和数据中心。

本文重点是质量保障的发展变化和工程师们在谷歌的角色演进。另外 REs 和 SREs 其实也在不断进化，这个我们以后再说。

最初，团队严重依赖于手工测试。当我们开始尝试自动化测试时，最先想到的是在前端的 UI 自动化上发力。这在当时是有效的，因为谷歌的规模还很小，所以产品集成的测试也很少。然而，随着谷歌的快速成长，越来越长的手工测试周期严重阻碍了产品的迭代和发布进度。并且，由于我们有时会在项目开发周期的末期发现一些 BUG，但此时再修复这些 BUG 所耗费的时间成本远远高于在项目前期发现并修复。所以，我们最终决定通过自动化测试来推动测试向项目流程的上游渗透，将更多的问题在更前置的项目流程环节发现并解决。

随着手工测试过渡到自动化流程，谷歌开始出现两个独立的测试角色:

• 测试工程师 (TEs)——有着资深的产品知识和测试/质量领域的专业知识，专注于测试本身。
• 测试开发工程师 (SETs)——最初是具有深厚基础设施和工具专业知识的开发工程师，建立了实现自动化所需的框架和软件包。

两个独立角色产生的影响是显著的:

• 自动化测试变得更加高效和精准（例如，减少运行时异常的触发等）。
• 打造和树立测试标准的项目数量激增（例如，改进代码和功能覆盖率来使产品质量越来越高）。

手工测试被简化为手工验证新功能，通常只在端到端，跨产品集成测试时需要手工测试。TEs 为他们所支持的产品积累了极深的业务知识，能为测试自动化和集成提供专业的业务指导。同时，TEs 的角色经过不断演变，职责也变得更加广泛：编写自动化测试脚本，创造让开发人员可以测试自己代码的工具，并不断设计更好和更有创意的方法来识别软件中潜在的问题。

SETs(与 TEs 和其他工程师协作) 构建了大量的测试自动化工具，并开发了适用于很多产品的自动化解决方案。最终产品的发布速度明显加快。所有人都非常满意，大家好才是真的好!

SETs 最初集中开发一些工具用于减少测试周期的时间，因为这是将产品代码投入生产环境的过程中，人工最密集最耗时的阶段。我们也先后向软件开发社区提供了如下工具：改进后的 webdriver、protractor、espresso、EarlGrey、martian proxy、karma 和 GoogleTest。主要是因为 SETs 非常喜欢与行业内的其他人进行分享和合作，也希望能通过举办一些会议进行更深层次的交流。随着其他公司也开始聘用开发工程师来担任类似 SETs 的角色，同时 SETs 在软件开发领域也不断地发表文章，并将测试驱动开发的思想引入主流的开发流程，最终软件开发行业接受了测试工程这个新学科。

通过不断努力，测试周期时间显著减少，但有意思的是，项目总体速度并没有相应加快，因为开发周期中的其他阶段还存在瓶颈。于是 SETs 开始构建新的工具来加速产品开发的所有其他方面，包括:

• 扩展 ide 使编写和评审代码更容易，缩短 “编写代码” 的周期。
• 自动化版本发布验证，缩短 “发布代码” 的周期。
• 自动化生产系统的日志实时校验和异常监测，自动化监控生产环境状态。
• 自动测量开发人员的生产力，帮助开发人员了解自己哪些工作是有效的，哪些不是。

综上所述，SETs 所做的工作自然地从只支持产品测试工作发展到支持产品开发工作。他们的角色职责变得更为广泛，涉及到整个工程生产力的提升。

考虑到 SETs 的角色职责已经扩展，我们想要更改职位的名称来反映他们实际的工作。但是新的头衔应该是什么呢？我们让谷歌所有的 SETs 来选择一个新的职位称呼，最终他们压倒性地（91% 的人）选择了——开发工程师、工具和基础设施 (简称 SETI)。

直到今天，SETIs 和 TEs 仍然在优化整个开发生命周期的过程中紧密合作，目标是消除从功能开发到产品发布过程中所有的工作障碍。对构建下一代工具和基础设施感兴趣么？欢迎加入谷歌（SETI，TE）!