1.QA 重组、35 岁的坎和"两个父亲"

---

2014 年的秋天，公司的项目处于攻坚阶段。为了在产品发布前尽可能多地暴露问题，我们测试团队没日没夜地加班加点，执行测试和报告问题。在这个吃劲儿的时刻，研发部门的领导突然做了一个针对 QA 团队的重大决定——将一百多人的团队进行拆分，百分之八十的测试工程师并入对应的研发团队内部。一时间，同事们都慌了神，很多人对明天的自己非常茫然。

就在此时，大洋彼岸的微软公司也传出了另一则新闻——裁掉上千名测试工程师，测试团队就地解散，测试开发的工作合并到软件工程师身上。

而国内的某知名测试论坛上，一个《我们还需要专职的测试吗？》的帖子登上热门榜首，跟帖无数，一片悲观的论调，唱衰测试工程师的前途和被替代的命运。

到了那年的圣诞节，上海飘起了雪花，冷风吹过，很是刺骨。某天午饭前，我主动找了同组的 Jason 一起去吃饭，因为我发现他最近似乎情绪有点低落。在食堂打好饭后，我俩面对面坐下，我起了个头。

我："最近感觉你工作热情不高啊？我在座位上就听到你叹气了，怎么了？"

Jason："哎，一言难尽。"

我："工作不顺利吗？还是？"

Jason："QA 团队重组了，我被分到研发那边了。虽然和新领导聊过一次，但是感觉后面怎么做很是迷茫。"

我："确实，这次重组，对很多人冲击很大，我理解你现在的心情。"

Jason："我在 QA 团队很多年了，现在并入研发，不知道饭碗还能保得住不？你看我们组的 Ahold，甚是得意。他早都一心想转去做开发，之前和研发的领导已经沟通过多次了。这次他如愿了，而我该怎么办？"

我："我知道你之前一直在测试团队，做得也很出色，这次并入研发团队，确实是不小的变化。但是工作保不住，不至于吧。"

Jason："哎。工作放一边，最近孩子要上幼儿园了，上海没有户口，被分到离家很远的一个破幼儿园。这还没完，我妈来上海帮着带孩子，最近身体也不好，我经常要请假带着老的往医院跑。最近项目压力大，请假也得看老板心情，我都不好意思了。刚过 30，要奔 35 了。都说 35 岁坎，你说我能跨得过去吗？你觉得测试工程师能做多久啊？你看到最近微软裁员的新闻了吗？还有…"

Jason 的话匣子打开，就刹不住车了。饭后，我们在公司的园区周围散步，又聊了很多。看得出来，Jason 最近确实不好过，各方压力之下，对职业发展产生了困惑。作为同龄人的我，除了同情他的遭遇外，任何的安慰和话术似乎都起不到作用。因为那时的我，也是眼前模糊，一时看不清未来的方向。

结束了漫长的一天的工作，我回到家里，看到活泼可爱的女儿，与她嘻哈打闹一番。我开玩笑地问孩子："如果爸爸没工作了，天天在家陪你玩，你高兴吗？"女儿突然很高兴地说："那太好了。我就要爸爸天天陪我玩。爸爸也会开心的，对吧？""我没工作了，没有收入了，不能给你买玩具去游乐场了，爸爸可能也高兴不起来了，怎么办？""那就把你变成两个，一个去公司上班，一个在家陪我玩。""等一下。你是说两个爸爸会比一个爸爸更好，对吧？"

女儿不经意的这一句，把我思绪又拉回到白天和 Jason 探讨的测试前途的话题上，并让我再次沉浸在最近 QA 团队的重组和测试行业发生的种种事情上。放下与孩子的嬉笑，我需要想一想：一个人可以既做程序开发又做测试吗？将来再也不需要专职测试的工程师了吗？

2.软件生产中的错误产生

---

开发一款软件产品或者构建一个软件系统，虽然可以借助高效的工具和严谨的流程为我们保驾护航，但是核心的程序和算法还是人的脑力活动产出的结果。既然软件工程仍然以人为中心，管理者要考虑三个方面的问题：

• 软件生产过程中，人是否会犯错误？为什么会犯错误？会犯什么错误？错误是否可以避免？
• 如果错误无法避免，那么不解决这些错误，会造成什么不良后果和损失？
• 如果要避免不良后果和损失的产生，以何种方式可以既高效又廉价？

虽然是三个问题，但是我们看到第一个问题是根本。对它的深入探究，会让管理者更加清晰地找到问题二和三的答案。

3.缺陷产生的心理学基础

---

针对人会"犯错误"这样一个话题，随着心理学对人类行为和背后原因的探究，发现了很多非常有趣的、与个体行为相关的规律和结论。这其中，比较有名的是 2-4-6 心理学实验。

