一些做测试的同学，可能会转型项目经理、项目管理、团队管理，或者转型产品，各种不同的转型方向。本文作者结合自己转型产品的经验，分析为什么测试岗位转型产品越来越难？希望能给你带来一些启发。

分享我近两年的一个感受，并试着分析其背后的原因。职位只是外界对你工作内容的定义，我们从事怎样的工作，拥有怎样的生活，更关键的在于自己的思维模式和意愿程度。

这又是一篇拖更很久的文章，早在去年夏天，就有测试小伙伴问过我，是否可以转型做产品。一位甲方的测试负责人也和我聊过类似的问题，如何让测试人员具备更好的业务思维。虽然两位朋友的出发点不同，但其背后都反映了两个岗位之间千丝万缕的联系。

因为我本就是开发毕业，测试入行，之后通过测试+需求这“一头一尾”的把控，逐渐转型项目管理，又恰逢合适的机会最终走上产品这条路。

因此，测试岗位，于我个人始终存在不一样的感情。做过、招过、见过，也经历过这个岗位在互联网团队中的尴尬处境，自然也会萌生一些思考。

我认识很多测试同学，其后续有不同的发展方向，有的转型项目经理、项目管理、团队管理，当然大部分还是继续在测试这个岗位持续深耕，有的做到了测试主管、高级测试工程师等等。像我这样转型产品的也有不少，不过更多是在前些年完成的转型。

最近两年测试转产品的比例应该是呈下降趋势，所以今天借此来聊一聊为什么测试岗位（功能测试为主）转型产品越来越难，也试着回答一下前面两位伙伴的问题。

01 测试与产品的不解之缘

本身从软件开发流程来看，产品做设计，测试验证此设计的交付物，两者在一定程度上都可以归结为“业务导向”，关注点和工作内容存在诸多联系。之前的文章需求岗如何为实施团队赋能中，也提到了两者不分家的观点。

产品在制定最终的设计方案时，如果具备测试思维，会让自己的方案更细致、更健壮，尤其是异常情况的处理，提前想到了，需求评审时会更主动。

最近看了团队小伙伴的年终总结，好几位都提到了自己的需求文档规则不细致，对于异常情况考虑不足等问题。

所以产品和测试可以多多沟通，相互以不同的思维和对待系统的角度互补。

我相信一位合格的测试人员，对于系统的细节、处理逻辑是最清楚的。因为我们常见的系统规模，大多只配很少的功能测试人员，开发大概率仅对自己的模块了解，产品大概率仅对业务流程和各功能之间的耦合关系了解。所以最近两年我们经常在进行一些功能迭代时咨询测试的意见，初步探讨系统可行性和工作量，也是基于这个原因。

02 优秀的测试越来越少

2021和2022两年间，我大致面试了100位测试人员，base地遍布多个城市，从直观感受来看，靠谱的功能测试越来越少，使我不禁思考，为什么？

可能是整体基数的原因，可能是行业重视程度和发展前景的原因，也可能是其他我没有觉察的原因，致使越来越多的测试人员真的做成了曾经行业玩笑“点点点的工具人”，很少思考功能背后的缘由，很少思考业务背后的问题。

也可能没有遇到好的团队、好的领导。因为我相信在测试的过程中一定会有很多疑问，但是把疑问问出去之后，是否有人真的耐心解答？很多团队的负责人经常会说：你就按需求来、这不是你操心的…从而逐渐磨灭了各位伙伴心中的求知欲。

也有很多公司、团队管理者把测试定位成一个“流程化的环节”，只是为了完成这个测试任务而招人、用人。哪里有测试需求，就把人派过去，可能一个月测一个项目，测完即走，奔赴下一个战场。

这种情况对于测试从业者来说，很难形成高效的经验积累。如果是同类业务还好，可以通过不同的客户诉求、定制化场景培养业务思维；如果是不同的业务，短时间内很难理解，到头来项目做了不少，但最终沉淀下来的也许不多。

即业务的连续性不足，更多的重复劳动带来的只是经验的积累，很难形成突破式成长。

平心而论，测试本身在互联网行业中，入门的门槛相对较低。俗话说人人都是产品经理，与其相对的，其实人人也都可以是功能测试。所以很多其他行业想要入局互联网的，会优先选择功能测试这个岗位，因此对软件工程的理解本就有很多不足。

