点点点，竟是测试岗最后的护城河
测试行业一直看不起“点点点”。
招聘要求里要写自动化、平台、精准测试、AI，做汇报也要讲技术建设。至于打开页面，把功能从头到尾用一遍，听起来实在没什么含金量。尤其是“手工测试”这四个字，说出来仿佛职业生涯已经没救了。
但也许：
测试岗如果还有什么不容易被拿走的东西，可能恰恰就是点点点。
测试岗本来就是一种临时分工
这里说的不是软件测试这件事。软件当然一直需要测试。我说的是现在互联网公司里这种测试岗：参加需求评审，等开发提测，写用例、测功能、提 Bug、做回归，然后跟着版本上线。
这套分工和敏捷开发很配。
需求被切得越来越小，发布从半年一次变成一个月一次、两周一次，后来一天都能发很多次。开发速度上去了，总要有人接住后面的验证。产品不可能每个细节都验收，开发自己测自己的代码又很容易漏，于是测试被放在开发和上线中间，替团队踩一脚刹车。
当然，专职测试远早于敏捷开发，不是敏捷“发明”了测试。但我们今天熟悉的业务测试岗，确实吃到了互联网高频迭代的红利。
版本越多，要回归的东西越多；需求越快，开发越没空自己慢慢测。团队多招几个测试，是最直接的办法。
现在的问题是，这个办法好像没那么必要了。
原来属于测试的活，正在被拆走
代码提交时有单测、静态检查和 Code Review，接口有自动化，发布有灰度，线上有监控和快速回滚。产品也可以直接在预览环境里验收，不一定非要等测试传话。
以前这些能力也有，但不好用，覆盖也差，所以最后还是要靠人肉兜底。现在工具慢慢成熟了，AI 又进来掺了一脚。
读需求、分析改动、列测试点、写接口脚本、造数据、看失败日志，这些都是测试日常里很花时间的事情，也都属于 AI 比较擅长的事情。单拿一个出来，AI 未必比经验丰富的测试做得好。但它便宜、快、不嫌烦，已经足够吃掉不少工作量。
质量没有变得不重要，只是未必还需要集中在一个叫“测试”的岗位上。
部署工作也很重要，但现在不会专门招一批人，负责把开发电脑上的包复制到服务器。因为这件事已经进了流水线。测试也将走到这一步：工作还在，岗位变少。
有时候大家会说开发怎么可能自己测试。确实有很多开发不爱测，但这更像管理问题，而不是测试岗永远存在的理由。只要出了问题真由开发负责，有足够好的工具，又不需要手写一大堆烦人的测试代码，开发并不是不会测。
AI Coding 普及以后，“测试不会写代码，所以由测试来补自动化”这条分工也有点奇怪。开发最懂自己的代码，AI 又能代写大部分脚本，为什么还要先把上下文讲给另一个人，再由另一个人写一遍？
越容易说清楚的工作，越危险
一个输入框要测哪些边界值，一个接口有多少参数组合，主流程每次上线前要跑几遍。这些事情都很重要。不过越是能把规则讲清楚，就越容易交给工具。
以前测试工程师转型，最常见的路线是学自动化、做平台。这当然比纯手工回归有价值。但自动化发展到最后，消灭的其实就是“执行测试”这件事。
平台也不需要那么多人。公司可能需要几个很强的人建设质量基础设施，不需要每个业务测试都去造平台。最后很可能是少数人做工具，开发维护自己模块的自动化，产品负责验收，中间那层按需求流转、按用例执行的测试越来越薄。
那还剩什么？
想来想去，好像真剩下了点点点。
点点点也分两种
一种点点点，是测试用例写第一步点登录，第二步输账号，第三步点确认，最后看结果是不是符合预期。
这种没什么好留恋的。人做得慢，还会走神，应该尽快交给机器。
还有一种不太一样。
拿到一个新功能，先随便用用。点一下觉得反馈不太对，再返回重来；换个旧账号试试；操作到一半杀掉进程；看到一个数字，顺手想一下它和昨天的数据能不能对上。原本只准备看功能 A，走着走着觉得它可能会把功能 B 弄坏。
最后找到的问题，经常不在任何一条测试用例里。
这种点点点看起来也没什么技术含量，甚至很难汇报。你很难说自己用了什么算法，只能说：“我用的时候觉得这里不太对。”
但一个有经验的测试说“不太对”，和刚入职的人说“不太对”，不是一回事。
他可能记得半年前出过一个相似的问题，知道这块数据从哪个服务来，知道哪些用户的账号状态比较脏，也知道开发为了赶时间最可能省掉什么。鼠标点下去之前，脑子里其实已经闪过了好几条路径。
点只是动作，真正值钱的是这些没写下来的经验。
真实用户也不会照测试用例操作。他会连点两次，会在加载时返回，会复制一段带空格的文字，会看不懂一个我们觉得理所当然的按钮。他遇到问题也不会贴日志，只会觉得不好用，然后走了。
自动化最擅长检查我们已经知道的东西，人的价值则可能只剩下发现“原来这里也要检查”。
行业里有个更正式的词叫探索式测试。不过这个词一说，又很容易开始画模型、讲方法、做平台，最后把一件依赖经验和好奇心的事情重新变成标准流程。
我还是愿意叫它点点点。
不是所有测试都能靠点点点留下来
这篇文章当然不是在给手工回归翻案。
如果只是比开发更耐心，能把固定流程多走几遍，这个优势维持不了多久。真正有用的是熟悉业务、对产品有感觉、看到小异常愿意继续追，以及能把一句“感觉不对”最后查成一个说得明白的问题。
以前测试用例写得完整，版本没漏测，工作基本就交代过去了。以后可能没人关心测了多少条用例，只关心上线前有没有发现真正的风险。
自动化、代码、AI 还是要会，只是不再拿它们证明自己比别人高级。它们应该负责把确定的、重复的东西清走，让人有空到产品里乱逛，有空多问一句为什么。
我不确定测试岗最后会不会消失。有些团队肯定还会保留，有些团队可能已经不再招聘了。这本来就取决于业务复杂度、发布方式和团队能力，不会有一个统一答案。
但有一点大概比较确定：质量不会因为测试岗消失就消失，也不会因为保留了测试岗就自动存在。
以前团队需要测试，是因为有太多东西来不及验证。现在机器慢慢接过了这些验证，人还能做的，是去碰那些团队压根没想到要验证的地方。
所以“点点点”不一定是测试岗落后的证据。
机械地点，确实没什么前途。可如果能比别人更早从一次卡顿、一个奇怪的数字、一条绕口的文案里感觉到问题，这大概仍然是很难写进流水线的能力。
测试岗最后的护城河，也许就是那句不太专业的话：
等一下，这里好像不太对。