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包括：
这种测试策略带来的结果就是相对较少的测试人员。根据Whittaker的观点，这也可能是因为“我们很少尝试一次快速交付很多功能。事实上，我们的目标恰恰相反：构建一个产品的核心部分，一旦它对很多人有价值，我们就发布这个产品，随后我们收集反馈，继续迭代。”另外一个确保质量的关键元素是使用多重版本。Whittaker以Chrome为例，介绍了四种不同的版本：
产品发布以后，如果发现了一个缺陷，我们会编写一个测试，并且在所有的版本中进行验证，看看这个缺陷是不是已经在某个版本里面被修复了。
简单来说，这就是Google用来测试他们的产品、确保代码质量的流程和组织结构。
查看英文原文：Ensuring Product Quality at Google
相关文章