最后，也可能是因为看不到更高的职业发展路径，让很多同学缺少长期目标，逐渐的接受自己的现状，逐渐的不再向上生长。

总之，优秀的测试人员在肉眼可见的减少，而且产品圈现在也是供大于求，在供需不平衡的情况下，普通测试很难转，优秀测试不愿转（自己不愿或领导不愿）。

但愿我以上表述存在“以偏概全”和“主观臆断”的逻辑谬误，因为测试出身的我，更希望测试行业能够人才辈出。诚然，有很多优秀的测试伙伴，从功能到性能、自动化、安全等等领域均有不错的发展，但更多的是比例、是整体表象，但愿这些言论不会给自己招来阵阵骂声

03 测试更适合做需求分析

如果测试真的想转型产品，中间跨过了一个过程，这个过程是“需求分析师”。

我认为功能测试最容易转型的岗位就是需求分析师，除了显而易见的功能、逻辑、细节，还有外部的沟通会给你的转型带来助力。

尤其是外包类项目，项目组内的测试会有很多机会和甲方的测试人员、业务人员对接，沟通缺陷、讨论合理的场景。在此过程中，无论是对自己的表达能力、应变能力，还是业务理解能力都会有不错的提升。

我当初转型，就是因为通过频繁的和客户沟通，逐渐从接收问题，变成了解决问题，逐渐开始和项目经理一起讨论需求，向开发讲解修改方案。

所以如果功能测试真的想转岗，我最推荐的就是需求分析师。

04 需求分析和产品经理间的“窗户纸”

但是需求分析和产品经理之间存在不小的区别，我在去年的一篇文章中也提到过，其中涉及团队模式的区别、工作重心的区别，最重要的是思维习惯和目标的区别。

虽然很多公司的产品经理实际上也是在做需求分析的工作，但是真正的产品经理和需求分析师之间，还是有一层“窗户纸”，很薄，但是不捅破依然是两个维度，捅破了才有可能互通。就像我的产品团队，最近在制定2023年的年度目标，我的目标就是真的做产品，而非做需求。

以我现阶段的理解（不一定对哈，欢迎讨论），需求分析和产品经理最大的区别在于思维方式和行动目标，这两者的区别导致了工作职责和日常内容的不同。

需求岗位更多是项目制管理中的关键一环，而产品岗位更多是研发管理中的关键一环，所处的环境不同，导致了这两者的区别。

即便两个岗位都在写文档、画原型、和其他岗位协同、和客户或者用户对接，但需求可能更关注于合同范围、产品更关注于业务边界；需求可能更关注于交付效率，产品可能更关注于标准化；需求可能更看重客户的意见，产品可能更看重用户的意见。

需求思维和产品思维之间的转化，也很难。

（特别说明：以上内容存在以偏概全的问题，希望各位能够领悟精神，不纠结于具体用词。而且对于需求和产品并没有优劣之分，只是不同公司不同团队下的模式不同罢了）

所以测试更适合转型需求分析，如果真的对产品感兴趣，可以再从需求分析转型到产品。当然，很多公司的初级产品其本质更像是需求分析，如果能找到这样的公司，从初级产品经理做起也是不错的机会。

05 测试所处的工作环境变了

随着近些年行业的发展，团队中更加强调职责分明、各司其职。虽然测试拥有从业务角度和体验角度提缺陷的权利和义务，但久而久之很容易让团队中的其他岗位不耐烦，而此时如果遇到一些相对教条化的领导，大概率不会给测试人员太多的自由度。

而且对于一些第三方机构的外包测试而言，经常一个人对接多个项目，多个团队甚至多个公司。此时每个项目的出发点和利益点可能都不相同，而且项目组为了更快的上线，势必不希望测试人员过于“思维发散”、“较真”、“爱提建议”。

诸如此类的工作环境，也很大程度上致使测试人员更愿意（或者不得不）恪守自己的职责边界——一切以需求文档为主

需求文档上写了，我就需要测，没写就不测；写的不合理，反馈给需求人员或者业务人员来定夺。这也许是大多功能测试同学很难突破的一道坎。

