岗位变化现象
这几年，不少科技公司、SaaS 公司和金融科技公司开始取消或缩减传统的 Functional QA / Manual QA / Feature QA 岗位。有的公司直接不再招聘功能测试，有的把测试团队合并进研发，有的在裁员周期里优先压缩手工测试。还有一种更隐蔽的变化：岗位名称看起来还在，但招聘要求已经从会写用例、能执行回归悄悄变成了懂自动化、能搭平台。
这类变化很容易让人焦虑：是不是 QA 岗位不行了？是不是 AI 和自动化已经把测试替代掉了？是不是以后就不需要专职测试了？
这一篇先不急着讨论个人怎么转型，而是回答一个更底层的问题：公司取消功能 QA，质量责任到底去了哪里？这个问题想清楚了，后面关于要不要转、往哪转的判断才有地基。
我的判断很明确：功能 QA 被压缩，不代表质量不重要了，而是质量责任从一个后置验收岗位，迁移到了整个工程组织结构里。被取消的不是质量本身，而是一种低效率的质量责任分配方式。换句话说，公司不要的不是质量，而是开发写完、QA 兜底的那套旧模式。
很多 QA 的焦虑，其实是把岗位旧形态被淘汰错当成了质量这件事不再需要人做。这两件事不能混在一起看。前者是组织分工的变化，后者是工程质量的需求。只要业务还要交付、系统还要稳定、线上问题还会产生，质量就不可能消失，只是它不再天然归属于某一个后置岗位。
过去，质量经常被理解成 QA 团队的责任。开发写完功能，提交测试，QA 验收、回归、提 bug，最后上线前再做一轮人工确认。质量像是流水线最末端的一道工序，由一个专门的团队负责盖章放行。这种模式在低频发布、系统复杂度不高、团队规模较小时可以运转：一个月发一两次版本，QA 有充足时间把主要路径过一遍。
但在高频发布、灰度上线、微服务、持续交付和 AI 辅助开发越来越普遍的环境里，后置人工验收越来越容易成为瓶颈。当发布从一个月一次变成一天几十次，把质量集中压在末端那道人工闸门上，这道闸门本身就成了交付速度的天花板。组织开始压缩功能 QA，本质上是在调整这套质量责任分配方式。
被压缩的 QA 类型
需要先说清楚一点：被取消或压缩最多的，不是所有 QA，而是低价值、后置型、执行型的功能 QA。这类岗位的典型工作，是根据需求写测试用例，在开发提测后执行功能验收，手工跑回归，点页面、提 bug，再在上线前做最后一轮人工确认。它们很少深度参与需求评审、技术设计、代码可测性、流水线质量门禁和生产质量分析。
它的问题不是测试不重要，而是参与质量建设的位置太靠后。如果一个 QA 的主要价值只体现在提测之后，那么当自动化、AI、外包和开发自测能力都在提升时，这类岗位就很容易被压缩：一部分工作可以被工具替代，一部分可以被开发自己消化，剩下的部分再单独养一个岗位，就会显得投入产出不划算。关键不是测试这件事没价值，而是只在末端执行测试这个分工方式的边际价值在持续下降。
要理解为什么靠后是个根本问题，可以看看传统模式下质量责任是怎么被一路后置的。在这套模式里，QA 是发布前最后一道人工闸门，整条链路大致是这样：
产品写需求
↓
开发实现
↓
提测
↓
功能 QA 验收
↓
回归测试
↓
上线
这个流程看起来清晰，但核心问题是质量责任被后置了。顺着一个具体缺陷就能看清它是怎么走到 QA 面前的：需求里没写清楚退款金额是否包含手续费，产品默认包含，开发理解成不包含，于是按自己的理解写了代码；开发自测时只跑了正常退款，没有覆盖含手续费的场景；自动化也没有这条用例；一直到 QA 阶段，测试同学按需求点页面，才发现退款金额对不上。
这个 bug 在需求阶段就已经埋下，却在最末端才暴露。它不是某个人粗心造成的偶发事故，而是流程结构的必然产物：需求歧义没有在评审阶段被拦下，就一定会沿着链路往下漂，直到撞上第一个真正核对业务规则的人，而那个人恰好是 QA。
这样的例子不是孤例，换个场景一样成立。再比如营销活动规定每人限领一张优惠券，没人设计阶段追问如果用户同时点两次会怎样，开发用先查再写的朴素逻辑实现，单线程下完全正确，开发自测和串行执行的自动化用例都跑绿，直到上线后被并发请求打穿，才暴露出重复领券问题。缺陷的根同样在设计阶段那句没追问，却要等到生产环境才被发现。
需求不清楚、设计有问题、代码可测试性差、开发自测不足、自动化覆盖不足，最后都会堆到 QA 阶段。QA 看起来是在保障质量，实际经常是在替前面所有环节补洞。这个位置天然只能接住别人漏下来的问题，却没有足够的权限和时机去阻止问题产生。
越往后修复成本越高，这是软件工程里反复被验证的规律，背后的机制并不抽象。同样是修上面那个退款缺陷：在需求评审时发现，成本不过是改一句话、补一行验收标准；在编码阶段发现，是改几行代码加一条用例；拖到 QA 阶段，已经要走提 bug、改、重新提测、重新回归的一整圈；漏到线上，代价就成了客诉、资金差错、紧急修复、数据回滚，外加事后逐笔对账。
同一个缺陷在不同阶段被发现，修复成本可能相差一两个数量级，而且越往后，附带的业务风险和信任损失越难用工时来衡量。所以很多时候，传统功能 QA 不是不努力，而是站在一个天然吃亏的位置上：既要为上游问题兜底，又很难改变上游产生问题的方式。
越是高频发布的场景，这种后置兜底就越撑不住。上线节奏是每天甚至每小时一次，靠一个团队人工排队验收，队列必然堵死。团队只能在速度和质量之间反复拉扯：放行得慢，业务嫌挡路；放行得快，又难免漏测背锅。这种结构性两难，光靠加人或让 QA 更拼命是解不开的。
质量责任拆进工程体系
新的质量模式不是不要 QA，而是把质量责任拆进整个工程体系，让它不再压在一个团队身上：
产品工程团队自带质量责任
+ 测试平台
+ 质量治理
+ SRE
+ 安全 / 风险 / 合规
+ 外包 / 众测
过去质量依赖一个 QA 团队兜底，现在它被拆成了多类组织能力：开发自身的自测能力、自动化流水线能力、测试平台能力、生产监控能力、质量治理能力、安全合规能力，以及业务风险控制能力。QA 不再是一个孤立的放行部门，而成了整个工程系统的一部分。
质量责任的流向也因此变了。旧模式是层层往后传，最后压给 QA，新模式则要求每个环节各自承担，并把问题尽量在本环节解决。换句话说，质量不再只是发布前的验收动作，而是需求、设计、编码、测试、发布、监控每个环节都要承担的工程责任。这正是质量责任前移和内建质量的真实含义：把原本堆在末端的判断，还原到它最该被处理的那个环节去。
这些能力听起来抽象，落到日常其实很具体。所谓质量责任前移，是把验收标准在需求评审阶段就定义清楚，让退款是否含手续费、并发领券怎么算这类歧义在写代码之前就被消灭。所谓内建质量，是把测试平台沉淀成工具，让开发能高效自测；是用契约测试让破坏约定的接口变更在流水线里立刻报红；是在写代码时就考虑可测试性，让核心逻辑能被自动化稳定覆盖。
生产监控和 SRE，则负责兜住那条测不全的长尾。再充分的上线前测试也无法穷尽真实流量里的所有组合，于是组织需要通过告警、灰度、限流、熔断、快速回滚和故障复盘，把漏网问题的影响范围和暴露时间压到最小。
这本质上是一次质量债务转移方向的逆转：旧模式把债务一路欠到末端集中清偿，新模式则要求每个环节当场结清自己产生的那部分。需求阶段把验收标准说清楚，研发阶段把自测和自动化补上，平台阶段把门禁和工具做稳，生产阶段把监控和恢复能力建起来。谁制造风险，谁就要参与消化风险。
公司敢这么做，背后通常有几股力量叠加：CI/CD 让后置人工验收的效率显得太低，开发自测和自动化成熟度在提高，AI 可以压缩掉大量低价值测试劳动；与此同时，公司希望质量责任前移，而在降本周期里，纯执行型 QA 很容易被视为成本中心。这些力量都指向同一个方向，于是叠加成了今天这股潮流。
但这里要强调一点，也是最容易被误解的一点：AI 替代的首先是低价值执行，不是高价值的质量判断。AI 已经能写测试、能点页面，所以测试岗位要消失了这个说法只对了一半。会被压缩的确实是重复性验证、简单脚本、低风险回归和机械化测试劳动，但这些本来就是最该被自动化吃掉的部分。
真正有价值的质量判断、风险识别、策略设计和质量体系建设，反而会因为低价值执行被释放出来而变得更重要。一个能说清楚哪条链路高风险、为什么这个场景必须覆盖、这个缺陷会不会影响资金安全的人，比一个能多点几个页面的人对组织更稀缺。AI 越强，越能放大这种判断力的价值，因为它能把判断快速变成大量执行，但它本身并不知道该判断什么。
结论与后续问题
功能 QA 被取消，表面看是岗位变化，深层看是组织结构变化。质量责任没有消失，只是从 QA 岗位迁移到了工程组织结构里。功能 QA 的时代确实在结束，但质量工程的时代正在开始。看懂这一点，要警惕的就不是测试不再被需要，而是只会末端执行这一种形态正在被淘汰。
对个人来说，这篇文章先给出一个判断框架：不要只问公司还要不要 QA，而要看质量责任被拆到了哪里。它可能拆到研发自测里，拆到自动化流水线里，拆到测试平台里，拆到质量治理里，也可能拆到 SRE、安全、风险和合规体系里。岗位名称会变，但这些能力不会凭空消失。
这就引出了接下来三个更具体的问题，也是这个系列后面三篇要回答的：
- 工程如何承接：没有 QA 兜底后，研发团队具体要补上什么？
- 组织如何治理：质量风险怎么不失控，谁来接住原来 QA 兜的那部分？
- 个人如何转型：QA 和测开接下来该往哪里走？