Don’t fall in love: 互联网产品是不断变化的，不需要等到把一个产品设计的很完美了才发布。

Facebook 从 2004 年的哈佛校园的学生项目在短短的 7~8 年的时间中快速增长为拥有 10 亿用户的世界上最大的社交网络，又一次见证了互联网创业成功的奇迹。同时它的产品研发流程也成为了众多互联网产品公司的追逐对象。今天我们来看一下 Facebook 在产品质量控制方面的实践。有人说，现在的 Google 象早期的微软，现在的 Facebook 象早期的 Google. 我觉得不无道理。 虽然 Facebook 已经早已不是创业公司，但是不难看出它在产品研发和质量控制仍然保持着创业公司的风格。在产品研发上，他们以小的研发团队为核心，遵循几个非常重要的原 则：

• Be there from start to ship: 每个工程师自始至终负责产品。从最开始的一个想法，到开发原型，到内部审核，反馈，到产品开发，上线和维护，全部有工程师自己搞定。
• Show work early and often: Facebook 非常看重反馈，尤其早期内部反馈。他们鼓励工程师有了想法后，尽快开发出原型，尽快得到反馈。
• Gets your hands dirty: 动手去做，去实现。
• Don’t fall in love: 互联网产品是不断变化的，不需要等到把一个产品设计的很完美了才发布。

为了遵循以上原则，Facebook 工程师采用以下质量控制手段来保证产品质量：

• 开发人员对质量负责： 开发人员从设计，实现，测试，到部署都要自己做。其它做工具，流程的工程师通过开发工具和流程来帮助开发人员更为简单方便地做测试，做部署和做监控。每个 开发人员有自己单独的测试环境，测试环境就是运行在开发本地机器上，部署非常简单快速。测试环境用的是真实的用户数据。
• 持续集成和测试自动化：每周发布一次。星期天晚上，要发布的构建从主线上分支出来到发布分支，到星期二的中午如果没有大的问题，就可以上线了。所有的测试运行控制在 10 分钟以内，所以不需要考虑不运行哪些测试用例。运行所有测试用例。 （只是听说，没有经过考证。）
• 内测 （dog food）：发布之前，公司员工使用要发布的功能。2~3天之内可以有几百个或上千个人在使用新功能。负责要发布功能的开发人员在星期天晚上到星期二中午之间会做大量的测试 （一边上班，一边刷微博，岂不是很爽 🙂 ）。
• 发布风险控制：新功能本身质量可能有问题，新功能也可能影响其它现有功能。为了减少或控制这些风险。Facebook 开发了一整套完善的发布，控制，监控流程和工具。做到：1. 测试通过后，产品质量基本有保证。2.即使有漏测的 bug，只会影响很少量的用户。3. 及时监控到问题。4. 及时修复。
• 产品监控：监控产品的系统的运行状态。

Facebook 之所以采取这种质量控制策略和它的产品特点密切相关：

1. 用户对社交产品质量的容忍度相对较高。比如发微博，现在连不上，等一会在连接也可以，现在发布不出去可以等一会再发，粉丝数量统计有误，没有人太 关心。其实 Facebook 并不认为自己的质量差。他们认为产品的质量高低不是有多少个 failed 测试用例，有多少个 bug 来确定的，而是有用户对质量的期望值来决定的。如果用户对产品质量的期望值很高很高，一个 bug 漏掉了都会照成质量差的印象，用户很有可能放弃使用。相反，如果用户的期望值一般，100个 bug 漏掉了都不会影响用户继续使用。所以 Facebook 产品发布的条件是满足用户对质量的期望值即可。
2. 相对宽松的产品发布周期。不像微软或 Google 很多产品已经在市场上，用户对下一版本的发布时间和新增加功能的期望很高，这往往给产品开发组的压力很大。Facebook 基本没有这个问题，它有适合自己的发布期限，不用受到外界干扰。
3. 产品发布和监控流程比较完善，即使有漏测的 bug，对用户的影响可以控制在最小而且可以及时发现及时修复。

Facebook 质量控制中引以为豪而且倍受瞩目的就是“没有专职测试工程师”。我这里需要专门讨论一下：

1. 什么是“专职测试工程师”？ 头衔里面有“测试”的工程师？专门找 bug 的工程师？专门做质量控制的工程师？等等。
2. Facebook 的确没有带“测试”头衔的工程师，也没有专门运行产品找 bug 的工程师。每个人都是开发工程师。但是他们的实际工作有区别，有的专门做面对用户的产品，有的专门做测试，开发工具，有的专门做产品的构建和持续集成工具 和流程，有的专门做发布和监控的工具和流程。如果按照传统意义上的开发和测试的划分的话，除了第一类外，其他都可以看做专职测试工程师。
3. Facebook 不是惟一一个没有带“测试”头衔工程师的公司，很多软件公司都没有，比如 twitter.
4. 很多人把专职测试工程师指专门运行产品找 bug 的工程师。微软在 2005 年去掉 STE (software test engineer )岗位，就已经没有这一类型的专职测试工程师了。

所以个人认为，专职测试工程师是个非常模糊的结论。尤其现在我们对产品质量控制方法的不断演变和提高，“测试”的概念不仅仅是指找 bug 了，所有围绕提高产品质量的工作都是测试。头衔上有没有“测试”不重要，有没有“测试”岗位不重要，重要的是如何有效保证和提高产品质量。