Google是如何测试的（二）

1. SWE or Software Engineer。写功能代码，并发布到终端用户。他们写设计文档、设计数据结构，并且花大量的时间write和review代码。他们要写大量的测试，包括测试驱动设计、单元测试、参与小、中、大的测试。他们对任何他们碰过的代码质量负责，包括写的、修复的、修改的。
2. SET or Software Engineer in Test。也是一个开发者，但是他的侧重点在于可测性。他们review设计，并且审阅代码的质量、风险。他们重构代码并且使他们具备更好的可测性。他们编写单元测试框架、自动化测试框架。从写代码这个角度来看，他们是SWE的伙伴，但是他们关心的是如何从代码层面上提高质量、测试覆盖率，而不是添加功能和提高性能。
3. TE or Test Engineer。他们是SET的补充（上文提到的“立两种类型的测试角色”的后者）。相比开发，他们更侧重测试（注意不是说他们不写代码）。他们要花大量的时间写代码，这些代码一般会是：自动化测试脚本、驱动、模拟用户场景的代码。他们同样要组织好SWE和TE的测试产出，理解他们的测试结果，并且一起运行他们，特别是到了项目的后期当发布的压力变大的时候。TE是产品专家、质量顾问和风险分析师。

（下面的这几段分析比较深入）

从质量的角度来看，SWE要分别对产品的功能和他的质量负责。他们要做到容错的设计、故障恢复、测试驱动开发、单元测试，并且还要和在SET的协助下编写代码测试他们的功能。（feature就是用户可以用到的功能，而这里作者列举的容错等都算是产品的质量维度。）

SET也是开发者，他们提供的产品功能（feature）是供测试使用的。例如：一个通过使用“待实现代码”（原文是stubs，我理解是code stub）模拟依赖的框架，从而能把新开发的代码分离出系统来测试（其实就是mock框架，gmock的功能）。简言之，SET编写的代码是为了能让SWE更方便的测试自己的功能。真正的测试工作是由SWE来做的。SET只确保SWE完成的功能是可测试的，SWE自己来完成写test case的工作。SET的关注的是SWE。具体功能的质量是最终目标，怎么让SWE能够容易的测试自己的代码是SET首要侧重点。这里有一个明显的质量漏洞，功能的使用者——终端用户呢？

在Google用户体验的测试是TE的事情。假设SWE和SET做的模块、功能测试都足够充分了，后面的任务就是这些程序和数据能不能有效的来满足用户的需求了。TE在这里是一个double-check。任何明显的bug说明SWE的测试不充分马虎。当这种bug难觅的时候，TE就可以转向他们最重要的任务了，这些任务有：确保软件完成了用户场景，性能上、安全上、国际化上都OK。TE要做很多的测试和测试协调工作，这种协调工作牵扯的角色很多，有：TE, contract testers, crowd sourced testers, dog fooders, beta users, early adopters（这里不直译了，contract表示契约，可以当做需求来理解；sourced指的是外包，可见google也有外包的产品；dog fooders是说公司的产品都要在公司内部先开展试用，公司鼓励每个人都试用自己的产品，这就叫eating your own dog food，dog fooder值得就是使用过自己产品的员工；beta用户是公测用户；early adopter就是尝鲜者，可以理解为发布后首先使用的人员。总之就是从产品）。他们要跟各种团体沟通的事情很多，包括：设计上固有的风险、功能的复杂性、避免故障的方法。一旦当TE介入，他们的工作没有尽头。（感觉TE更像是涵盖了产品的运营任务，不是运维哦）。