会写代码,只是测试开发工程师的门槛——关于「软素质」的讨论
我必须要指出，也许10年前是这样，但是在越来越卷的今天，“会写代码”，或者说有一定的技术能力，只是这个岗位的门槛。想进入这个岗位，或者想在这个岗位发展下去，真正重要的，是一整套“软素质”。毫无疑问： 这些软素质，往往不会写在 JD 里，却决定了在团队里的位置、话语权，以及职业上限。如果你是个学生，想走测开方向｜或者你是个开发，想转测开｜亦或是你已经在测开岗位上，我都希望我的这篇文章能对你有些帮助。这篇文章，我想系统聊聊：测试开发工程师，到底需要哪些软素质。在开始之前：为什么“软素质”听起来这么虚？
很多测试开发，特别是学生，当从猎头或者HR处打听到：但如果你真的参与过测试开发的面试设计，或者带过人，就会发现：领导口中的“软素质”，并不是性格评价，而是那些没法写成代码、却直接影响结果的能力。它们之所以显得“不可量化”，只是因为很难用几道题考出来，一、对“风险”的敏感度，而不是对“BUG”的执念
有一个经典梗，说BUG多就扣开发的绩效，BUG少就扣测试的绩效。但这只是一个梗而已，BUG的多少不能说明开发的能力，也不能说明测试的能力。测试开发工程师的视野要迈过的第一道坎，是从“找 BUG”转向“控风险”。不是所有 BUG 都值得挡版本，但有些风险，哪怕只有 1% 的概率，也必须死磕。
二、站在“整体系统”视角，而不是模块视角
当然，职责边界很重要。 但系统性思维，恰恰是测试开发最重要的软能力之一。没有人从“系统整体”去看它。
而测试，往往是最后一个、也是最合适站出来补这个视角的角色。
三、沟通能力：不是“会说话”，而是“会对齐”
当然，“会说话”、能输出、维护人际关系都是优势，但对于沟通能力来说，只有一个目标：降低不确定性，让事情更快往前走。而优秀的测试开发，会主动去“对齐信息”，而不是事后证明自己是对的。
四、敢于坚持，但知道什么时候该让步
坚持，是为了降低系统性风险，而不是为了赢一场争论。成熟的测试，会在关键点上寸步不让， 也会在非关键点上，体面退场。
五、负责程度：可以摸鱼，但该盯的东西一定要盯
很多人一听到“负责”，心里会本能抗拒。 因为现实中，“负责”这个词，常常被滥用成：但成熟的团队，对测试负责程度的期待，远没有这么简单粗暴。你可以不一直高强度输出，可以不显得特别忙，甚至可以在一些无关紧要的地方适度摸鱼，但在关键时刻，你有没有把该盯的东西真正盯住。- 线上指标异常时，有没有人持续跟进而不是丢一句“已反馈”
这些事情，往往不会写进测试用例，也不会每天有人追着你问。但一旦出问题，所有人都会回头复盘：当时，这件事有没有被当成一件必须安全落地的事情在盯。开发可以明确地说，这不是我负责的模块，这块逻辑我没有改动。这在开发体系里是成立的，因为开发的职责边界，本身就是围绕模块划分的。当问题跨模块、跨服务、跨团队时，如果测试也选择只站在自己的那一小块范围内，问题往往就会在边界处被不断传递、不断稀释，直到某一天以事故的形式爆出来。所以很多时候，测试的负责，并不是亲自解决问题，而是确保问题不会悄无声息地消失。也正因为如此，在事故复盘或面试追问中，经常会出现类似的问题：当系统开始变复杂、责任开始变模糊时，你会不会依然选择对结果保持关注。这也是测试开发工程师“负责程度”最核心、也最难被量化的一部分。
六、自我驱动：没人逼你，但你知道该补哪里
不得不说，开发这个岗位要求定期交付一定的成果，但测试要“混”起来还是比较容易的，这就决定了，自我驱动能力，几乎决定了一个测试开发的成长上限：- 是否会在流程卡顿时，想着是不是能通过工具或机制减少重复劳动。
- 是否会在多次踩坑后，总结出一套可以复用的方法，而不是只停留在经验层面。
这些行为，很少会被直接写进绩效目标，但它们会慢慢改变你在团队中的位置：- 从被动接需求的人，变成大家默认会提前拉你参与讨论的人。
- 从版本末尾被通知的人，变成关键节点必须被同步的人。
这种变化，往往不是某一次技术突破带来的，而是长期自我驱动积累的结果。
七、和测试工程师相比，测试开发工程师的软素质差异在哪里
这两者在技术栈上的差异，大家已经讨论得很多了。但事实上，发展到今天，我认为二者已经没有什么本质区别。硬要说的话，我认为有以下几点，且并不是谁高谁低，而是关注点不同、承担的隐性责任不同。测试工程师，更多是在既定需求和实现方案下，尽可能发现问题。关注的是功能是否符合预期，边界条件有没有覆盖，现有用例是否还能兜住改动。在需求还不够清晰、方案还没完全落地时，就开始判断系统性风险，评估设计是否可测试、可回滚、可监控。这就决定了，测试开发的软素质中，前置判断能力占比会更高。在测试阶段内，把分配到的需求测清楚、问题提清楚，本身就是一件合格甚至优秀的事情。而测试开发工程师，往往会被默认承担一些没人明确指派、但又必须有人持续关注的事情。比如测试体系是否可持续，环境是否稳定，数据和依赖是否可靠，线上质量指标是否长期健康。而测试开发工程师的沟通，更多是在做取舍和对齐，是在参与决策，而不仅仅是反馈问题。最后，在成长路径上，两者对软素质的依赖程度也不同。而测试开发工程师，如果只停留在会写代码的测试，软素质迟早会成为瓶颈。因为越往后走，技术能力会逐渐同质化，真正拉开差距的，是在复杂系统中持续做判断的能力。
八、为什么开发更懂代码，但招聘往往并不偏爱开发转测试
从表面看，开发转测试似乎是一个非常合理的路径：开发懂代码、懂架构、懂实现细节，按理说做测试开发应该更有优势。但现实中，很多团队在招聘测试开发时，反而会对纯开发背景转测试保持谨慎。在需求明确、方案既定的前提下，功能跑通、本次需求交付完成，往往就是阶段性成功。而测试开发的核心目标，是尽可能提前发现事情可能会出问题的地方。需要在方案还没完全敲定、代码还没完全落地时，就开始反向思考风险和失败路径。很多开发转测试的人，在早期都会不自觉地带着实现视角。更容易站在够用即可的位置，而不是持续追问极端情况下系统会怎样。当你亲手设计和实现过大量功能后，很难在心理上迅速切换到一个完全反向的角色。在评审或讨论中，容易出现替方案解释合理性、低估异常概率、用后续优化换当前推进的倾向。而测试开发，往往需要站在一个不太讨喜的位置，把这些问题一遍遍拉回台面。如果一个人内心仍然把测试当成次优选择，这种心态迟早会在工作中显现。这也是为什么面试中，面试官会反复追问转岗动机。包括应届生面试中，如果同时投递了开发和测试开发，也会反复追问职业规划。最后需要说明的是，这并不意味着开发不能成为优秀的测试开发工程师。一旦完成角色认知和思维方式的切换，我认为确实有开发背景的人往往上手更快、上限也更高。我的身边就存在着既有深厚技术功底又有极好风险意识的开发，也正是这样的人给我带来职业危机感，促使我不断学习进步。
