Google的测试策略从来没有变过，我们执行测试的策略随着公司的演化而演化。我们现在是一个集搜索、应用、广告、移动、操作系统等业务于一体的公司。每一个我们关注的领域都是在该领域有意义的问题。随着我们不断的增加新的“关注领域”（Focus Areas），延伸已经存在的领域，我们的测试也在不断的扩展和改善。而我们当下在做的以及我们预计未来将会发展的方向，就是我将要在这系列文章中将要阐述的问题。

　　让我们先从组织结构的介绍开始，这个或许会让你感到惊奇。在Google并不存在一个真正意义上的测试部门。测试实际存在于一个关注领域，我们称它为“生产率工程”（EngineeringProductivity）。“生产率工程”是一个拥有一定数量的横向和纵向的工程学科，测试是最大的一个。而在这个组织中，“生产率工程”是由以下三部分组成：

　　1、产品团队。他们设计的内部的和开源的工具由公司里的所有工程师完成。他们负责构建和维护代码分析器、开发环境、测试用例管理系统、自动化测试工具、构建系统、源代码控制系统、代码回顾计划、缺陷数据库。他们的目标就是设计一种能让工程师更有效率的工具。工具是在检测预防的战略目标中占非常大的一部分。

　　2、服务团队。他们在一个非常宽泛的领域内向产品团队提供诸如包含工具（includingtools）、文档、测试、发布管理、培训等方面的专业技能。他们的专业技能涵盖可靠性、安全性、国际化等方面，也会处理产品团队可能遇到的关于功能细节方面的问题。任何一个其他“关注领域”的服务团队也可以为产品团队提供专业技能服务。

　　3、嵌入式工程师。他们有效的担负起了Google产品团队在有需要时的需求。有些工程师会跟着同一个的产品团队数年，另一些则只会在一个较短的周期内为产品团队的需要提供服务。Google鼓励所有的工程师经常更换自己服务的产品团队，以保持饱满的精神状态，并保证有效和客观的工作。测试工程师也一样，更换团队的节奏也是因人而异的。有些测试工程师在Chrome项目下数年，而有一些则在加入团队18个月后去了别的团队。在产品知识与新颖的视角间保持一个良好的平衡，是一个测试管理者需要关注的。

　　所以这意味着测试同学向工程生产力部门的经理汇报，但是他们会把自己看成产品部门团队的一员，像搜索、邮箱、和Chrome部门。从组织架构上看，测试都是两个团队的一部分。测试和产品团队坐在一起，参与计划，一起吃饭，共享奖金，享受像全职的产品团队成员一样的待遇。这种单独的组织汇报关系的好处是可以给测试人员之间提供良好的共享信息的讨论机会，好的测试思路可以很容易的在工程生产力部门内部蔓延，无论公司内的哪条产品线，都可以很快地使用这些最好的测试技术。

　　测试人员的这种项目分离和汇报组织结构也有它的缺点，目前来看，最大的问题是测试人员被看做外部资源。产品部门团队不能对测试人员有太多的依赖，他们自己必须要合理地控制产品质量。是的，没错，在谷歌，是产品部门团队对产品质量负责，而不是测试人员。每个产品部门的开发人员都需要做测试工作，测试人员的任务是为产品部门团队搭建自动化测试基础设施和流程，测试人员让开发可以自给自足地、独立地做完成测试工作。

　　在这种模式下，我比较喜欢的是，开发和测试将有相同的地位。在质量方面，开发和测试成为了真正的伙伴，最大的质量重担交给本应属于的开发人员，开发的职责就是正确地实现产品功能。另外这样可以保持多对一的开发测试比率，开发人员在数量上远超测试人员，并且测试工作做的越多，开发测试比率就会越大。产品部门团队也会对这样的高开发测试比率而感到骄傲。

　　好，现在好像大家都是好朋友了，对吧？ 相信你已经看到这种模式的一个问题，开发人员不能很好地驱动缺陷【Bug】的运转，开发不会测试。难道我要否认这一点么？不管怎样，我都不会否认，尤其是在我去年做的一次关于开发工程师与测试工程师对比的游戏之后（告诉你：测试工程师赢得了较量）。

　　在谷歌，解决这个问题的办法是将角色再细分，我们通过设立不同的测试角色来解决这两种不同的测试问题。在下一篇文章里，我将详细阐述这些测试角色和谷歌是怎样将测试问题分成两部分来分别解决的。