【上海校区】Facebook没有测试工程师，如何进行质量控制的？ - 黑马程序员技术交流社区

Facebook从04年的哈佛校园的学生项目在短短的7－8年的时间中快速增长为拥有10亿用户的世界上最大的社交网络，又一次见证了互联网创业成功的奇迹。同时它的产品研发流程也成为了众多互联网产品公司的追逐对象。

在如今的互联网领域，Facebook的创新能力一点也不弱于google。上篇文章谈到Google，今天再来谈谈Facebook。首先声明，由于没有在facebook实地工作过，因此，对Facebook的质量控制体系，均来自于Facebook工作的员工及网络相关资料的论述。

在分析FB的质量控制前，还是需要先了解其文化特点及业务形态：

1、“这是《财富》500强中首家由千禧一代创建的公司，”Facebook前人力资源和产品经理莫里·格雷厄姆(Molly Graham)表示。出生在1980年以后的千禧一代，常常无拘无束，并抱有一种幻想——工作应该是一件有趣的事情。

而Facebook的CEO，接受了年轻人的特点，并为他们精心制定了管理方法。Facebook高层精心设计下“黑客“也是成为Facebook的企业文化标签。“黑客”让Facebook显得卓尔不群，它标志着Facebook始终拥有着最先进的生产力，旨在通过不断的创新和实验来拉近世界的距离。

Facebook的企业文化受到了马库斯·白金汉(Marcus Buckingham)的影响。白金汉是一名出生在英国的管理专家。他呼吁人们“扬长避短”，建议经理们在分配员工职务时要迎合他们的优势。

Facebook甚至鼓励低级别员工质疑和批评经理。谷歌的管理结构更为森严，成为一名“经理”意味着拥有更大的权力。而在Facebook，“职称毫无用处，”大家只看你的工作质量、信念的力量以及影响其他人的能力。”

用户对社交产品质量的容忍度相对较高。比如现在连不上，等一会在连接也可以，现在发布不出去可以等一会再发，粉丝数量统计有误，没有人太关心。其实facebook并不认为自己的质量差。他们认为产品的质量高低不是有多少个failed测试用例,有多少个bug来确定的，而是由用户对质量的期望值来决定的。

如果用户对产品质量的期望值很高很高，一个bug漏掉了都会造成质量差的印象，用户很有可能放弃使用。相反，如果用户的期望值一般，100个bug漏掉了都不会影响用户继续使用。所以facebook产品发布的条件是满足用户对质量的期望值即可。

相对宽松的产品发布周期。不想微软或google很多产品已经在市场上，用户对下一版本的发布时间和新增加功能的期望很高，这往往给产品开发组的压力很大。Facebook基本没有这个问题，它有适合自己的发布期限，不用受到外界干扰。

因此，在其产品研发团队组成上，依然可以保持小的研发团队规模，同时保留创业团队的特点。Facebook 项目的人员配比：一个项目一般是两三个设计师、5-10个工程师，产品经理要确保代码按时发布。

每个工程师自始至终负责产品。从最开始的一个想法，到开发原型，到内部审核，反馈，到产品开发，上线和维护，全部有工程师自己搞定。

非常看重反馈，尤其早期内部反馈。他们鼓励工程师有了想法后，尽快开发出原型，尽快得到反馈。

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

相比较于Google，facebook确实没有测试工程师。不过，Facebook 仍然有负责质量评估的工程师，并积极鼓励每位工程师报告产品漏洞。而且各角色相比较于传统公司定位也有所差异。

1、同谷歌一样，Facebook 的企业文化同样以工程师为主。一名工程师说：“产品经理基本上在这里毫无作为。”工程师可以修改尚未正式上市的产品规格，在任何时间提出新的功能创意。

2、产品经理如果要获取开发资源，不会如很多公司通过立项评审然后组织分配，而是需要产品经理通过自己发布产品的创意，吸引有兴趣的工程师。

3、与产品经理确定产品定义的方式不同，产品经理通常不会干涉工程师的偏好，如果出现争论，工程师们会开发出原型机，用一周的时间开发某项功能并进行测试，以确定它是否值得推出成品。通常情况下，新功能都是由 Facebook 员工亲自测试。

