用户故事要经过 DoR 的考验才能被研发团队接受，只有扛住 DoD 的考核才能迈出走向客户第一步。点击了解 DoD 和 DoR ：如何消减敏捷开发协作中的「认知偏差」？

在敏捷开发中，想要评估一个故事是否达到客户对需求的期待，就要让它去接受「验收标准」的考验：用户故事必须「通过」所有的验收标准，才算是真正地产生价值。

DoD 是对迭代中「所有」工作事项或用户故事的「基本要求」，而验收标准则是对「特定」用户故事的「需求细节」进行的逐一验证。

一个工作项目是否能如质如期地完成，最重要的部分就取决于开工前是否有明确的「验收标准」。

一、 验收标准的目的

01 描述明确的需求范围

通过对验收标准的讨论，团队可以了解产品负责人与利益关系人对需求的期待，也能更明确地掌握需求的范围，方便估计时程与测试涵盖范围。

02 描述错误的案例处理

编写验收标准条例可以全方位地考虑需求可能会出现的限制与错误情况，并延伸对应的处理方式。在开发过程中，实现快乐路径（Happy Path）相对简单，但「错误／例外处理」却常常被遗漏掉。

03 增加共识的讨论模式

透过对验收标准的讨论，产品负责人和开发团队能够一次又一次地理解需求目的，确保对需求持有相同的理解，才能在最后的展示阶段完整地呈现结果。

04 提早列举出测试案例

书写验收标准的过程也是测试人员和产品负责人向开发团队说明和同步测试最低标准的过程。这样才不会出现开发产出越过测试，或待测试项目未完成开发等情况。

05 时程工期的有效估计

只有完成验收标准的讨论后，开发团队才能更好地明确需求和测试的范围，对需求开发做出更准确的估计，其中包括时间、人力的绝对估计，以及点数、大小的相对估计。

二、 验收标准的写法

常见验收标准的写法有三种，分别是情景式、规则式和习惯式。

01 情境式写法 Scenario-based

「情境式写法」是面向场景的，其信息描述最为完整，也因此在敏捷团队中被更广泛地传播和应用。

情境式写法的结构包含了以下五个元素，传递了「测试用例」和「价值交付」两方面信息。

• 情境 Scenario：描述用户使用的场景／情景

• 假定 Given：描述验收标准的预先设定条件

• 当 When：描述用户在什么情况／操作下

• 然后 Then：描述预期会发生的结果

• 而且 And：描述预期会发生的更多结果

​

举个例子说明一下：

情境 用户帐号登录

Given 用户进入「账号登录」页面，

When 用户输入错误的用户名或登录密码时，

Then 登录页面会弹出「密码错误」的提示，

And 登录页面也会呈现「忘记密码」跳转入口。

02 规则式写法 Rule-based

「规则式写法」是用条列的方式列出所有需要验证的测试案例，通常是一份清单形式的文件。相比情景式写法，规则式的验收标准能覆盖更多、更广的测试范围，但也省略了对需求价值的描述和说明。

测试案例「用户账号登录」的验证规则如下：

• 用户输入正确的账号、密码时，可以登入账号页面查看账号信息；

• 用户输入存在的账号、错误的密码时，需要出现提示信息「密码错误」；

• 用户输入不存在的账号时，需要出现提示信息「该账号不存在」；

• 用户连续输入错误的密码超过三次时，需要出现提示信息「密码已错误三次，请重设密码（附跳转）」。

03 用户角度的习惯写法 Customer-based

有些测试人员可能会用流程图、思维导图、检核表等方式书写验收标准，但写法不是重点，能清楚呈现「验收标准」，说明客户需求期望的就是好方法。

三、 验收标准的八点误区

1. 工作项目完成后才进行验收标准的讨论。

2. 验收标准事无巨细，单一功能就有不同组合的测试。

3. 验收标准范围太广，已经超过本次要进行的范围。

4. 验收标准不是用户看到的情境，而是底层的技术细节。

5. 团队对验收标准还没有达成共识就开始工作。

6. 验收标准无法独立，需要其他验收标准的配合才能进行测试。

7. 测试的条件是充满变数的，无法模拟的。

8. 只由测试人员或产品负责人单向设计出的验收标准，开发团队事前不知情。

原文作者：Vince Huang

文章来源：Medium【文思不藏私】专栏