一个组织宣布从测试转向质量工程（QE）：测试人员换了头衔，开发开始承担更多测试，自动化投入增加，仪表盘也越来越多。几个月后，责任可能更模糊，自动化更难维护，原来的问题仍然存在。

Barry Ehigiator 在 Ministry of Testing「Leading with Quality 2026」活动的工作坊中讨论了这种落差。他的核心观点是：QE 转型很少是因为团队缺乏技能或投入而受挫，更多时候是组织低估了转型所需的系统性改变。可持续的 QE 不仅要调整岗位和实践，也要重新设计工作机制。下文前半部分依据工作坊回顾整理；AI 原生 QA 的应用和四周试点则会明确标为实践延伸。

识别：对照转型承诺与团队实际体验

QE 转型通常承诺质量共担、目标更明确的自动化、更快的反馈、更少的后期意外、更好的协作、更有把握的交付，以及更好的客户结果。这些目标都合理，但不会因为改了头衔或工具就自动实现。

工作坊先请参与者回顾自己的经历：组织是在探索、采用还是扩大 QE？当初希望实现什么？目前哪些做得不错，又出现了什么意外或挫折？讨论也暴露出一个实际问题：人们有时把质量工程、质量保证、质量控制和质量管理当成同一个概念使用。

转型承诺可能出现的现实应追问的问题
质量共担责任归属变得模糊谁决定风险是否可以接受？
更有价值的自动化脆弱脚本和维护积压增加自动化降低了什么重要风险？
更好协作会议变多，却缺少共同预期各角色如何定义“足够好”？
持续改进同类问题不断重现谁负责行动并验证效果？

症状能指出问题在哪里，诊断还要继续追问背后的系统原因。测试不稳定可能来自接口脆弱、可测试性不足、优先级冲突或没有维护时间，不一定是测试人员能力不够。

诊断：从个人表现转向系统原因

工作坊用了一家虚构公司 Proquains Ltd 作案例。公司把测试员改称质量工程师，要求开发更多参与测试，加大自动化投入、增加质量指标，也在产品团队中倡导共同负责；但工作流程、决策权、激励方式和改进资源并没有随之改变。

活动请参与者辨认：哪些做法看起来不错？有哪些警讯？什么系统条件造成这些警讯？公司可以怎么做？案例中的症状包括：质量工程师直到关键决策之后才介入；各职能对质量的定义不一致；发布风险没有明确决策人；自动化增加但交付信心没有提升；质量指标按时报出，问题却一再出现；改进工作持续被降优先级；责任扩大却没有相应的权力、时间和影响力。久而久之，团队也可能怀疑 QE 是否真的改善了工作方式。

诊断自己的转型时，可以追问三个问题：最重要的风险是什么？我们观察到了哪些症状？背后是什么系统原因？ 第三个问题能把讨论从责怪某个人或某个职能，转向改变工作环境。

QE 转型中的七个陷阱

一、改了岗位名称，没有重设计系统。 质量工程师这个头衔不会自动改变需求何时澄清、测试人员何时参与产品决策，也不会自动明确谁接受风险。

二、没有明确目的就增加自动化。 自动化能降低重要风险、缩短有效反馈时间或帮助团队决策时才有价值；否则它可能带来脆弱的流水线、维护负担和虚假的信心。

三、有协作，没有共同愿景。 产品、研发、设计、运维、质量和客户看重的结果可能不同。若不把目标和取舍说清，增加会议并不能解决分歧。

四、数据更多，学习更少。 缺陷数、覆盖率、执行次数和流水线统计只是信号，不是解释。把它们变成个人指标，还可能让人忙于优化数字，而不是解决问题。

五、要求共担，却没有赋权。 真正的责任共担需要信息、访问权限、尽早参与、明确决策权、处理风险的时间、影响取舍的能力和领导支持。缺少这些条件，“人人负责质量”可能变成“谁都无法行动”。

