爬，走，跑。
在比其他公司少很多测试人员的情况下，谷歌做的还不错的一个关键原因是，很少尝试在一次发布中包含很多的功能。实际上，谷歌经常反其道而行之，在一个产品的核心模块被开发后，如果有一定数量的受益人群就立刻发布，然后不断的得到用户反馈再迭代开发新功能。这也是我们在Gmail 上的做法，Gmail 被贴上Beta版本的标签在线上运营了四年。通过这个Beta标签也可以来警示用户，Gmail 还并非完美的产品，有出错的可能。只有当邮件数据达到 99.99%的时间都是可用的时候，我们目标就算达到了，这个Beta标签才会被去除。很明显，质量是一个不断改进的过程。
这里的这个改进过程，并不像西部牛仔那样，一下子什么都能搞出来。实际上，一个产品为了达到我们称之为Beta的版本，也要经历一系列的过程，并在过程中证明其价值。Chrome是我加入谷歌前两年一直所工作的团队，它同样经历了多个版本。在每个版本里，基于对产品质量的信心和不断寻求的客户反馈才让我们进入到下一个版本。这些版本历程大致如下：
金丝雀版本（Canary Channel），不太可靠的版本，并不适用于发布。就像一只金丝雀在煤堆里一样，如果不幸身亡，那说明还有工作要去做。只有超强容忍能力的用户才有可能使用金丝雀版本来试验运行，你不能依赖这样的应用能把实际工作完成。
开发版本（Dev Channel），是开发工程师们日常工作中使用的版本。所有的同一产品组的工程师都需要去安装这个版本，并在真正的工作中使用他们。
测试版本（Test Channel），是给内部的狗食【译者注，dog food，一般指自己团队的产品，给自己或者公司内部的人尝试使用的中间产品】，如果能够有持续不错的性能表现的话，也可能会是beta版本的候选。
Beta版本或发布版本（The Beta Channel or Release Channel），是给外部用户使用的第一个版本。只有在之前的各种版本历程中通过了测试和真实用户的枪林弹雨般的验证后，才会成为beta版。
上述的这种从爬到走、走到跑的模式，让我们在运行一些测试同时又可以对我们的应用系统做一些试验调整，并从真实用户和每个版本的每日自动化测试那里得到及时的反馈。
对于这样的过程，还有一些分析角度的益处。例如，发现了一个bug，测试人员可以根据这个bug创建一个测试用例，并针对所有的每一个版本都运行这个测试用例，从而可以验证这个 bug fix是否在所有的版本中都真正得到了修复。
【译者注：关于Chrome 与 Chrome OS 各版本的称呼，可以参见http://www.chromi.org/chromedownload ，其中也涉及到本文中各个版本的称呼，但并不是与 James文中完全一致，实际上像金丝雀版本，一些喜欢尝鲜的外部用户也在使用】
相关链接：