开发对质量负责：开发从设计，实现，测试，到部署都要自己做。其它做工具，流程的工程师通过开发工具和流程来帮助开发人员更为简单方便地做测试，做部署和做监控。每个开发人员有自己单独的测试环境，测试环境就是运行在开发本地机器上，部署非常简单快速。测试环境用的是真实的用户数据。

持续集成和测试自动化：每周发布一次。星期天晚上，要发布的构建从主线上分支出来到发布分支，到星期二的中午如果没有大的问题，就可以上线了。所有的测试运行控制在10分钟以内，所以不需要考虑不运行哪些测试用例。运行所有测试用例。（只是听说，没有经过考证。）

严格实施代码审计：在Facebook 做 code review时间大约占50%，管理者对代码质量负有一定责任。甚至代码质量高于一切：Facebook Code review是重点KPI考核的对象，实行连坐制，如果因为代码质量问题，那么产生的KPI责任包括领导30％、程序员50％、审核人员20％。

在代码checkin之前，都要由专人进行review。Facebook 创始人兼 CEO 马克扎克伯格会亲自对 News Feed 每个代码更新把关。在 Facebook，所有重大升级的代码都进行强制评估，任何一个改动都至少由一人把关。但是，无论工程师对 News Feed 做出任何改动，都将由扎克伯格亲自把关。

内测（dog food）：发布之前，公司员工使用要发布的功能。2－3天之内可以有几百个或上千个人在使用新功能。负责要发布功能的开发人员在星期天晚上到星期二中午之间会做大量的测试（一边上班，一边刷微博，岂不是很爽）。

通过灰度发布控制风险：新功能本身质量可能有问题，新功能也可能影响其它现有功能。为了减少或控制这些风险。Facebook开发了一整套完善的发布，控制，监控流程和工具。

做到：1.测试通过后，产品质量基本有保证。2.即使有漏测的bug，只会影响很少量的用户。3.及时监控到问题。4.及时修复。

产品监控：通过社区讨论的正负面舆情，及与历史应用数据的对比情况，监控产品的系统的运行状态技术修复。

Facebook质量控制中引以为豪而且倍受瞩目的就是“没有专职测试工程师”，所以个人认为，专职测试工程师是个非常模糊的结论。尤其现在我们对产品质量控制方法的不断演变和提高，“测试”的概念不仅仅是指找bug了，所有围绕提高产品质量的工作都是测试。

头衔上有没有“测试”不重要，有没有“测试”岗位不重要，重要的是如何有效保证和提高产品质量。因此，某种意义上，开发工程师、运维人员，其实都承担了测试的职能，但没有作为专门的岗位存在而已。

大家其实也关心，这么创新的氛围下如果确保Facebook员工的质量意识呢？我认为其实有2点非常值得借鉴

1、公开透明化：Facebook的每个员工都有个积分系统，其他员工可以对其进行”点赞、踩“，当然，对工程师而言。如果在发布过程中，出现有代码bug导致无法顺利发布的、或者代码审查时发现代码质量很差的，都会被“踩“。

当然，工程师努力取得牛逼的业绩可以获其他人的“赞“。这个积分直接会影响半年一度的绩效评估。而且，透明化后如果经常被裁的员工，在公司也很难立足了。

2、严格结果考核：工程师负责质量，如果在运维时出现由于某工程师代码bug导致发布回退，或严重质量事故的，会导致该工程师被“解雇“

因此，Facebook在质量控制过程上有一套方法，在考核激励上，也确保每个工程师必须重视自己代码的质量。因为，除了自己没有其他人为你的代码负责，而且一旦出错就是工程师的全责，无可推卸。保证考核制度简单，易于实施。

Facebook确实对员工赋予足够的信任，但由此对立面。每个员工一旦违反规则，必须承担严重的后果与责任。所以，对于很多人来说其实facebook的氛围其实压力非常大，而不像外界想的那么好“混“，创新企业的工作压力不大，其实是误解。因此，也印证一句话话，“天道酬勤”，创新也是如何啊。