六、鼓励改进，却不给优先级。 团队可能知道测试脆弱、环境不稳定，却没有责任人、容量或优先级去修复。没有优先级的持续改进仍然只是愿望。

七、认同原则，却没有可执行的策略。 团队可能都赞成左移、质量共担和自动化，却没有统一的落实方式，最后每个小组各自解释，实践逐渐碎片化。

从质量职能转向质量系统

质量职能视角质量系统视角
由一个部门把守质量多个职能共同影响质量结果
主要看缺陷总数用证据与反馈推动学习
在交付末端集中检查在整个交付过程中建立信心
只有专家负责验证质量团队围绕共同愿景协作、管理风险

质量专业人员仍然不可或缺，但他们的贡献应从交付末端的验证，扩展到促进协作、辅导团队、风险分析、系统思考和质量领导。测试设计、探索式测试、策略制定和反馈解读仍需要专业能力；同时，质量工作必须贯穿交付过程，不能只留给末端的一道关卡。

Barry 还引用了同事 Jit Gosai 常鼓励团队思考的问题：质量如何在我们的系统中被创造、维护，又如何流失？ 这能把注意力从岗位名称转向影响结果的工作流程、决策、反馈和激励。讨论重点也要从“质量归谁管”转向“团队的协作方式如何持续产出质量”。

CREATE：设计 QE 成功所需的条件

CREATE 是工作坊提出的六部分变革框架。Barry 结合既有的质量与变革管理理念，以及自己在 QE 实践中的经验设计了这一框架；六部分彼此关联，并对应前面的陷阱。

C — 共同定义质量愿景

让产品、研发、运维、设计、质量和相关干系人一起明确客户在意的结果、不可接受的失败、发布决策需要哪些证据，以及出现取舍时如何决定。有效的愿景能改变实际决策，不只是多一页汇报材料。

R — 重新设计系统

检查工作流程、激励方式、决策权、团队协作、发布节奏与发布做法，以及反馈回路。如果团队只因交付功能数量受奖励，所有质量问题又都交给 QA，组织结构本身就不支持共同负责。

E — 让团队有能力行动

说清谁可以升级或阻止高风险发布、谁能质疑验收标准、谁可以提出可测试性改进、谁能为技术债争取时间。还要提供相应的访问权限、影响取舍的能力、受保护的改进时间、能力培养和可见的领导支持。赋权不是人人都能决定一切，而是让承担责任的人确实有条件行动。

A — 让实践对应风险和价值

新增工具、自动化、AI Skill 或流程前，先问：它解决什么问题、降低什么风险、支持什么决策、创造什么价值，以及团队如何判断它是否有效。QE 不应成为孤立的测试项目；产品、研发、设计、运维、支持和测试人员都需要理解实践为何引入，以及它如何服务共同结果。

T — 跟踪有意义的指标

让指标服务于学习。分析逃逸缺陷时，同时看严重程度、客户影响、变更规模和根因；分析自动化覆盖时，也要看风险覆盖、误报、反馈时间和维护成本。数据真正有价值，是因为它改变了团队的理解或下一步行动。指标应辅助判断，团队还要结合上下文解读。

E — 让持续改进真正发生

预留容量、指定负责人、公开进展、检查结果并分享经验。复盘之后，应当改变工作约定、工具、决策路径或系统约束，而不是只把行动项标记为关闭。还要验证改变是否改善了结果；没有效果就继续调整。

六项合在一起，也回答了第七个陷阱：只有愿景，没有可执行策略。

领导者负责创造条件

领导者影响团队优先优化什么：只看速度，还是也看韧性；团队能否在安全的氛围中公开风险和暴露弱点，还是提出坏消息会受罚；改进时间是否有保障，还是每个迭代都被交付任务填满。领导者也决定决策权如何分配。QE 不能长期依靠一线人员额外努力来弥补结构性问题。

