软件测试人员迷茫之中如何找到职业发展的方向？

news2024/11/25 7:51:40

出现迷茫或焦虑的原因是什么？

　　也许每个人的原因不一样，但不外乎是下面这些原因叠加的结果。

　　1、敏捷和DevOps开发模式的推行，虽然20年的历史是否已经证明“敏捷已经失败了” 暂且不管，但敏捷/DevOps之风刮的还是很厉害，开发和测试越来越融合，一些头部企业正在取消“测试工程师”这样的岗位，从国外的微软到国内的腾讯，而不少企业也在不断追求越来越高的开发测试比，或者现在只招“测试开发工程师”。

　　2、测试的天花板比较低，自己上升的空间比较小，在职位上升通道上，测试工程师很难成为研发部门负责人、研发总监、研发VP、CTO等；虽然有些公司专门也为测试人员设置了专家、高级专家、架构师这样的岗位，但不少公司没有这样高端的测试职位。

　　3、35岁是一个门槛，许多人也担心到了这个年龄，公司就可能不和自己续签合同。虽然这不只是测试人员所面临的达摩克利斯之剑，开发人员也会感受到即将到来的末日。

　　4、测试工作被机器人替代。人们经常分享AI助力自动化测试、机器人完成稳定性/性能/用户体验等测试，也会给测试人员的危机感。

　　如何走出迷茫？

　　先概括为基本的两点，后面再展开讨论。

　　1、坚守现在的测试岗位，把各项工作做得极致，迅速成长为某个方面的专家或测试架构师，也可以成为技术管理者（如测试经理/测试总结，但这个风险会大些），对公司或对个人有很高的价值，使自己立于不败之地。

　　2、看清未来发展趋势，勇于接受挑战，不害怕，努力转型，成为一名开发人员、产品经理、项目经理或市场经理等。

　　先说“坚守岗位”。即使开发和测试融合，测试工作始终少不了。在一个全功能的团队中，各个成员的分工还是会有不同，会发挥各自所长，自然也会发挥测试人员的测试强项，侧重测试工作，至少在团队转型的初期。即使在之后的相当长时间，也需要一个Test Owner（测试的负责人），负责整个测试/产品质量的工作，具体负责测试的计划、测试整体方案设计、指导整个团队做好测试。如果系统复杂，会在团队之上，在整个产品线的组织架构上设置专业的岗位，如性能工程、用户体验、混沌工程等技术岗位。

　　所以，如果你成为测试某个方面的专家，如业务测试专家、测试需求建模专家、用户体验专家、性能测试专家、混沌工程专家、性能工程专家、质量工程专家等，在公司就一定有立足之地的，即使公司老板追求越来越高的开发测试比，也只会淘汰一般的测试工程师，不会淘汰专家。

　　“35岁”那个槛，也不会对专家起作用，我在（盛行35岁会被淘汰的）某家公司看到白发苍苍的测试专家。如果只是一个普通的工程师，无论是开发还是测试，到了35岁的确有危机，而如果是专家，这个危机基本不存在（虽然会有其它危机，危机总是存在的）。

　　要想成为专家，一定要有良好的思考能力，经常反思，不断总结，并具有工匠精神，把事情做到极致。

　　其中批判性思维是我最为推崇的，善于反思，更容易看到问题，纠正自己的问题。同时，要经常写文章发表，或走出去参加沙龙、大会分享，把自己的想法、思考和问题的解决方法进行总结并讲出来，看看其他人的反馈，如果经得起别人的质疑或挑战，说明就是对的。绝不能自己躲起来，一个人自嗨，总觉得自己是对的，那将害了自己，要么将一条错误的道路走到底，要么进步很慢。

　　工匠精神，精益求精，例如对用户体验测试的研究，其中有个指标是响应时延，可以分为启动响应时延、切换响应时延、滑动响应时延等指标的验证，然后进一步进行人因分析，查找相关论文研究成果，了解可感知的时延是多少毫秒，点击时延和拖动时延有多大的差异等等，如下图（来自绿盟标准）所示。

要成为专家，不仅要专，深入某个领域研究，有精湛的技术和丰富的经验，而且也需要有广度的知识，如了解研发的开发模式、产品的业务架构/技术架构，了解软件的设计模式、面向对象的分析/设计/编程、操作系统、数据库、网络等等，还包括领导力、沟通/协同技巧等软实力，成为T型人才。

　　再说转型，更不用怕。团队要转型，像微软那样的航空母舰都要转型，个人转型岂不是很简单吗？况且人生没有几个转型，也就枉来地球一趟。如果一辈子只做一件事，也有遗憾。

　　从测试转开发，没那么难。在做测试时，可以做些储备，例如从自动化测试入手，接触测试工具、学习编程语言，借助Java、Python开发测试脚本，然后再深入一些，针对一些开源的测试工具，进行二次开发或为工具（如JMeter）开发插件，增强某项功能（如更酷的测试结果展示）。平时或工作之外，也可以给自己安排开发任务，去开发一个测试工具，或参与开源软件项目。而且，今天学习材料，无论是图书、视频、MOOC还是代码练习平台、社区交流平台等等都不缺，只要学习，就不缺材料，只是缺少毅力和坚持。