有很多小伙伴问，测试职业的天花板是不是很低？
在回答这个问题之前，我想请大家先想一下，当初自己为什么会选择测试这个职业？入门门槛低？不需要写代码？工作比开发轻松？还是其他。这个理由或许就是问题的答案。很多测试人员之所以选择这个职业，是因为觉得测试相对开发来说比较“容易”。所以，天花板其实不是别人给的，恰恰是自己给自己设定的。
我在之前的文章“探索：测试的核心价值到底是什么？”里提过，不论是开发还是测试，或者 SRE、DBA 等等，他们在核心能力点上有很多共通之处，只是在末端领域方向上有所分化。测试从本质上说，只是开发的一个方向，而不是区别于开发的岗位。因此，理论上他们之间可以相互转换。
事实上，我所在的企业里，测试转岗开发的情况非常普遍，这就足以说明这个问题。即便是测试专业，做到 P9 甚至更高级别的情况，也不是没有。他们既在技术上有深厚的基础，又在业务上有独到的见解。所以，所谓的天花板，最终取决的还是自己对测试职业本身的认知和实践。
有不少人会想，自己学技术并不擅长，但可以凭借熬资历坐上管理岗位，就能绕开技术的短板。而现实中的确也有很多这类情况，管理岗位可以不用亲力亲为，只需招聘比自己技术能力更强的下属来完成任务，看起来似乎一切都很理想。
这种途径真的可行吗？
我们需要用足够长远的眼光来看待这个问题。过去几年在互联网红利的加持下，企业需要抢占地盘，达到赢者通吃的目的。这个时期业务的成败，更多依赖的是投入速度而非人员素养，因此企业才会大规模、高薪水地进行招聘。在人员数量极速膨胀的情况下，难免就会鱼龙混杂。
但是行业的发展都有周期性，一旦进入冷静期，就势必要做出自我调整。在经济低迷的市场状况下，资本不再轻易为难以预见的收益买单，企业管理也由于资本投入的减少，开始由扩张化转为精细化。这也是近期“裁员潮”的原因：市场并不是没有空缺，只是变得更加理性。而成本高、产能低的纯管理角色（不要忘了测试毕竟是技术岗），在这种变化中就有较大的可能被“结构优化”。
退一步说，无技术的管理，即便幸运地在行业下调期保住饭碗，在团队内也会遇到不少的挑战。因为不懂技术，无法在方向上做出决策，无法判断下属产出的价值，优秀人才渐渐流失，团队整体走向平庸，自己仍然会遇到瓶颈。并且行业也在动态发展，终有一天量变会演变成质变，引起新一波的结构升级，如果能力没有跟上，依然逃脱不了被淘汰的命运。
那么测试技术是不是等于写代码？
首先我比较反感现在市场上把测试岗位分为“手工测试”和“测试开发”。这种划分方式，一方面强行降低了“手工测试”的入门门槛（手工的意思不就是点点点？），造成行业能力水平的混乱；另一方面让“测试开发”产生一种不该有的优越感，为了有别于“手工测试”而脱离业务。
我们必须要明白，技术存在的意义，就是为了产生业务价值。手工测试也好，自动化测试也罢，都是为了让业务发展得更好。比如为什么要做自动化测试，一定是因为我们判断它能给业务带来好处，而不是主观上或习惯上觉得要有自动化。因此，强行将自动化测试、性能测试与业务团队剥离，只会让两个部分的人员都没有成长。
举个例子，较早前我和教育行业某公司的一位测试经理交流过团队组建方法，她很惊讶于我们整个团队都在写自动化而不是构建专门的自动化团队。而我告诉她的是，只要采用合适的方法，让团队平均达到这种水平只需要三个月。我们经常过高地估计掌握技术的困难，也经常过低地估计自己学习技术的能力。
两年后，她的团队不巧遇到教育行业的调整，被迫进行人员缩减。优化掉的并不是“手工测试”，而是“测试开发”。她也很坦白的告诉我，少了这些测试开发，业务依然能够运转，但少了手工测试，团队立即就会完蛋。现实就是如此，个人的价值体现，最终还是要由业务价值做出判断。
讲到这，上面问题的答案就显而易见。没有所谓的手工测试和测试开发，技术也并不等同于代码。我们是否学习和采用某种技术的唯一标准，就是它能够给自己的业务带来多大的帮助，仅此而已。
当然，这不是说代码不重要，而是说要明白为什么学代码，学完代码又要如何应用。代码之所以关键，是因为它是很多技术的基础。比如自动化测试需要写脚本，白盒测试需要 Code Review，开发测试工具也离不开编程等等。
同样的，每个领域也都有自己的专业知识：接口测试需要理解 HTTP 协议，安全测试需要理解攻击原理，性能分析需要理解技术架构...... 技术世界浩如烟海，我们不用急于求成，可以在实践过程中，逐渐掌握各个领域需要的技术点，由点到线，再由线到面，最终发展成全面的技术体系。
测试之道的成长，从来没有捷径。这个世界不缺大道理，缺的是付诸行动的决心。明代哲学家王阳明在数百年前就提过：“知是行的主意，行是知的功夫；知是行之始，行是知之成”。