目前几乎所有的大厂都在严格控制研发：测试比例，从3:1到5:1，甚至在“去QA化”。在这样的背景下，测试同学的价值在哪里？职业发展路径会怎么样？未来测试真的会消失吗？
带着这样的疑问，我访谈了一位14年的资深测试同学小余。2008年毕业的他，从最开始的Windows 技术栈，到加入互联网大军。做过很多业务测试，测试工具的开发，也从0到1建设过持续集成系统。目前负责多个业务测试和工程效率团队。
成长的关键路径
小余总结过去的14年，成长有两个关键节点。其一是从Windows 软件到互联网。
2015年，小余加入一家互联网公司，做搜索业务的测试。前几年他是做PC安全、WPS服务等Windows 软件开发和测试，对Linux几乎没涉及过。
入职后，发现自己不会的东西特别多，他开始疯狂补课。那时正是互联网如火如荼之时，他“很珍惜这个机会”，每天都加班到很晚。“每个月报销，看自己下班打车票上的时间都是晚上12点之后。”
在这样努力之下，他很快就完成了从Windows到Linux技术栈的转型，把整个检索的质量体系搭建起来。一年后在公司测试团队慢慢崭露头角。
现在回看这段经历，小余总结虽然硬能力是现补的，但测试需要的通用能力，比如测试架构能力，测试case设计能力等，之前的积累是能迁移过来的。“其实硬能力，比如代码能力，提升并不难，只要足够拼，都是可以很快学会的。”
这次的成功转型，他迎来了职业的飞速发展期，开始整体负责一个业务方向，开始带人，走上团队leader，到带几十人的测试团队。
不过小余认为自己成长的第二个关键节点，并不是团队越带越大，而是作为负责人，从0到1去做一个服务于千人研发团队的持续集成产品。
为了做好这个系统，公司组建一个虚拟团队，包含研发和测试，他开始有机会去带研发团队。持续集成国内做得彻底的公司不多，他所在公司是做得很早的一家，很多技术国内都没有成熟案例，比如容器化的建设。国内没有，就向国外公司学习，一点点摸索前行。
技术之外，最大的成长点是有机会完整地去做一个产品。“测试其实在整个业务链路中是偏后的，一般都是产品-研发-测试，而这次我有机会去全局去思考产品设计和项目管理，以及产品如何更好地推广、落地。”
这是一个很大的转变，“对我来说，之前作为QA看得层次太少了，更多是支撑好这个产品，保障质量，关注的是执行。而自己做产品，质量只是其中的一小部分，重要的是要不断思考方向该怎么走，当前阶段该做什么，以及这个产品怎么能让用户更好地使用，怎样才能真正帮到用户。”
虽然是给研发使用的内部产品，但也是一个完整的产品，而且用户就在身边，需要直面很多压力。
除了不断跟研发沟通碰撞，挖掘真正的需求之外，他还锻炼出一个重要能力——数据驱动的能力。比如这个关键页面会去看pv、uv、nps，看内部使用的满意度，工具的稳定性，成功率等。基于数据点去运营，去不断提升。
最后这个产品做得很不错，在公司全面推广落地，极大地提升研发效率。
测试的能力模型
我问小余，如何看待测试的能力模型，以及与研发能力模型上的差异？显然，这个问题他已经考虑过很多遍，迅速娓娓道来。
测试与研发能力模型上区别最大的是测试的基础能力，比如测试case设计，测试场景，测试方案，以及整个测试流程协调等。
相同的是对技术能力的要求，尤其是测试开发同学。但相比研发对技术深度的要求，测试更关注技术的广度。测开同学要交付的产品一般都是公司内部产品，不像研发可能要面对高并发流量，但对测开同学来说，能快速地完成工具开发非常关键。
测试同学的发展路径一般有三条：业务测试专家、测试开发专家、测试经理。不同路径，能力模型有一些差异。
能力模型中，硬能力——比如代码能力，不同编程语言能力，并不难，花时间都是可以很快攻坚的。“相比硬能力，我更关注QA解决问题的能力”。
对于业务测试，需要能快速判断当前业务的质量现状，并且基于现状灵活地运用自己掌握的测试、沟通等能力，和研发制定方案和解决问题，也就是测试架构的能力。以及当事情规划好了，如何利用项目管理能力，把事情去拆解落地，到最后的复盘和总结。
而测试开发的同学，建议关注整个工程效率，不要只做工具，更要关注工具的落地和实施是否真的有效果。
以上大多数测试岗位的能力模型要求，而14年的老兵，对测试同学的能力有更高的期待。
测试同学需要理解质量策略不是固定的，需要根据业务现状以及目标去调整。比如业务快速发展期，更注重保障基础的质量，不适合做精细化的卡口测试。而对于很稳定、高并发的业务，精细化、严格的流程卡口会更合适。
同时，要去关注质量上做哪些事情，能够更好地帮助业务去拿到结果。“需要明白QA只是整个公司的一份子，虽然测试的小目标是质量，但大目标是推进业务达成目标。”
“去QA化”，测试同学如何应对？
现在大厂都在控制测试比例，国外很多公司比如微软、Facebook，以及国内的微信支付都在推行“去QA化”，很多测试同学焦虑自己的价值。小余坦言这个问题也困扰自己很多年。
“去QA，本质是在解决一个效率问题，在不同角色中间流转，一定会造成效率的浪费。产品-研发-测试，测试发现bug，再反馈给研发，确实是有资源的浪费。”
那“去QA化”背景下，QA同学何去何从？小余分享自己看到的两种路径：
第一种：QA变成一个赋能的角色，把测试能力和工具、流程等等，赋能给研发和其它角色。具体质量上做的事情交给研发自己去保障，目前国外采用的比较多。
而在国内，这种方式走得并不是很顺，采取的是第二种模式，QA去量化和证明自己的价值。把质量更好地评估和量化出来，并且换算到业务价值。比如质量分提升多少，对于关键链路的转化率提升多少，影响多少用户数等等。同时根据业务价值的重要程度去安排测试资源和工具的分布。
未来关注复合能力
我问他对目前“卷”的看法，小余的回答让我眼前一亮。
首先，他认可一个前辈的观点——“卷的本质是因为我们还在增长。无论是国家GDP，还是互联网行业，其实都在增长。有了增长，大家才有卷的空间，大家才会觉得做得多做得快，就会拿到更多的结果和收益。”
而欧美，看起来没有我们这么卷，其实他们是从卷过来的。这些国家目前GDP的增速，互联网行业的增长速度都是不如国内。所以“卷”是发展中的一个阶段。