我记得有一段时间，测试工程师的地位和重视程度比较高，可能大家都发现了测试的必要性。但是没过多久，这阵风又没了。可能大家逐渐发现，一个高质量的项目交付，一个好的产品上线，测试仅是其中一个环节，更多的是需要从管理体系、流程规范等方面入手。所以慢慢的，很多测试同学就开始考虑要不要转行。

06 扪心自问，你真的想吗？

城外的人想进去，城里的人想出来，盲猜各行各业有很多这样的人都有转行的想法。但是，我们需要认真考虑的是：这真的是你想要做的吗？

以测试转行产品来举例，我们需要先分析自己为什么想转？是因为觉得这个岗位不受重视？没有成长空间？整日受气？不被开发尊重？还是因为什么？

分析出来的原因，再进一步分析背后的底层逻辑，可能会发现最终的问题还是在自己。即便换了岗位、换了公司，现在所遇到的问题大概率还会遇到，因为我们的底层逻辑和思维习惯没有变。

仅仅依靠外力，不足以推动自己的转变。所以一定要自内而外有强烈的意愿，才能让你在面对后续困难时持续斗争。否则浅尝辄止，最终会让自己更不再愿意主动求变。

如果你现在是测试团队的负责人，想让自己的下属具备一定的产品思维，以便更好的开展后续的工作。这时我的建议依然是，先确定他们真的想拥有产品思维吗？或者说如何让他们有这个意愿。再确认你们的工作环境，允许、或者适合测试人员具备产品思维吗？之后才是如何培养，如何转变的问题。否则我们提出一些要求和设想，在真正推进落地时会困难重重。

而本身培养产品思维、业务思维的方法有很多，我本身也需要在产品思维上不断加强。今天先不讨论怎么做的问题，最近我在读《底层逻辑》这本书，对于思维、产品、规律等方面又有了一些新的理解，待我认真读完之后，再聊怎样培养产品思维吧。

07 职位是定义，思维在自己

回到今天标题中的“转岗”两个字，其实我最终想表达的观点是：

职位只是外界对你工作内容的定义，我们从事怎样的工作，拥有怎样的生活，更关键的在于自己的思维模式和意愿程度。

即便转岗，没有转换思维和习惯，依然会面临诸多问题，甚至是更严重的问题；反之当我们养成了相对好一点的习惯，培养了更成熟全面的思维模式，即便不转岗，也能有自己的办法去应对当下的问题。

而且对于这些问题，我的另一个建议是【主动】，主动面对，主动接纳，主动沟通，才能主动解决。

• 比如我们可以主动和上级沟通，表明自己的意愿和想法，看看领导怎么回答；
• 比如我们可以主动和产品同事聊天，聊聊他在工作中的收获、困惑、甚至于做产品的心路历程，看看这些故事，是不是你想拥有的；
• 你还可以回顾自己工作中的收获、困惑以及心路历程，通过复盘来寻找问题到底出在哪？

找到关键问题，才更容易解决现象。

以上就是今天的分享。因为我已经脱离测试岗位多年，更多以旁观者的角度分析，所以内容中若存在纰漏烦请多多理解、多多指教

写在最后

本文仅是针对一些实际情况进行分析，并不涉及测试、需求、产品三个岗位优劣的评判。任何一个优秀项目的诞生，任何一个好产品的问世，都离不开各个岗位的通力协作和各司其职。

今天虽然是在探讨测试和产品之间的现象，但也能客观反映出很多其他岗位、其他从业者的疑虑。其实无论是哪个岗位，只有自己深入探索，自驱成长，长远规划，持久坚持，才能真正掌握“核心竞争力”。

这份核心竞争力，能够让你应对大多数的外部因素，走出内心的焦虑和彷徨。至于如何做，因人而异，在此我分享《底层逻辑》中的两段话，希望能给你带来一点帮助。

学会选择，常常就是学会放弃：选择一个，放弃其他。选择有时比努力重要，但放弃有时比选择更重要。我们应勇敢选择，然后享受好处，承担坏处。

努力的时候，都希望大家瞬间认可，而出了问题后，却不去想几个月之前的懈怠。这是很多人都容易走进的思维误区。

——《底层逻辑》

本文没有写具体的方法，这和我之前的风格有些差异。但最近的体验就是：想通了，方法自然会出现；想不通，再多的建议也是徒劳，况且这些建议不一定真的有效。

所以，希望我们能通过不同的文字体会字里行间的观点~