爬、走、跑

在拥有如此少量测试人员的情况下，Google还可以取得不错的成果，核心原因在于Google从来不会在一次发布的产品中包含大量功能。实际上，我们的做法恰恰相反，在一个产品的基本核心功能实现之后，就立刻对外发布使用，然后从用户那里得到真实反馈，再进行迭代开发。这也是我们在Gmail产品上的经验，Gmail带着beta标签在线上运营了四年，这个标签用以警示我们的用户，Gmail仍处于改良之中。对于最终用户，只有该产品达到99.99%的可用性时，我们才会把beta标签去掉。在Android G1这个产品上，我们再次使用了这个方法，让这个非常有用且经过良好设计的产品变得更棒了，功能也更加丰富全面，之后的Nexus手机也采用了相同的策略。有一点需要引起注意，对于初期版本的用户，并不是因为这个产品还处于早期版本就不为之提供足够的功能，早期版本并不意味着是一个不可用的烂版本。

注意 Google经常在最初的版本里只包含最基本的可用功能，然后在后继的快速迭代的过程中得到内部和外部用户的反馈，而且在每次迭代的过程中都非常注重质量。一个产品在发布给用户使用之前，一般都要经历金丝雀版本、开发版本、测试版本、beta或正式发布版本。

Google发布的过程虽然快，但也并不像想象中如牛仔一般的鲁莽与仓促。实际上，为了发布我们称之为beta的版本，一个产品要经历一系列的内部版本验证，用以证明它已经具备了一定的质量。例如Chrome，这是我加入Google之后的两年都为之工作的一个产品，根据我们对产品的信心以及来自用户的反馈，我们在整个过程中使用了不同的版本，大致顺序如下。

金丝雀版本：这是每日都要构建的版本，用来排除过滤一些明显不适宜的版本。就像煤矿井里的金丝雀（译注：17世纪，英国人将金丝雀放到煤矿井里检测井中空气质量。如果金丝雀死了，则表示矿井中的空气已达到令人中毒的水平。此处意为对一件事情的预警），如果构建失败了的话，意味着我们的流程可能在哪里出了问题，需要去复查一遍我们的工作。使用金丝雀版本需要极强的容忍度，而且在这个版本下可能无法使用应有的基本功能。一般来说，只有这个产品的工程师（开发或测试人员）和管理人员才会安装使用金丝雀版本。

注意 Android团队在这方面有更勇敢的尝试，所有核心开发团队成员的手机上都安装有每日构建的版本。这样做是为了减少往代码库中提交有问题的代码，一旦安装了错误代码，手机甚至都无法使用其基本功能，例如和家人通话。

开发版本：这是开发人员日常使用的版本，一般是每周发布一个。该版本具有一定的功能并通过了一系列的测试（我们将会在随后的章节里讨论这点）。所有这个产品下的工程师都会被要求去安装这个版本，并在日常工作中真正使用它，这样可以持续对这个版本进行测试。如果一个开发版本不能够满足日常真实工作的需求，那么它将会被打回为金丝雀版本。发生这种情况不但令人郁闷，工程团队也需要再花费大量的时间去重新评估。

测试版本：这是一个通过了持续测试的版本。这个版本基本上是最近一个月里的最佳版本了，也是工程师在日常工作中使用的最稳定最信任的一个版本。测试版本可以被挑选作为内部尝鲜（译注：dog food）版本，如果该版本有比较持续的优良表现，也是作为beta测试的候选版本。一些情况下，如果测试版本在公司内部使用得足够稳定，一些想更早尝试这个产品的外部合作伙伴也会使用这个版本。

beta或发布版本：这个版本是由非常稳定的测试版本演变而来，并经历了内部使用和通过所有质量考核的一个版本，也是对外发布的第一个版本。

这种爬、走、跑的模式，给我们的应用程序尽早地提供了一个测试验证的良好机会。与从自动化测试那里得到的反馈一样，我们每天都能从内部用户那里得到关于这些版本的质量反馈。