02｜敏捷迭代里的测试和瀑布模型比，流程上有什么不同？

开场先给节奏对比：瀑布是阶段串行（测试在下游等），敏捷是迭代内并行（两周一迭代，需求开发测试交叠进行）——节奏差异是所有流程差异的根源。

回答思路

第一步：讲测试的四个具体变化

• 时间上：没有集中的测试阶段，测试和开发同步进行（开发做一个我测一个，持续集成持续验证）
• 用例上：迭代级的小集合代替大而全（随 story 走，每个故事有自己的验收测试）
• 角色上：测试参与全迭代活动（站会、评审、回顾都要在，不是接到提测才出现）
• 回归上：自动化回归成为刚需（两周一版没有时间手工全量回归，自动化是敏捷测试的生存前提）

第二步：讲敏捷测试的独特活动

• Story 验收标准的三方共建：开发、测试、产品对验收条件达成一致，测试把它翻译成验收测试
• 迭代内的持续测试：提测的概念淡化，分支合并前就开测
• DoD 的质量条款：「完成的定义」里含测试通过，测试标准进团队契约

第三步：讲瀑布没消失的行业现实

外包、银行、To G 项目大量还是瀑布或类瀑布（需求稳定、合规要求留痕）。能讲「什么场景适合什么模型」比站队敏捷更显成熟。

收尾：给认知收口

模型的本质是「什么时候发现缺陷」——敏捷的价值是缺陷反馈周期从月缩到天，测试的所有动作变化都围绕这个压缩展开。

考察重点

维度	说明
企业动机	敏捷是国内互联网的主流研发模式，企业要看你是「真在敏捷团队待过」还是「背了 scrum 名词」，四个变化里讲不出细节的会被判定没经历过
过线标准	节奏对比 + 测试的四个具体变化
区分度	讲 DoD 质量条款、story 验收三方共建的是敏捷老兵；只会说「敏捷就是快」的是没待过
加分项	瀑布仍适用的场景判断（行业视野）
减分项	认为敏捷没有流程没有文档（是轻量不是没有），或把敏捷等同于「不用写用例」，认知错误

来源

整理自知识星球帖《面试情报 10｜测试流程与团队协作 20 题》，返回题库。