Google的产品质量保障机制

Google的产品质量保障机制

James Whittaker（前微软架构师，《如何突破软件》系列技术图书作者，现任Google测试工程总监）最近撰写了一系列文章讨论Google如何做测试。Google将开发和测试混合在一起，测试人员相对较少，而每个产品在正式发布前需要经过若干连续的通道（译注：channel 按常规翻译为通道，其实这里的意思更接近于“版本”）。

与大多数组织不同，Google对于产品质量的探求走的是自己的路。据Whittaker 介绍，Google并没有一个大型的测试部门，部分测试任务被指定给开发人员完成。

“测试与开发携手并进。写一点儿代码，就构建测试一下，再写代码，再测，如此往复。更好的状况是在编码之前就规划好如何测试。测试不是一项孤立的实践，而是开发过程自身的一部分。质量不等同于测试，将开发与测试混合交叉在一起，直至不分彼此，这样才能有质量保障。”

之所以如此，是因为Google认为产品质量关键在防患于未然，而不是通过检测。

质量是开发的问题，而不是测试的问题。在某种程度上，我们可以将测试实践嵌入开发过程。我们创造了一个超级增量型的开发流程，在此流程中，如果一个增量开发成果漏洞百出，那么这些错误可以回滚。我们不仅预防了许多客户问题的出现，而且减少了做回归测试的人员的数量。

因而，在Google，测试工程师做的并不是通常意义上的测试，而是确保开发人员拥有自动化的架构和流程以完成测试。开发人员对其代码质量负责，做必需的测试。这便将测试压力放在它该在的地方，即，负责将产品开发正确的开发人员。为了实践Google的质量哲学，Google有三种类型的工程师：

1.SWE，即软件工程师。这是传统的开发者角色。SWE编写交付给客户的功能性代码、

创建设计文档、设计数据结构和全局架构、并用大量时间审查自己写的代码。SWE还要编写大量测试程序，编写测试驱动的设计文档、进行单元测试，参加小型、中型和大型的测试活动。SWE对所有他编写的、订正的、修改的东西的质量负责。

2.SET，即测试软件工程师。这也是开发者的角色，但他们关注的是产品的可测试性。SET

审查产品设计，评估代码质量和风险。为了使代码更便于测试，SET会对代码进行重构。

SET编写单元测试框架和自动化测试框架，也与SWE进行合作编码，不过SET更关心提升质量和测试覆盖率，而不是增加新的功能特性或改进产品性能。

3.TE，即测试工程师。TE的职责与SET恰好相反，这是一个测试第一、开发第二的角色。

许多Google的TE花费大量时间写测试脚本，从而还原使用场景甚至模仿用户。TE还会组织SWE和SET的测试工作，解释测试结果，驱动测试的执行，尤其是在项目后期准备发布的时候。TE是产品专家、质量顾问、风险分析师。

换句话说，SWE对软件特性及其质量负责；SET提供支持代码以使SWE更好地进行产品特性测试；TE则执行快速的测试，或者对在开发阶段被忽视的bug进行复查，并且提供用户测试、性能测试、安全测试诸如此类。

在组织层面上，Google有几个重点领域：搜索、广告、应用程序、手机、操作系统等等，一个领域就是一个EP（工程生产力）集团，EP有几个横向和纵向的部门，测试是其中最大的。EP由以下团队组成：

●产品团队：为Google的所有工程师设计生产力工具，包括开源工具，例如代码分析器、

IDE、测试用例管理系统、自动化测试工具、编译构建工具、代码控制系统、代码走查工具、bug数据库。

●服务团队：在工具、文档、测试、产品发布、培训等等方面，为Google员工提供专业

的可靠性、安全性、国际化服务。

●嵌入工程师团队：这是租借给Google各个产品团队的测试团队。他们可以选择留在一

个产品团队呆几年，不过更鼓励他们切换不同的团队，这样可以保持产品知识和新鲜视野之间的健康平衡。这些测试人员在Google重点领域的产品团队工作，但直接向EP 管理层汇报。这是为了向测试人员提供一个信息分享的平台，良好的测试理念可以在EP内部快速地转移给所有测试人员，无论是否与其产品有关。

这种测试安排相对减少了测试人员的数量，之所以如此，按照Whittaker说法是：“我们极少一次性交付一大堆产品特性。事实上，我们的目标是：构建一个产品的核心，当其可用时便发布它，然后收集反馈，迭代开发。”

产品质量保障过程的另一个要素是多通道的使用，以Chrome浏览器为例，它便有4个不同的通道：

1.金丝雀通道：为那些尚不能见光的代码准备

2.开发通道：这是开发人员使用的通道

3.测试通道：准备进行beta测试的代码

4.Beta或发布通道：准备向Google内部或普通用户发布的产品

产品发布后，若发现了bug，那么针对所有通道都要写测试代码，以便验证在其中的某个通道该bug是否已经被修正了。

简言之，这就是Google进行产品测试和代码质量保障的流程和组织结构情况。

原文：/news/2011/03/Ensuring-Product-Quality-Google Ensuring Product Quality at Google Posted by Abel Avram on Mar 11, 2011

James Whittaker, a former Microsoft architect, author of several books in the “How to Break Software” series, and currently Director of Test

Engineering at Google, has written a series of posts on how Google does testing. Google blends development with testing, having relatively few testers, and each product goes through successive channels before is ready for prime time.

The quest for quality at Google follows a different path than that used by most organizations. Google does not have a large testing department, but rather testing is partially assigned to the developers, according to Whittaker:

Testing and development go hand in hand. Code a little and test what you built. Then code some more and test some more. Better yet, plan the tests while you code or even before. Test isn’t a separate practice, it’s part and parcel of the development process itself. Quality is not equal to test; it is achieved by putting development and testing into a blender and mixing them until one is indistinguishable from the other.

That is because Google considers that quality is ensured through “an act of prevention” rather than one of detection:

Quality is a development issue, not a testing issue. To the extent that we are able to embed testing practice inside development, we have created a process that is hyper incremental where mistakes can be rolled back if any one increment turns out to be too buggy. We’ve not only prevented a lot of customer issues, we have greatly reduced the number of testers necessary to ensure the absence of recall-class bugs.

So, at Google, testers do not do testing as is generally known, they only “make sure they [developers] have the automation infrastructure and enabling processes” to do testing. Developers are responsible for the quality of their code, doing the testing needed. This places t he “quality burden where it belongs: on the developers who are responsible for getting the product right.” To implement their quality philosophy, Google has three types of engineers, according to Whittaker:

The SWE or Software Engineer is the traditional developer role.

SWEs write functional code that ships to users. They create

design documentation, design data structures and overall

architecture and spend the vast majority of their time

writing and reviewing code. SWEs write a lot of test code

including test driven design, unit tests and, as we explain

in future posts, participate in the construction of small,

medium and large tests. SWEs own quality for everything they

touch whether they wrote it, fixed it or modified it.