艾伟也谈项目管理，Google的产品质量之道

　　James Whittaker是Google的测试总监，曾任微软构架师，也是“实用软件测试指南”系列图书中好几本书的作者。他最近写了一系列的博文，介绍Google是如何进行测试。Google把开发和测试紧密结合在一起，测试人员相对较少，每个产品在正式上线前都要经过好几个不同的版本。

　　Google保证产品质量的方法和很多公司是不一样的。Google没有一个庞大的测试部门，相反，部分测试工作委派给了开发人员。Whittaker写道：

测试和开发同时进行。编写一些代码，马上进行测试和构建。接着，编写更多的代码，继续测试。更好的是，在你编码的时候或者编码之前，就计划好你的测试。测试不是一个独立分开的过程，它是开发的一部分。质量不等同于测试；要想有高质量的产品，就要把开发和测试紧密捆绑在一起，直到不分彼此。

　　这是因为，Google认为要保证质量，预防胜于检查：

质量来自开发，而不是测试。为了拓宽开发环节，我们可以把测试融入到开发中去。我们已经建立了一个超高效的增量流程，只要有一个增量被证明缺陷太多，我们就可以回滚这些错误。我们不仅预防了很多产品级问题，还大大地减少了那些为确保消除“召回级别”缺陷而安排的测试人员的人数。

　　因此，在Google，测试人员不用做测试是众所周知的，他们只要“确保他们【开发人员】有自动框架和相关流程”进行测试即可。开发人员进行必要的测试，他们对他们的代码质量负责。这其实就是强调了一点：“质量的重担落在那些负责交付正确产品的开发人员的肩上。”为了实现他们的质量哲学，Google有三种类型的工程师，Whittaker解释道：

• SWE或者软件工程师是传统的开发角色。SWE编写最终交付给客户的功能代码。他们编写设计文档，设计数据结构以及整体架构，花绝大部分时间编写和审查代码。SWE会编写很多测试代码，包括测试驱动设计，单元测试，以及在未来的几篇博文中我们会具体解释的，如何参与到简单、中等甚至复杂的测试集成中去。SWE们对他们参与的一切的质量负责，不管是他们编写的、修复的或者是修改的。
• SET或者测试软件工程师（Software Engineer in Test）也是开发角色，只是他们专注于易测性。他们审查设计，密切关注代码质量和风险。他们重构代码，让代码更加易于测试。SET需要编写单元测试框架和自动化测试。他们的代码也会提交到SWE所工作的代码库(code base)，但是他们更加关注提高质量和测试覆盖率，而不是增加新功能或者提高性能。
• TE或者测试工程师则跟SET恰恰相反。他们这个角色会把测试放在首位，而把开发放其次。很多Google的TE会花很多时间来编写模拟了实际使用场景甚至是模拟了用户的自动化脚本和代码。他们也整理SWE和SET的测试工作，解读测试结果从而驱动测试，他们也会在项目后期参与到项目中去，来强力推动项目发布。TE是产品专家，质量顾问也是风险分析员。

　　换句话说，SWE负责软件功能特性和它们的质量。SET提供代码支持，从而使SWE能测试这些产品特性。TE快速地测试系统或者再次检查那些被开发人员忽略的主要缺陷。并且，他们协助用户测试，还进行性能、安全以及其他类似的测试。

　　在公司级别，Google有几个关注域（Focus Areas）——搜索、广告、应用程序、移动服务、操作系统等等。其中有一个关注域是工程生产力（Engineering Productivity，EP），它包括了一些“横向和纵向的工程规范（horizontal and vertical engineering disciplines）”，测试是其中最大的一块。EP包括：

1. 产品团队——为整个Google的所有工程师提供能提高生产力的工具，包括开源项目，比如“代码分析器、IDE、测试用例管理系统、自动测试工具、构建发布系统、版本控制系统、代码审查安排系统、缺陷数据库。”
2. 服务团队——为任何Google员工提供关于可靠性，安全，国际化等领域的专业知识，包括“工具、文档、测试、发布管理、培训”等等。
3. 派遣式的工程团队（Embedded Engineers Team）——在Google，测试人员会被借调去不同的产品团队。他们可以选择为一个团队服务很多年，但公司鼓励他们去不同的团队轮岗，从而能够“在产品知识和新鲜视野之间”保持一个良好的平衡。这些测试人员参与到产品团队中的很多不同的关注域，但是从组织关系上来说，他们汇报给EP管理层。这样做的理由是能够建立一个“让测试人员共享知识和信息的论坛。好的测试想法在EP内部很容易传播开来，从而使所有测试人员，不管他们为哪个产品服务，都能够了解到公司内最好的技术。”

　　这种测试策略带来的结果就是相对较少的测试人员。根据Whittaker的观点，这也可能是因为“我们很少尝试一次快速交付很多功能。事实上，我们的目标恰恰相反：构建一个产品的核心部分，一旦它对很多人有价值，我们就发布这个产品，随后我们收集反馈，继续迭代。”另外一个确保质量的关键元素是使用多重版本。Whittaker以Chrome为例，介绍了四种不同的版本：

1. 金丝雀版（Canary Channel）——还没有做好发布准备的代码
2. 开发版——开发人员使用的版本
3. 内部测试版（Test Channel）——为了准备beta发布的版本
4. 测试（beta）或者发布版——这个版本的产品可供Google内部或者公众使用。

　　产品发布以后，如果发现了一个缺陷，我们会编写一个测试，并且在所有的版本中进行验证，看看这个缺陷是不是已经在某个版本里面被修复了。

　　简单来说，这就是Google用来测试他们的产品、确保代码质量的流程和组织结构。

　　查看英文原文：Ensuring Product Quality at Google