敏捷测试：在Scrum团队中测试人员如何工作

在 Scrum 团队里，测试人员最常遇到的困惑往往不是「怎么测」，而是「我在这个团队里到底算什么角色」。在传统瀑布流程中，测试是一个独立阶段，测试人员守在上线前的最后一道关；进入 Scrum 之后，这套分工被打散，测试活动需要跟着两周或三周的迭代节奏走。敏捷测试解决的正是这个问题：它把测试从独立阶段变成贯穿整个迭代的持续活动，测试人员也从独立把关者变成开发团队的一员。

这篇文章围绕一个问题展开：在 Scrum 团队里，测试人员究竟怎么工作。下面先说清敏捷测试的定义与边界，再看角色定位，接着拆解一个 Sprint 内的具体动作，最后给出判断做得对不对的标准与常见误区。

敏捷测试是什么：从独立阶段到贯穿迭代的实践

敏捷测试是遵循敏捷开发原则、把测试融入整个开发流程的一套测试实践。它既不是一种具体的测试方法，比如黑盒或白盒，也不是某一款工具，而是一组价值观、流程、实践与配套环境的组合。业内较为一致的看法是，敏捷测试使用的基本测试技术，比如等价类划分、边界值、探索式测试，与传统测试并无二致，真正的差别在价值观、思维方式、流程和协作方式上。

判断一段测试是不是「敏捷」，可以看三个特征。

• 测试融入开发流程，而不是独立阶段。 测试活动从需求讨论就开始，一直延续到迭代结束。
• 持续测试、持续反馈。 每个迭代都要交付可用增量，测试节奏与开发同步，而不是等开发全部完成再集中测试。
• 跨职能团队共同承担质量。 测试人员、开发人员、产品负责人围绕同一个目标协作，质量责任不再单独压在测试人员身上。

与传统测试相比，差异集中体现在几处：测试计划由一次性制定变为持续细化，从厚重的计划书变为刚好够用的一页纸；测试用例更多围绕用户故事和验收标准直接验证；回归验证更多交给分层自动化；测试人员的协作对象，也从「开发完成后的交接方」变为「贯穿需求到验收的同行者」。

这套实践的思想源头可以追溯到 2001 年发布的《敏捷宣言》，其四条价值观强调个体协作、可工作的软件和响应变化。此后 Lisa Crispin 与 Janet Gregory 在 2009 年的《Agile Testing》中，把测试人员在敏捷团队中的定位系统化，这本书也被广泛视为敏捷测试领域的重要参考。

测试人员在 Scrum 团队中是什么位置

要理解测试人员的位置，先要回到 Scrum 的角色定义。《Scrum 指南》只定义了三个角色：产品负责人、Scrum Master 和开发团队。测试人员并不单列其中，而是开发团队的一员。

这一点常被误读。很多团队默认把自己分成「开发」和「测试」两拨人，任务从开发流转到测试，看起来分工清晰，实际却把瀑布的排队问题带进了迭代。Scrum 不区分程序员、测试人员、数据库工程师等岗位，目的就是形成端到端交付的集体所有权：团队共同为增量质量负责，而不是各管一段、交接了事。

落到日常协作，测试人员的接口大致有三条。

• 与产品负责人：一起把用户故事写清楚，明确验收标准，并在迭代评审中核对「完成」是否真的完成。
• 与 Scrum Master：把测试环节遇到的环境、依赖、流程障碍暴露出来，推动移除。
• 与开发人员：结对评审需求与设计、补充单元测试、关注持续集成结果，让问题在合入前暴露。

一句话概括角色转变：测试人员从「质检员」变成团队内的质量推动者。这个转变不改变专业价值，反而对沟通和工程能力提出了更高要求。

一个 Sprint 里，测试人员具体做什么

角色定位落不到具体动作上，就只是一句口号。按迭代的时间线拆开，测试人员的工作大致分为三段。

计划与需求阶段：把质量动作前置

迭代计划会、需求梳理会和评审会，是测试人员介入的起点，也是测试左移真正发生的地方。这一阶段的关键动作不是「提前准备用例」，而是从可测试的角度发问：这条用户故事要验证什么，验收标准是否可观察，边界和异常场景有没有定义，依赖是否明确。

如果验收标准写得含糊，后面所有的测试都只能靠猜。 测试人员在这类会议上的价值，往往体现在把模糊需求问清楚，让整个团队少走返工。

开发阶段：持续测试与快速反馈

编码进行的同时，测试工作同步展开。测试人员设计并维护用例与检查表，在接口和单元层面推动自动化，关注持续集成的执行结果，代码合入即验证。每天站会上同步风险和阻塞，让问题尽早暴露。

除了基于脚本的验证，探索式测试在这一阶段同样重要。它强调边设计、边执行、边学习，适合在功能刚成形、需求仍有不确定性的阶段发现意料之外的问题。

验收与回顾阶段：把关与改进

