1. product team。公司内部使用的工具还有开源工具都由它来生产，这些都是提高生产率的工具，包括代码分析工具、IDE、case管理工具、自动化测试工具、编译工具、编译系统、代码版本控制工具、code review工具、bug database。
2. services team。给上面的product team的各种工具的提供使用经验，包括工具本身、文档、测试、发布管理、培训等，这些经验涵盖可靠性、安全性、国际化等方面。每个FA都共享这些经验。
3. Embedded engineers。被按照具体的需求外借到不同的产品团队（FA）。有的呆在同一个产品团队好多年，有的则轮换多个产品团队。google鼓励工程师做这种轮换，因为这样可以保持新鲜感、浓厚的兴趣、立场的客观。测试工程也一样，不过这种轮换的平率则取决于个人。有测试工程师在Chrome上做了好几年有的只有18个月。在新鲜感和领域知识中间做好一个平衡是作为一个测试人员要特别关注的事情。

从上面的表述可以看出来，测试工程师在google其实就是Eng Prod这个部门下面的Embedded engineers，他们要向Eng Prod的汇报，但是却工作生活在别的产品团队，比如Search、gmail等。可是他们不向产品团队的人汇报，这种“分开汇报”方式的好处是他提供了一个forum，可以让测试工程师分享他们的知识。在 Eng Prod 中Good testing ideas可以很容易产生。

把项目线和汇报线分开有它的挑战。目前最大的挑战是：测试是（产品团队的）外部资源。产品团队不能指望测试工程师保证质量，而是要自己来确保。在Google产品质量是产品团队自己的事情，不是测试工程师的事情。每个开发工程师要自己来做测试。测试工程师的任务是确保他们有测试的自动化框架，另外还要建立一种有利于“自依赖”（开发依赖自己的测试来保证质量）的流程。总结起来就是：测试工程师让开发工程师更舒服的来测试自己的代码。

我（James）之所以喜欢这种方式，在于他把开发和测试人员放到了相同的位置（不存在上下游关系）。他让测试开发成为伙伴，并且把最大的质量任务给了开发，致力于让产品正确运行的开发自己。另外一个副效应就是做到一个很高的开发测试比。产品团队应当以此为荣！

上面这种策略的弊病在于开发通常自己不能确保自己的质量，在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是产品专家、质量顾问和风险分析师。