【腾讯TMQ】【测试左移专栏】从测试左移到工程生产力

作者：探路者

团队公众号：腾讯移动品质中心TMQ

编者注：随着互联网行业的发展，质量管理的方向逐渐向生产过程看齐。2017年是TMQ变革的重要年份，本文拟通过一个宏观的视图，给读者展现此次变革的完整思路，希望能带给大家一些启发。作为TMQ 2017年的重点工作，测试左移在多个团队中已经开展了起来，具体他们是怎么做的，有哪些好的实战案例，我们会陆续挑选一些分享给大家，请各位读者同学们期待。

一、测试行业现状分析

近几年随着移动互联网的飞速发展，整个行业一派繁荣。市场竞争之激烈，业务变化之快速，几乎是前所未有的。由此带来的需求是，产品迭代要快，质量要好，于是大家都依赖测试团队来对质量把关。测试团队的规模越来越大，分工越来越细。但是，这样做的结果是，开发只管生产，至于质量，交给测试同学吧。表面看来，测试团队岂不是更受重视？但是，测试团队已然变成了一个彻底的下游团队，它的价值在于上游团队的工作没做好。开发团队逐渐失去了质量意识，因为他们知道有人会为他们兜底。对于整个组织来说，质量的成本不断的被拉高。即使很多人不在意前几个问题，但是在如此激烈的环境中，测试团队真的做得很“愉快”吗？

回顾软件测试的历史，会发现它几乎是和软件开发同时诞生的，并且，测试一直都是伴随着编码活动的。软件测试工程师这个职业，也是随着软件工程的分工越来越细后分化出来的。

再看看以Google, Facebook为代表的世界一流互联网公司（下文简称“GF”），他们只是通过非常少（甚至没有，因项目而异）的测试工程师来保障质量。这里就不详细说GF是如何做测试的了（有需要的可以去读读《How Google Test Software》这本书）。

从国内行业的趋势来看，GF这样的理念已经开始落地了。国内很多公司都陆续组建了EP团队，大家熟知的有阿里、滴滴、美团等。要做到GF的水平，不是一蹴而就的，有文化的因素，有人的能力（工程素养）的因素，行业环境的因素。就像很多年前，敏捷开始从国外传入到国内，很多人都说咱们国内的情况不一样。但是到现在你看大家都是在做敏捷，并且都能找到适合各自的敏捷研发模型。所以，第一这个事不是不能做，只是它还比较新，大家需要有一个过程；第二，也不能完全照搬，得找到适合自己的方式。

但同时，我们也要有清醒的认识，这并不代表我们不需要测试工程师这个岗位了。我们想做的，是想把质量这样的事情，重新放回到开发的过程中，同时对测试同学的未来发展，开辟一条新的道路。好了，道理说起来总是容易的，关键还得从一点一滴做起。从17年开始，TMQ就提出了“测试左移”，团队转型的思路。

注：研发流程图都是从左侧画到右侧，测试一般都在右面，所以叫做“测试左移”。

二、MIG研发现状分析

基于此，TMQ分析了MIG的大部分产品研发的模式，和GF做了一番对比。

1、品质管理的理念

GF的品质由开发团队负责，产品的品质主要通过开发人员在开发阶段来保障。高质量代码是开发人员追求的重要目标之一，少量专职测试人员的职责是协助开发人员提升这部分工作的效率，简言之，GF的理念是“品质是开发出来”的。

MIG目前的现状是品质由测试团队负责，产品品质主要通过开发提测后，大量专职测试人员（含正式和外包）找出产品在开发阶段引入的bug并转交开发人员去不断修复而逐渐提升，最终达到发布标准，简言之，我们的产品“品质是测试并修复出来“的。虽然经历多年的积累和沉淀，这种模式也运行得很好，但终究不是最优的。

2、质量成本投入

在GF的研发模式下，缺陷都是及早的被发现并被修复，由此带来的成本非常低。通过侧面的一个数据可以反映：Google的开发测试比几年前就是10:1，如今只会更高；Facebook一开始就没有专职测试，据说近年来才有极少量的专职测试。