心理学家 Peter Wason 在 1960 年设计的著名 2-4-6 实验揭示了人类普遍存在的"确认偏差"。实验中，参与者需通过测试数字组合来猜测"2-4-6"背后隐藏的简单规则（实为"任何升序排列的数字"）。然而，大多数人会基于"2-4-6"形成特定假设（如"每次加 2"），并倾向于提出符合自己假设的例子（如"8-10-12"）来验证，而非尝试推翻假设的反例（如"1-3-5"）。这个实验有力地证明，人们倾向于寻找证实自己想法的证据，而忽略可能证伪的信息，这使得我们很难发现自己思维或工作中的错误。

2-4-6 是一个关于"确认偏差"的经典实验。它在一定程度上反映了人在证明"自己是正确"这件事上的"努力"，这就是一种典型的认知偏差。

人在完成任务时难以发现和纠正自己犯的错误，这在心理学上有几个相关的解释，主要涉及认知偏差、注意力分配和大脑的自动化处理。以下是其中一些根本原因的分析：

• 盲点偏差（Bias Blind Spot）：人们往往对自己的表现有过度的自信，这在心理学上称为盲点偏差。这种偏差使得我们难以客观评估自己的错误，因为我们倾向于认为自己比他人更理性、更少犯错。例如，软件开发者会无意识地高估自身代码的可靠性，而低估他人反馈的价值，这会导致在代码评审时有选择性地忽视同事的评审意见。

• 自动化处理（Automatic Processing）：当我们习惯性地进行某些任务时，大脑会将这些任务变得自动化，以节省认知资源。这种自动化处理可以提高效率，但同时也使得我们更难注意到小错误，因为大脑更关注完成任务的全局，而忽略细节。例如，开发者习惯性复制粘贴旧代码片段到新模块中（依赖惯性操作节省认知资源），未检查依赖版本或接口变化，导致新功能因旧代码与新环境的兼容性问题而失败。

• 认知负荷（Cognitive Load）：人在任务中如果认知负荷过高，注意力可能会分散或资源不足。这会导致人们无法全神贯注于细节，并因此忽视潜在的错误。例如，开发者在修复一个紧急缺陷时，因同时需要处理多个高优先级任务（如架构设计、会议沟通），匆忙提交代码时遗漏了某个关联配置文件的更新（注意力资源被过度占用），引发连锁故障。

• 选择性注意（Selective Attention）：人的注意力有限，往往会集中在最显眼或最重要的任务方面，而忽略那些看似不重要的细节。这种"选择性注意"可能会导致对错误的忽略，尤其是当这些错误不是任务的核心内容时。例如，开发者在设计一个用户界面时，由于主要关注业务流程的重要性，而选择性地忽视界面在某些场景下的布局错误，造成可用性受到严重影响。

• 任务熟练度与自我检测的关系：在任务熟练度较低的情况下，个体可能没有足够的知识去判断自己的错误。而在高熟练度下，虽然能够理解任务，但由于过度依赖经验和直觉，也容易忽略潜在的偏差或错误。这种情况类似于"专家的陷阱"，即专家过于依赖惯性思维，难以发现潜在的新问题。

单一软件开发人员的行为受到上述一种或者多种心理机制的影响，会产生各种各样的错误。而复杂的软件系统是多人协同开发的，他们协同工作时所犯的错误通常不仅仅是单人错误的累加，它往往还会放大，甚至产生新的错误。这种现象在心理学和组织行为学中有着多方面的解释，涉及群体动力学、沟通障碍、决策偏差等。以下是对这种现象的分析及其背后的心理学基础：

• 群体极化效应（Group Polarization）：群体讨论或协作时，决策可能会趋向于更加极端的方向。这种情况下，个体的观点可能受到群体其他成员的影响而变得更激进或更偏向某一方向，增加了错误的风险。例如，某团队在技术选型讨论会上，过分地追捧生成式 AI 的技术落地，形成成员相互强化对"前沿技术"的推崇，而忽视对于新技术的经验缺乏的事实，最终导致初期开发周期缺陷非常多，也无法快速收敛。

• 从众心理（Conformity）与集体盲点（Group Think）：群体决策时，个体往往会受到从众心理的影响，即使他们怀疑某个决策是错误的，也可能会顺从群体的意见，避免反对。例如，在代码审查中，初级开发者可能因权威压力（如资深工程师主导意见）或群体共识（如多数人认可某设计）而隐藏疑虑，导致潜在缺陷未被发现。

• 社会惰化（Social Loafing）：当多人协作时，某些人可能会减少自己的努力，因为他们认为其他人会承担更多的工作量，这就是所谓的"社会惰化"。这种现象可能导致错误被掩盖或拖延。例如，某团队开发支付系统时，因任务分配不清晰，一些开发者认为边界条件会被其他开发人员处理，导致生产环境出现未处理的异常并且增加问题定位的成本。

