google在公司的大层面组织上有很多的Focus Area，search, apps, ads, mobile, operating system这些都是不同的FA。测试隶属于其中的一个FA，这个FA的名字叫Engineering Productivity。这个FA由很多纵向的横向的学科构成，测试是其中最大的一个学科。Eng Prod这个FA由下面的部分组成：
- product team。公司内部使用的工具还有开源工具都由它来生产，这些都是提高生产率的工具，包括代码分析工具、IDE、case管理工具、自动化测试工具、编译工具、编译系统、代码版本控制工具、code review工具、bug database。
- services team。给上面的product team的各种工具的提供使用经验，包括工具本身、文档、测试、发布管理、培训等，这些经验涵盖可靠性、安全性、国际化等方面。每个FA都共享这些经验。
- Embedded engineers。被按照具体的需求外借到不同的产品团队（FA）。有的呆在同一个产品团队好多年，有的则轮换多个产品团队。google鼓励工程师做这种轮换，因为这样可以保持新鲜感、浓厚的兴趣、立场的客观。测试工程也一样，不过这种轮换的平率则取决于个人。有测试工程师在Chrome上做了好几年有的只有18个月。在新鲜感和领域知识中间做好一个平衡是作为一个测试人员要特别关注的事情。
从上面的表述可以看出来，测试工程师在google其实就是Eng Prod这个部门下面的Embedded engineers，他们要向Eng Prod的汇报，但是却工作生活在别的产品团队，比如Search、gmail等。可是他们不向产品团队的人汇报，这种“分开汇报”方式的好处是他提供了一个forum，可以让测试工程师分享他们的知识。在 Eng Prod 中Good testing ideas可以很容易产生。
把项目线和汇报线分开有它的挑战。目前最大的挑战是：测试是（产品团队的）外部资源。产品团队不能指望测试工程师保证质量，而是要自己来确保。在Google产品质量是产品团队自己的事情，不是测试工程师的事情。每个开发工程师要自己来做测试。测试工程师的任务是确保他们有测试的自动化框架，另外还要建立一种有利于“自依赖”（开发依赖自己的测试来保证质量）的流程。总结起来就是：测试工程师让开发工程师更舒服的来测试自己的代码。
我（James）之所以喜欢这种方式，在于他把开发和测试人员放到了相同的位置（不存在上下游关系）。他让测试开发成为伙伴，并且把最大的质量任务给了开发，致力于让产品正确运行的开发自己。另外一个副效应就是做到一个很高的开发测试比。产品团队应当以此为荣！
上面这种策略的弊病在于开发通常自己不能确保自己的质量，在Google我们解决这个问题的方法是建立两种类型的测试角色，来解决两种完全不同的测试问题。