可以问：有人指出重大风险时，组织是否有清楚的升级路径？跨团队问题反复出现时，是否有人能改变系统，而不只是再提醒一次“加强沟通”？

团队就绪度检查

工作坊回顾介绍的是一个简明练习：对六个就绪度问题回答是 / 部分符合 / 否，再据此找出最重要的约束。下面按 CREATE 整理的检查项是实践改编，并非原文检查表的逐字复现。不要把结果当成个人绩效分数。每项回答为“部分符合”或“否”时，都应补充症状、背后的系统限制、需要参与的人、行动负责人，以及两周内最小但有意义的一步。最后用这句话明确最主要的约束：“在进一步推进 QE 之前，我们组织最需要改变的是……”

C — 共同质量愿景

  • 不同职能是否共同定义质量与客户结果？
  • 发布风险的接受标准是否明确？

R — 系统设计

  • 工作流程是否支持尽早反馈？
  • 激励方式是否同时鼓励质量和交付，而不只看产出数量？

E — 赋权行动

  • 每项重要风险是否有明确的决策人？
  • 团队是否能访问所需环境、数据、信息和资源？

A — 风险与价值

  • 自动化是否对应具体的重要风险？
  • 新工具是否有价值假设和停止条件？

T — 有用的度量

  • 指标是否会推动具体决策？
  • 是否同时跟踪结果和维护成本？

E — 持续改进

  • 是否为改进工作预留了容量？
  • 每项改进是否有负责人和效果验证方式？

从最重要的约束开始，而不是追求高分。用下面这份简短记录，把两周行动说具体：

  • 观察到的症状：
  • 背后的系统原因：
  • 需要参与的干系人：
  • 最小有效行动及负责人：
  • 成功证据：
  • 复查日期：

将框架用于 AI 原生 QA

本节是独立实践延伸，不是 Barry 工作坊回顾中的原始主张。

AI 原生 QA 也会遇到相同的系统陷阱。团队可能引入 AI Skill 包、智能体和 MCP 集成，却没有共同质量标准、可重复的评估集、权限边界或人工审批点。最后所谓的“AI 提效”可能只是生成内容更多、错误更难追踪、维护成本更高。

先试点一个有价值的流程，例如需求评审或测试用例生成。明确输入和输出约定、禁止行为、人工复核点，并使用真实历史案例建立基准。衡量有依据的发现、无依据的结论、评审耗时和修复成本。有证据支持时再扩大范围。

不能只数 AI 生成了多少测试。还要检查这些测试能否执行、是否覆盖真实风险、会不会制造虚假的信心，以及是否缩短了从发现风险到作出决策的时间。

四周试验

下面也是实践延伸。目标是验证一项改变，不是宣布四周完成 QE 转型。

周次重点交付结果
第一周访谈干系人，梳理承诺与现实的落差症状记录和质量愿景草案
第二周用七个陷阱和 CREATE 诊断问题一到两个优先级最高的系统约束
第三周试行流程、权限或容量调整工作约定、决策路径和负责人
第四周检查证据并调整结果回顾、下一轮试验和停止条件

四周试点可以建立可衡量的学习与调整闭环。全组织范围的 QE 转型需要更长时间，也要看组织是否根据试点结果采取行动。

带回团队的三项行动

  1. 从系统原因着手诊断。 检查协作、决策、风险管理、改进优先级，以及现有系统鼓励了什么行为。
  2. 让 QE 实践对应客户和组织目标。 测试、自动化、可观测性等实践都应支持用户和组织真正重视的结果。
  3. 把 QE 当作有计划的变革来管理。 明确责任和决策权，保护改进容量，建立反馈回路，并把学习转成行动。只发布一份转型公告不会自动带来新行为。

结语

可持续的质量工程，需要通过共同目标、决策权、工作方式、反馈和持续改进有意识地设计出来。下一步应问：我们的系统需要改变什么，QE 才能成功？

参考资料

QA 指标安全测试白盒测试背靠背测试本地化测试
分享