测试视角的 DoR 与 DoD
DoR（就绪定义）与 DoD（完成定义）是团队的工作协议：需求进迭代前要有可测的验收标准，任务宣称完成前要有测试证据与缺陷收敛。测试参与定义这两道门，能减少开发末期才发现需求不可测的返工，也让「完成」有统一的证据口径，而不是各自解释。
基本信息
| DoR 关注 | 验收标准可执行、依赖澄清、环境可评估 |
|---|---|
| DoD 关注 | 用例执行完成、缺陷处理、自动化与文档更新 |
| 测试职责 | 参与协议定义，并在每张卡片上做门检查 |
| 常见证据 | 用例结果、缺陷状态、自动化记录、变更说明 |
| 维护节奏 | 迭代回顾时校准两道门的内容与措辞 |
| 边界 | 轻量流程可合并检查项，但证据要求不能省 |
示例条目
示例条目
# DoR（进迭代前）：
验收标准明确、依赖已澄清、环境可评估
# DoD（宣称完成前）：
用例执行完成、缺陷处理、自动化补齐、文档更新两道门的核对清单
| 门 | 核对问题 | 常见缺口 |
|---|---|---|
| DoR | 验收标准可执行、可判定吗？ | 标准模糊，测试无法设计用例 |
| DoR | 异常与边界写进验收标准了吗？ | 只写主流程，异常后补 |
| DoR | 依赖与环境已澄清吗？ | 数据与账号没准备 |
| DoD | 用例执行完成、失败有结论吗？ | 失败无结论就宣称完成 |
| DoD | 自动化补齐与文档更新了吗？ | 回归资产没沉淀 |
| DoD | 变更影响面与回归范围记录了吗？ | 影响面靠口头说明 |
典型使用场景
- 迭代计划会：用 DoR 筛选可进迭代的需求。
- 每日站会：暴露卡在门上的阻塞，当日升级。
- 卡片流转：DoD 未满足不进入完成列。
- 评审验收：把证据清单作为验收材料。
- 复盘改进：统计两道门被击穿的次数与原因。
- 新人辅导：用两道门解释团队的工作协议。
DoD 不要只写「测试通过」：写明证据类型与存放位置，验收才能自动核对。
DoR 缺失时最常见的返工是需求不可测：验收标准写成可执行例子再进迭代。