MIG在目前的研发模式下，需要通过测试和开发的工作产出交互，一方面测试需要花很多时间来测试，开发工程师消耗在Bug fix相关工作上的effort也非常多，而且问题发现越晚，修复代价越高。同样对比测试团队的规模，我们的体量是非常大的。

3、测试周期

GF的产品质量在开发阶段就已经达到很高水准，所以有些产品直接可以做到自动化的持续交付。即便需要专职测试人员介入的，因为交付给测试人员的产品质量已经很高，所以测试周期相对开发周期来讲也很短。

相对于GF，MIG从测试介入到版本发布，测试周期相对是较长的，这就从一定程度上将产品的交付周期拖长了。

4、缺陷修复的时机

由于GF的开发团队对产品的质量负责，在开发周期内绝大部分应该消灭的缺陷都被发现并修复了。

MIG的大部分产品的缺陷修复时机，集中在开发完成后，留给上线后的风险更大。

综上所述，MIG的研发体系在品质管理层面与GF相比有很大的差异，也意味着有很大的提升空间，所以我们要向GF学习，将品质管理和相关工作向研发的上游逐渐左移过去。一方面需要提升开发和产品团队的质量意识、开展相关工作，一方面也需要改变专职测试团队现有的工作职责、方式和能力模型。

三、工程生产力 (Engineering Productivity)

EP这个词有不同的叫法，有的叫工程效能、研发效能，本文还是按照字面意思来，叫做工程生产力。细心的读者可能会发现，EP这个词里面没有提到质量，因为质量是伴随着你的产品的必备属性，意思是高质量的效率。

回到根本问题上来，如果让开发团队来承担质量的责任，对开发团队来说有哪些好处？

1、质量成本降低：降低在产品基础品质保障上的资源相对投入，即在产品品质不变甚至更好的前提下获得更高的开发测试比。也就是说，或用更少的专职测试资源支撑现有规模的开发团队的产出，或用现有的专职测试资源支撑更大规模的开发团队的产出；

2、节省开发资源：开发团队从代价更大的后期修复问题变成代价更小的前期避免或修复问题后，节省的开发资源可用于更多有价值feature的开发；

3、缩短交付周期：由于提测质量变高，会有效缩短测试周期，若迭代新功能规模不变，则可以有效缩短整个研发周期，让产品新功能具备更快交付给用户的能力。当然，理想情况下，如果做到了持续交付，交付周期则更短。

四、测试团队的发展

大伙也许会问，你们这样做，不是把自己搞得失业了吗？当然不是这样。我们的目的是赋予了测试团队新的价值和使命，让质量回归到最合适的人和环节。外部的环境前面也讨论过了，如果不这样做，按现在的趋势，过不了几年，我们将会被动的被调整。有一句话说得好：与其等着被革命，还不如自己起来革命。

具体一点来说，对于TMQ团队的发展方向，有几条思路：

1、提升价值：为提升整个产品团队的研发能力服务，而不是做质量的把关者；

2、提升员工全栈能力：敦促团队成员提升开发能力，改进现有能力模型，向全栈工程师方向发展，扩大工作类型的适应范围；

3、调整人力结构：减少投入在基础质量上的人力，着眼未来，投入到前沿的AI、大数据评测中。

五、未完待续

前面说了这么多，这个事情具体怎么落地呢？在此打算把一些思路分享给大家，我们打算分几步走：

第一步：自己做。

在已有的测试方法和技术之外，探索有效果，投入产出比高的方法，目标是为了第二步。比如单元测试，code review，可测性，测试工具和平台等。

第二步：教开发做。

在第一步的基础上，寻找工程能力比较好的团队，合作推进，目标是让开发团队学会怎么做测试。当然这一步需要组织由上而下的推动。

第三步：技术服务。

随着越来越多的开发团队承担质量责任，对相关的测试基础设施有更高的要求，测试团队需要进一步提升自己的工具能力，要具备产品化的能力，最终转型为提供技术服务，而非人力服务。

原文链接：http://tmq.cs0309.3g.qq.com/2017/05/test/

获取更多测试相关干货 请关注我们的微信公众号——腾讯移动品质中心TMQ：

版权所属，禁止转载