我亲手砍掉QA手动测试岗，两个月后团队没少一人

今年8月，我告诉开发团队：功能做完不能再甩给QA部门等着验收，谁写的功能谁负责在发布前测好，线上出的问题也由作者修。我是pdf.net的质量工程负责人，这家公司做订阅制PDF编辑器。提出这个改动，等于把自己逼到一个尴尬问题上——如果我们不再检查别人的功能，我们存在的意义是什么？

我是从手动测试入行的，替它说了很多年好话。但后来我不信了：在流水线末端加一道人工检查，并不会让产品更好，它带来的成本比它拦下的问题更多。以前我们整天在工单里打勾，现在我们去翻生产数据、自己动手修一些bug、维护一套全工程团队共同贡献的测试套件。支付相关的改动仍然人工验，悬停和动画也仍然人工看。消失的是那条排队等QA的工单队列。

顺带说一句，公司并没有要求我们降本或裁人。改动落地几个月后，QA团队一个人没少，发布依旧每个工作日都在出。

“QA会看一眼的”，我也曾这么想

我以pdf.net第一位QA的身份加入时，没有测试环境，也没有自动化测试套件。我一边搭这些，一边手工验功能。工单流转到“待测试”，我接过来，要么打回去，要么放行。

这看起来是防止bug流入生产的合理办法。时间久了，我看出三个问题。

第一是逃生通道。身后有QA，人总有退路。不确定功能好不好用？QA会看。没在手机上验？QA会看。没想到可能弄坏隔壁团队的模块？QA会发现。而且QA做得越好，开发想得越少。

第二是规模。开发开始用AI写代码，功能涌来的速度超过我们检查的速度。发布卡在测试环节，工单在开发和QA之间来回踢。我们招了两名全栈QA，手动和自动化都能干，压力缓了一些，但等式没变：每个功能仍然要占用某个人的时间。人工检查靠招人扩容，代码靠token扩容得快得多。HR还在约第一轮面试，AI已经又开了几十个PR。

第三个问题对我触动最大。一次讨论流程时，有人说这里的手动测试实际上是“隐形的”。这话扎心，因为我知道验一张工单要花多少功夫，也知道我向业务方解释它的价值解释过多少回。

我们确实记录了验过的每一项，但记录躺在一张关闭的工单里：没人回看，一个月后别人的PR弄坏了这个功能，它也不会再检查一遍。下一个版本还得重做同样的活，不管第一次做得多好。

可就在那个夏天，我还在说：没有手动测试，我们“几乎不可能”扛住所有新功能。

这次没有“QA会看一眼”了

取消人工检查这件事，谁提都行。管理层提，听起来像砍预算；开发提，像是要把QA挪开。我们自己提的，那就得自己把它做成，并给团队找到一个更有用的位置。

和所有工程师商定的规则很简单：如果开发不确定功能能不能用，这个任务就不算完成。

8月的公告把它正式化，QA部门改名为质量工程（QE）。公告附了FAQ，还有一个帖子，有人预言会爆发一场圣战。小规模地爆发了一下 :)

我们是订阅制产品，所以保留了一条明确的例外：QE团队仍然用真实银行卡人工检查重大支付改动。其余部分，功能作者负责发布前测试，线上bug由团队共同负责。条件允许时，我们先写一个在当前代码上会失败的测试来复现缺陷，再修到同一个测试能防止它复发。

我原以为开发会抵触写测试。结果一旦他们要为线上功能负责，测试就成了保险。没人想当那个把bug送到用户面前的作者，而跑一遍测试给了他们发布前自查的手段。

开发每个PR都有预览环境，可以跑端到端测试，也可以让浏览器代理走一遍用户场景。他们还有BrowserStack做真机检查。但工作成果仍要自己看，我们不信任代理能把每件事都做对。

作者为功能写测试，QE负责评审。我们写了指南，讲产品背景、什么该进测试套件、测试该怎么组织。现在大部分测试由AI生成，这些说明就更重要了——结构漂亮的测试，也可能在验一个错误的东西。

我们的评审精力就花在这里。人工检查只能告诉我们功能今天能不能用；一个被评审过的测试，能在每次合并时再检查一遍。工单会关闭，规格会过时，而那些测试留了下来，成为产品应该怎样运行的一份可用记录。

现在测试数量多得多，开发和QE一起贡献。质量正在变成整个团队构建产品的方式的一部分。

那我们到底在这里干什么

如果只是改个头衔，叫质量工程师没什么意义。团队每个人认领了一块需要工程投入的领域，职责早已超出测试队列。