从上面的心理学研究和实验的结果来看，软件的设计过程中，由于错误引入的缺陷，不仅仅是一个客观的无法避免的事实，而且参与"制造"这些缺陷的人（们）时常是不自知的。软件缺陷的产生，本质上是软件开发者认知架构局限性与复杂软件系统不确定性的产物。

4.通过测试建立"反认知偏差"防御机制

---

既然软件生产中错误在所难免，那我们就会设想弥补的措施，而软件测试就是一个非常重要的方法。

从心理学角度，软件测试的价值在于构建"反认知偏差"的防御机制，它是保证软件发布质量的一个重要的手段。软件测试的存在不仅是技术验证，更是组织层面的认知免疫系统——通过建立独立的观察视角、设计反偏差的协作机制、应用对抗认知局限的工具，将心理学理论转化为可落地的真实存在的质量保障体系。这一过程印证了"反脆弱"思想：承认错误的必然性，通过构建能从波动中获益的测试体系，将认知偏差的负面影响转化为系统改进的驱动力。

通过不同的测试方法、流程、组织，这种防御体系可以得到有效的构建。下面是一些具体的案例：

1）为了打破"自我验证"逻辑，测试团队被赋予外部观察者的角色，可以有效地降低"盲点偏差"带来的风险。测试设计者和执行者通过模拟用户视角，来遍历和触发软件开发者未能触及的异常路径（如边界条件、兼容性场景等）。

2）测试团队采用自动化测试工具，可以有效地打破研发团队的"流程惯性"和"模式依赖"。例如，SonarQube 的代码重复检测功能可以被部署，检出代码复制粘贴导致的潜在的缺陷。

3）测试设计者可以采用分层设计的思想，将验证任务拆解为核心路径（高认知负荷场景）与附属场景（低负荷场景），并通过自动化覆盖后者，释放人工测试资源聚焦复杂逻辑，来达到认知负荷理论的优化原则。

4）测试团队采用探索式测试的"非自动化思维"，在无预设脚本的自由探索中执行软件，测试人员的"适应性注意"能捕捉到开发者因目标导向忽略的异常交互（如用户误操作引发的界面卡死）。

5）利用群体动力学对流程优化，引入交叉测试的机制，可以有效破解"从众陷阱"。例如，可以安排后端开发人员测试前端的逻辑，让不同知识背景的人带着另一种视角，来降低群体思维的同质性风险。

6）测试团队可以主导缺陷复盘，来应对"责任弥散"。在明确错误归因时，测试团队可以采用个体/系统双维度的方式进行，既实时地指向某个研发成员的责任（降低社会化惰性），又通过流程改进填补协作合作时的漏洞（如制定标准化接口变更广播通知流程）。

即便上述独立测试和多种策略可以有效地降低缺陷发生的情况，为什么还会有很多裁撤测试团队，将测试职责移给研发的呼声呢？我会相信，多数的软件团队的决策者是经验丰富和富有智慧的，他们在研究"是否需要独立测试人员和团队"这件事情上是谨慎的。在企业和组织内部，做出了降低测试开发人员配比，甚至取消测试岗位，是一种资源再配置的管理措施。这是基于特定的上下文（如互联网产品上线后缺陷仍可快速热修复、软件以技术驱动而非产品主导、项目处于市场试错阶段等），而不具备普世意义。

一名微软前员工，曾在 2000 到 2014 年间担任高级软件开发测试工程师，参与了从 Windows XP 到 Windows 10 的开发。他在 2019 年时讨论 Windows 10 质量问题和变差的情况，指出 2014 年测试部门解散后，微软更多依赖开发者测试、遥测数据和 Windows Insider 反馈。这种质量的降低，是否是微软的决策者和 Windows 用户所能容忍的呢，毕竟我们无法做到 100% 的无缺陷产品。

5.测试，有没有终结者？

---

十年后的今天，我在微信上收到网友的询问："是否有基于生成式 AI 的自动化解决方案可以分享？我们部门有很多测试人员都在进行手工测试，雇佣他们成本太高了，想通过 AI 取代这些人的所有测试工作。"

十年后的今天，当我划开十年前老同事 Jason 的朋友圈，最新动态是一张他带着全家老小跨省旅游的合照。他配文道："再智能的 AI 也画不出眼前这片青山绿水，也复制不了全家相拥欢笑的温暖瞬间。此刻的美好，唯有真情才能带来。"

十年后的今天，我还继续在测试行业工作，而女儿也不再提"两个父亲"的分身设想，但是软件行业关于两种角色的讨论永远在继续。在不远的未来，如果软件还是由人创造，如果 2-4-6 实验结论依然有效，那么测试还会因何终止？

张昊翔

2025/4/17

Wechat: hzhan11

QQ: 22321262

Email: xjtu_xiangxiang@hotmail.com

Blog: https://www.infoq.cn/profile/2215BDBD532CB4/

LinkedIn: https://www.linkedin.com/in/hzhan11/