本节书摘来自异步社区《Google软件测试之道》一书中的第1章1.2节角色，作者【美】James Whittaker , Jason Arbon , Jeff Carollo，更多章节内容可以访问云栖社区“异步社区”公众号查看。
1.2 角色
为了保证“解铃还需系铃人”这句名言成为事实（译注：“you build it，you break it”，摘自“you build it，you break it，you fix it”。原意指在构建实验室（Build Lab）的人永远不会去修复构建失败（build break）的问题，只有开发人员自己才能修复。这里的意思是开发人员自己要对自己写的代码负责，比专职的测试人员更适合做测试工作。在传统的开发岗位之外我们又增加了几种角色。我们明确地提出了有一种工程师角色必须存在，他可以让开发人员更加有效且高效地做测试。在Google，我们的确创建了这样的角色，他的职责就是让其他的工程师更有效率和质量意识。这些角色常把他们自己看做是测试者，但实际上他们的使命是提高生产率。测试人员的存在是为了让开发人员的工作更有效率，并且很大一部分体现在避免因马虎粗心而导致的返工，因此，质量也是效率的一部分。在接下来的章节里，会花费较多的内容来详细讲解这些角色，所以在这里只进行简单的介绍。
1.2.1 软件开发工程师（SWE）
软件开发工程师（译注：software engineer，后文简称SWE）是一个传统上的开发角色，他们的工作是实现最终用户所使用的功能代码。他们创建设计文档、选择最优的数据结构和整体架构，并且花费大量时间在代码实现与代码审核上。SWE需要编写与测试代码，包括测试驱动的设计、单元测试、参与构建各种大小规模的测试等，这些测试会在本章的后面做详细解释。SWE会对他们编写、修复以及修改的代码承担质量责任。假设一个开发者不得不修改一个函数，如果这次修改导致已有测试用例运行失败，或者需要增加一个新的测试用例，他就必须去实现这个测试用例的代码。开发工程师几乎将所有的时间都花费在了代码编写上。
1.2.2 软件测试开发工程师（SET）
软件测试开发工程师（译注：software engineer in test，后文简称SET）也是一个开发角色，只是工作重心在可测试性和通用测试基础框架上。他们参与设计评审，非常近距离地观察代码质量与风险。为了增加可测试性，他们甚至会对代码进行重构，并编写单元测试框架和自动化测试框架。SET是SWE在代码库上的合作伙伴，相比较SWE是在增加功能性代码或是提高性能的代码，SET更加关注于质量提升和测试覆盖率的增加。SET同样会花费近百分之百的时间在编写代码上，他们这样做的目的是为质量服务，而SWE则更关注客户使用功能的开发实现上。
注意
SET是SWE在代码库上的合作伙伴，与增加功能性代码或提高性能的代码的SWE相比，SET更加关注于质量的提升和测试覆盖率的增加。SET写代码的目的是可以让SWE测试自己的功能。
1.2.3 测试工程师（TE）
测试工程师（译注：test engineer，后文简称TE）是一个和SET关系密切的角色，有自己不同的关注点——把用户放在第一位来思考，代表用户的利益。一些Google的TE会花费大量时间在模拟用户的使用场景和自动化脚本或代码的编写上。同时，他们会把开发工程师和SET编写的测试分门别类地组织起来，分析、解释、测试运行结果，驱动测试执行，特别是在项目的最后阶段，推进产品发布。TE是真正的产品专家、质量顾问和风险分析师。某些TE需要编写大量的代码，而另外一些TE则只用编写少量的代码。
注意
TE把用户放在第一位来思考。TE组织整体质量实践，分析解释测试运行结果，驱动测试执行，构建端到端的自动化测试。
从质量的角度来看，SWE负责功能实现和这些独立功能的质量。他们对容错设计、故障恢复、测试驱动设计、单元测试负责，并和SET一起编写测试代码。
SET也是开发人员，负责提供测试支持。有这样一个测试框架，它可以把新开发的代码隔离，通过模拟一个真实的工作运行环境（一个包含stubs、mock、fake等方法的流程，这些内容会在后面详细讲到）和代码提交队列来管理代码的提交。换句话说，SET编写代码，通过这些代码提供的功能让SWE能够自己测试他们的功能。多数测试代码是由SWE完成，SET存在的目的就是保证这些功能模块具有可测试性，并且相应的SWE还可以积极地参与到测试代码的编写中去。
很明显，SET的主要关注对象就是开发人员。SET的主要职责是让开发者可以很容易地编写测试代码，从而达到独立功能模块的质量要求。专注于用户角度的测试则是TE的职责。考虑到SWE和SET已经做了足够多的模块级别与功能级别的测试，下一步要考虑的就是要验证这些可执行的代码与数据集成在一起之后，是否可以满足最终用户的需求。在这里，TE扮演着一个双重确认的角色，确认开发人员在测试方面的工作是否到位，任何明显的bug都会表明早期开发人员所做的测试工作存在不足或比较马虎。当这些明显的bug变少时，TE会把注意力转移到常见用户使用场景中去，是否满足性能期望，在安全性、国际化、访问权限等方面是否满足用户的要求。TE运行许多测试的同时，也负责和其他团队的TE、合同工编制的测试人员、以众包形式参与的测试者、内部尝鲜者、beta测试者以及早期用户进行合作交流，与各方讨论基本设计带来的风险、功能逻辑复杂性和错误避免的方法。一旦TE参与到项目之中，基本上就会没完没了。
