用户故事要经过 DoR 的检测才干被研发团队承受，只有扛住 DoD 的考核才干迈出走向客户第一步。点击了解 DoD 和 DoR ：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
有些测验人员或许会用流程图、思维导图、检核表等办法书写检验规范，但写法不是要点，能清楚呈现「检验规范」，阐明客户需求期望的便是好办法。
三、 检验规范的八点误区
-
作业项目完结后才进行检验规范的讨论。
-
检验规范事无巨细，单一功用就有不同组合的测验。
-
检验规范规模太广，现已超过本非必须进行的规模。
-
检验规范不是用户看到的情境，而是底层的技术细节。
-
团队对检验规范还没有达到一致就开始作业。
-
检验规范无法独立，需求其他检验规范的合作才干进行测验。
-
测验的条件是充满变数的，无法模拟的。
-
只由测验人员或产品负责人单向设计出的检验规范，开发团队事前不知情。
原文作者：Vince Huang
文章来历：Medium【文思不藏私】专栏
想要了解更多程序人生、灵敏开发、项目管理、行业动态等消息，欢迎关注Liga@juejin了解更多详情，或点击咱们的官方网站LigaAI-智能研发协作平台线上请求体验。