我们维护基础设施和测试架构，评审工程师提交的测试，改进人和代理写测试所依据的规则。一次失败的运行应该指向真问题，而不是让人去追一个不稳定的测试。我们还负责跨团队场景——每个开发盯着自己的功能时，这类路径最容易被漏掉。这些不那么显眼的路径，我们仍然自己写端到端测试，只是频率比过去低。

QE在发布决策里仍有位置。发布流程大部分自动化，但值班的质量工程师要在合并前核对必需的结果和机器人信号。

更多注意力转向生产：错误、日志、可用性和产品分析，以及每一项的“正常”长什么样。修得动的，我们直接修，而不是开一张工单丢给别的团队。需要更清楚地了解用户体验时，分析事件我们也能自己加。

代理帮我们把这摊活管起来。它们检查信号、排查疑似缺陷并尝试复现；另一个代理在结论变成工单之前提出质疑。晚上，还有一个代理复盘当天代理们自己错在哪，并改掉一条规则。另有一个机器人对预发环境里失败的运行做初筛。

由人决定什么值得处理、该谁去处理。代理不派活、不在公共频道发言、不自行关闭issue。

这也让我们和业务方有了另一种对话。QE和产品团队一起在演示会上讲：一个问题影响了多少用户、对他们意味着什么、折算成钱是多少。有了产品分析权限，错误、用户和钱能放进同一张图里。

对一个工作成果曾经消失在关闭工单里的团队来说，这总算有实打实的东西可以拿给业务方看。

然后生产环境说了几句话

没有漂亮的前后对比图。转型才几个月，还拿不出完整对比。我们仍然每个工作日发新功能，发布质量没有下降。

第一个月，我们给各团队带去了几十个旧流程漏掉的真实bug。这些是我们腾出时间更仔细地看生产之后发现的，而不是靠发布前那套已知的检查场景。

有用户打开文档时编辑器崩溃，修复后新版本上没再出现同类情况。另一起崩溃影响较老的Safari版本和较老的iPhone，这次QE自己排查并修好，没有把工单交给产品团队。

一天晚上有几个小时，部分用户在结账时看不到Apple Pay、Google Pay或PayPal。支付按钮消失了，但系统没有报任何错误。

用我们自己的文件和设备做例行检查，并没有暴露这些问题。暴露它们的是生产信号：错误和指标。

转型也暴露了我们所依赖系统的弱点。预发环境并不总和生产一致：功能开关和实验的配置不同，让测试失败更难解读。有一次实验没经过QE就上线，测试套件大部分失败。失败里藏着一个真bug，逼我们把那次改动回滚。我们需要预发和生产一致，才能相信测试告诉我们的话。

早期AI生成的测试是另一个警告。它们看起来整齐、全部通过，但有些几乎没验任何有用的东西。我们收紧了指南，把评审设为强制。也要说清楚：端到端测试不是越多越好，能在更低层级可靠检查的，就该放在低层级。

有些情况仍然只在生产出现，往往涉及少见的浏览器、特定的支付方式或不寻常的操作顺序。我们每天看这些信号，能补回归覆盖就补。监控是我们验证产品的一部分，它也不能免掉我们从失败里学习的义务。

我曾以为离不开它

最直接的反驳是：人能发现自动化测试漏掉的东西。我知道这是真的。那个夏天，我们就在一个只对小部分用户开启的实验中，靠人工抓到一个严重bug。悬停、动画和时序仍然需要眼睛，探索性测试也没有消失。

这些检查重要，但我认为，一个完全围绕“检查别人做完的功能”建立的角色正在消亡。如果你的价值是拿着清单手工走一遍，代理会做得更便宜，开发会做得更快，因为他们知道自己改了什么。

押注“AI永远不懂用户”是糟糕的策略。好策略是别再当最后一道防线，而是去设计这道防线。

对我们团队来说，这意味着理解产品和钱、在代码写出来之前看到风险、读数据、写下人和代理共同遵守的规则。这比接受或打回一张工单要求更高，也给了我们更大的空间去对发现的东西采取行动。

我们在它看起来还像实验的时候就承担了风险。我认为几乎所有人几年内都会这样工作，不过受监管行业（比如金融科技和医疗）会慢一些，需要自己的做法。

那个夏天早些时候，我还说过没有例行手动QA我们“几乎不可能”运转。把那个信念拿去检验，给了我职业生涯里最有用的“红跑”。

如果你的团队还有一列叫“待测试”，我想知道是什么让它留在那里。