迭代末尾，测试人员基于验收标准做验收测试，确认增量是否达到可交付状态，并参与演示收集反馈。发现问题时，通过 Bug 记录复现步骤、影响范围与严重程度，跟踪到回归验证通过为止。

迭代回顾会则把质量数据摆上台面：这个迭代的问题在哪个阶段暴露、回归是否还有大量人工重复、哪类问题反复出现。改进项会进入下一个迭代。敏捷测试的改进是持续的，不是一次性的流程改造。

支撑敏捷测试的几组关键实践

上述工作方式依靠几组实践支撑。它们不是彼此独立的清单，而是相互咬合。

测试左移与持续测试是主线。左移指把质量保障动作从迭代末尾提前到需求和设计阶段，越早发现，修复代价越小；持续测试指测试贯穿整个开发周期，靠自动化支撑快速反馈。

分层自动化与测试金字塔决定自动化的投入结构。单元测试数量多、运行快，位于金字塔底层；接口测试居中；UI 测试少而精，只覆盖关键流程。底层越扎实，回归成本越低。

探索式测试补足脚本化测试覆盖不到的角落，在用户体验和业务场景验证上作用明显。

敏捷测试四象限提供了一个检查视角，按「面向技术还是面向业务」「用于支持团队还是评价产品」把测试活动分成四类，用来识别团队是否有明显盲区。四类测试缺一不可，只做其中一类，质量视图就是残缺的。

完成的定义（DoD）把质量门禁固化成团队共识。一段增量满足哪些条件才算「完成」，需要有明确的、团队一致认可的判断依据。

怎么判断测试人员在敏捷团队里做得对不对

判断标准不该是「跑了多少用例」，而应看质量是否真的被前移。

• 交付结果：每个迭代能否稳定交付可用增量，回归验证是否主要依靠自动化完成。
• 问题暴露的时机：多数问题在需求和开发阶段被发现，而不是等上线后由用户反馈。
• 协作密度：需求评审、设计讨论中能否看到测试视角，验收标准是否由团队共同确认。
• 工具承载：需求、任务、用例、Bug 与迭代看板能否在同一条链路上贯通，数据可回溯。

最后一条容易被低估。流程再清晰，如果需求、用例和 Bug 分散在不同系统里，质量数据就无法回溯，改进也无从谈起。 中国信通院云大所与思码逸联合发布的《DevData 2024 研发效能基准报告》在交叉分析中提到，采用敏捷开发模式的研发团队，研发效能中位值比其他模式（含混合模式）高出约 9%；同一调查也显示，受访企业的单元测试覆盖度中位值仅为 15.14%，说明质量前移仍有较大提升空间。敏捷带来的效能优势有据可查，但能否兑现，取决于基础工程实践是否扎实，而不是贴一个敏捷标签。这也正是研发效能度量需要持续观察的原因。

常见误区与落地建议

敏捷测试常见的偏差，大多不在技术上，而在协作与流程设计上。

伪敏捷是最常见的偏差。 判断方法很直接：看任务板上是否单独设了一列「测试」。如果有，测试很可能仍被当作一个阶段，迭代末段的堆积和返工依旧会发生。

只上自动化、不改协作，同样普遍。 自动化能降低回归成本，但如果测试人员仍在开发完成后才介入，问题暴露的时机并没有提前，本质没有改变。

把质量责任全推给测试人员，也时常发生。 敏捷强调全员质量，开发写单元测试、产品负责人参与验收、测试人员推动质量，三者缺一不可。

落到建议上：把验收标准写清并纳入团队共识；让自动化覆盖重复回归，把人工留给探索和场景验证；用 DoD 固化质量门禁；再选一套能贯通需求、任务、用例、Bug 与迭代的工具。在这方面，禅道把产品、项目、测试、文档放在同一平台，让质量数据与迭代进度在同一处沉淀。

测试管理是其中直接支撑测试工作的部分，覆盖用例、测试单与 Bug 管理，并能与需求和迭代关联。对规模化研发团队来说，工具层面的贯通，是让敏捷测试从理念落到日常的前提。

想进一步了解迭代实践与方法案例，也可以翻阅禅道图书馆的公开内容。

常见问题

敏捷团队还需要专职测试人员吗

需要。变化的是角色定位，不是必要性。测试人员从独立把关者变为团队内的质量推动者，工作重心向需求澄清、风险识别、自动化建设和探索式测试倾斜。团队规模较小时，测试能力也可能由开发人员共同承担，但这不意味着质量责任被稀释。

敏捷测试还需要写测试用例和测试计划吗

需要，但形态更轻。测试计划从厚厚的文档变为一页纸的要点，明确策略、重点范围与特定方法即可；测试用例更多针对用户故事和验收标准直接设计。省下的时间，用于分层自动化和探索式测试。

测试人员一定要会写自动化脚本吗

不一定要求每个人都精通开发，但需要理解分层自动化的结构，并能参与接口或单元层面的测试建设。自动化不是测试人员一个人的任务，而是开发与测试共同维护的基础设施。