这两天，关于“字节 QA 并进 RD”的讨论很热。
评论区里有两种很典型的声音。
一种是开发说：早该这样了，开发自己写单测、自己验收，少一层交接，效率更高。
另一种是测试说：QA 都并进研发了，是不是以后就没人要测试了？
这两个问题，其实都问偏了。
QA 和 RD 可以合到一个组织里，质量责任却不能合成一句“大家一起负责”。
因为软件项目里最危险的状态，从来不是“测试岗少了”，而是上线出了问题以后，所有人都能说一句：这个不是我该测的吗？
一次上线，最怕出现四个“我以为”
假设现在要发一个优惠券改版。
开发说：核心计算我写了单测，没问题。
前端说：页面我自己点过，没问题。
产品说：主流程我看了，没问题。
测试说：这个版本不是我负责的，我只帮忙看了一下。
结果上线后，老用户叠加券的场景算错了；客服补发的券没有走新规则；退款后优惠资格又被恢复了一次。
这时候你会发现，问题不是谁“不够努力”，而是没人把这几个问题串起来：
这次改动影响了哪些历史规则？
哪些入口、角色、状态组合必须跑？
单个接口对了，跨系统的数据还能不能对上？
风险已经知道了，谁有权决定“带风险上线”？
以前，很多团队把这些事默认丢给 QA。现在如果 QA 并进 RD，最先要补上的就不是岗位名称，而是这张质量责任表。
QA 并进 RD，不等于 RD 多接几个测试任务
很多人把融合理解成一句话：开发以后顺手把测试做了。
但开发自测，和质量保障，本来就不是一件事。
开发最擅长的是把功能构建出来：接口能通、页面能展示、代码逻辑能跑。他的测试天然会围绕“我刚写的东西”展开。
这没有问题，单测、接口测试、代码评审本来就应该是研发责任的一部分。
可用户不会按你的代码模块来使用产品。
用户会在弱网时连点三次；会拿半年前的账号叠加新活动；会从一个很少用的入口进入；会在支付成功但回调延迟时刷新页面；也会在十万行导出、权限切换、灰度回滚时，把系统推到平时没人走的位置。
这些问题，需要的不是“再点一遍页面”，而是一种专门盯着系统边界、历史包袱和异常路径的风险判断。
所以，融合以后更合理的分工不是“开发把 QA 吞掉”，而是：
角色
需要对什么负责
研发
代码可测试、单元测试、接口契约、基础安全与可观测性
测试开发/质量工程
风险分析、端到端验证、回归策略、测试环境与数据、质量门禁
产品/业务
验收标准、业务规则、异常场景的取舍
项目负责人
在已知风险下，是否发布以及准备什么兜底方案
岗位可以融合，这四类责任不能消失。
单测都过了，为什么还不能直接发？
因为“代码正确”和“业务可用”之间，至少还隔着三道墙。
第一堵墙：模块正确，不等于链路正确
订单服务、优惠券服务、库存服务各自的测试都过了，不代表用户下单一定正确。
真实事故经常发生在接口之间：字段含义没对齐、状态同步晚了一步、重试造成重复扣减、旧版本兼容规则没带上。
第二堵墙：正常输入正确，不等于异常时可控
开发写“用户点击提交”时，脑子里通常是一次点击、网络正常、数据干净。
而质量验证要故意问反面：重复提交怎么办？请求超时后用户重试怎么办？第三方回调晚到十分钟怎么办？权限刚被回收，缓存还没失效怎么办？
第三堵墙：功能正确，不等于发布可控
一个功能即使没有明显 Bug，也可能因为监控缺失、开关不可回退、灰度范围太大、数据库变更无法兼容而不该直接上线。
这就是为什么成熟团队会有质量门禁。
它不是“测试卡研发脖子”，而是把大家各自知道的一点风险，整理成一次能做决策的发布证据。
真正会被压缩的，是“只接单、不判断”的位置
说句实在的，测试行业确实会变。
只拿到需求、列一批固定场景、机械执行、把结果填进系统的工作，会越来越多被自动化和 AI 接手。这不只发生在测试，研发、前端、运营里同样在发生。
但另一类能力反而会更稀缺：
能从需求里提前看出系统性风险；
能把业务规则拆成可执行、可回归的测试设计；
能搭建接口自动化、数据准备、环境治理和持续回归；
能看懂监控、日志、链路，帮助团队从“发现问题”走到“定位问题”；
能在时间、资源都不够时，判断哪几道质量关绝对不能省。
这类人未必还叫“传统 QA”，也可能叫测试开发、质量工程师、质量负责人，甚至直接在研发团队里承担质量角色。
名字会变，价值不会变。
对测试工程师来说，现在最该补什么？
不是急着把简历上的 QA 改成 RD。
先把自己的工作，从“等别人给任务”往前推一步。
需求刚出来时，你能不能用业务规则、状态流转和边界条件把风险问出来？
开发开始实现时，你能不能理解接口、数据库、日志和部署链路，知道自动化该插在哪？
版本准备发布时，你能不能拿出一套有优先级的回归策略，而不是一句“全量测一遍”？
线上有问题时，你能不能把一次事故沉淀成下一次可复用的测试资产？
这就是测试开发真正的价值：不是替开发多点几下，而是让团队每次交付都比上一次更可验证、更可追溯、更不依赖运气。
字节 QA 并进 RD 的讨论，最后不该只落成一句“测试没了”或者“开发赢了”。
它真正提醒我们的，是以前靠部门墙兜住的质量责任，正在往每一个工程角色身上重新分配。
组织可以合并，工牌可以改名。
但总要有人在所有人都说“应该没问题”的时候，继续问一句：
证据呢？如果它在最差的情况下坏掉，我们准备怎么接？
