The Practice of Improving Software Quality - Facebook Article

Facebook has grown rapidly from a student project on the Harvard campus in 2004 to the world's largest social network with 1 billion users in just 7-8 years, once again witnessing the miracle of Internet entrepreneurial success. At the same time, its product development process has also become the target of many Internet product companies. Today we take a look at Facebook's practice in product quality control. Some people say that the current google is like the early Microsoft, and the current facebook is like the early Google. I think it makes no sense. Although Facebook is no longer a startup company, it is not difficult to see that it still maintains the style of a startup company in product development and quality control. In product development, they take a small R&D team as the core and follow several very important principles:
Be there from start to ship: Every engineer is responsible for the product from start to finish. From an initial idea, to developing a prototype, to internal review, feedback, to product development, launch and maintenance, all are handled by engineers themselves.
Show work early and often: Facebook takes feedback very seriously, especially early internal feedback. They encourage engineers to develop prototypes as soon as they have an idea and get feedback as quickly as possible.
Gets your hands dirty: Get your hands dirty, do it.
Don't fall in love: Internet products are constantly changing, you don't need to wait until a product is designed to be perfect before releasing it.
 
In order to follow the above principles, facebook engineers use the following quality control methods to ensure product quality:
Development is responsible for quality: development from design, implementation, testing, to deployment must be done by yourself. Other engineers who make tools and processes help developers to do testing, deployment and monitoring more easily and conveniently by developing tools and processes. Each developer has his own separate test environment, which runs on the development local machine, and the deployment is very simple and fast. The test environment uses real user data.
Continuous Integration and Test Automation: Release once a week. On Sunday night, the build to be released is branched off the mainline to the release branch, and by noon on Tuesday it's ready to go live if there are no major issues. All test runs are controlled within 10 minutes, so there is no need to worry about which test cases to not run. Run all test cases. (Just heard, not verified.)
内测 (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了,所有围绕提高产品质量的工作都是测试。头衔上有没有"测试"不重要,有没有"测试"岗位不重要,重要的是如何有效保证和提高产品质量。

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=324587766&siteId=291194637