客观看待“去测试化”的论调

看到这样一个很有意思的问题：

研发负责人明年规划去掉测试岗位，QA 工作由研发来负责。但当前团队的自动化测试覆盖度不足，短期还需要大量的手工执行测试用例，该怎么办？

诚然，这几年经济和就业形势很差，导致很多公司开始玩降本增效的策略。对普通打工人来说，工作时间没见降低，工作强度和压力反倒是高了不少。再加上隐隐悬于头顶的裁员危机，大家只能紧紧抓着当前的工作不松手。

但从客观的角度来看这个问题，软件测试只是整个软件研发交付环节中的一部分，且由于相比于研发岗位，测试的产出和价值确实没那么直观体现，在降本增效的大环境下，去掉测试岗位，QA 由研发来负责就显得没那么突兀。

但很多人陷入了一个认知误区，即裁掉测试岗位我就要失业了，软件质量就会下降。

但事实上，无论是软件测试还是软件研发都只是软件研发交付环节中不同的工作类型而已。从来没有明确的规定，说软件测试岗位只能做执行测试用例的事情。

“去测试化”其实仅表示不再设专门的软件测试这一岗位，软件测试工作不再由专门的 Title 为软件测试工程师的人来做，但软件测试环节在软件产品的研发交付过程中依然很重要，软件测试工作更多的由开发工程师来负责。

即以软件测试为 Title 的岗位可能会变少，但软件测试这一工作类型依然存在，且会更加重要。

回答一下本文开头提出的问题，面对去掉测试岗位这一挑战，该怎么办。

首先，少了软件测试这一岗位，但软件测试这一环节的工作照样需要有人做，那测试同学大可选择转研发岗位。

其次，无论是手工还是自动化执行测试用例，都只是达成质量保障目标的手段之一。除此之外，质量规范、风险评估、项目管理、环境治理等工作才是保障产品按时保质交付更为重要的因素。

不妨抛弃传统的测试思维，以质量教练的角度来为产品的质量保障做出新的贡献。

再次，将“去测试化”看作一场际遇，让你职场转型的机遇。

软件工程领域早期是没有专职的软件测试岗位的，后来随着技术理念的发展进步，分工进一步细化才出现了这一岗位。但技术在不断发展，原有的工种消失和转型也是应有之事。

最后一点，微软和谷歌已经彻底去测试化，将测试职位取消。国内我所知道的，比如阿里从去年开始也在逐步去 QA 化，测试转岗研发。这是大势所趋，不以个人意志为转移。

与其抱残守缺，不妨主动转型其他岗位，或者在还有精力奋斗的年纪，尝试探索其他行业。

我和星球里很多同学聊过职业生涯发展规划的话题，很多测试同学都存在类似的想法，担心自己技术不行做不了研发，或者“去测试化”自己就失业了，不知道该做什么，但这仅仅是惯性思维在作祟。

什么叫惯性思维？即以自己擅长的或者已经获得成就的方法作为万能答案，做什么事都是这个思路。

在这种趋势还正向发展的时期，依赖路径固然能发挥很大作用。但当大环境发生变化时，惯性思维或者说抱着依赖路径不放只会让自己深陷泥沼，且越陷越深。

更好的做法是主动突破自己的舒适区，多探索一些未知领域，不断拓展自己的能力边界。这样即使环境变化了，你也有更多的底气和腾挪空间，走出自己的职场第二曲线。

掉进水里不会淹死，一直呆在水里才会淹死，愿你能懂。