如何编写用户故事的验收标准
【本文翻译自 Clear Acceptance Criteria for User Stories with Examples】
在一个完美的世界里，人们看一眼就能明白彼此在想什么，没有什么能让他们之间产生困惑。但在现实世界中，我们要想办法把自己的想法传达清楚，让同行不会误解我们。
在软件开发中，验收标准（Acceptance Criteria）有助于正确设定客户对产品的期望。诸如 "我希望我的应用很棒，受到尽可能多的人欢迎 "这样的标准并不能真正说明什么；我们通过参考用户故事（User Story）的验收标准来消除客户和开发团队之间的误解。
在这篇文章中，我们将讨论敏捷方法论（如Scrum和Kanban）中的验收标准，并为你提供一些比较好的验收标准的例子。
Scrum、用户故事和验收标准在2020年并不只是流行语
我们提到Scrum是有原因的。Scrum是一个敏捷框架，可以帮助软件开发团队交付任何复杂的产品。在RubyGarage，我们更喜欢按照Scrum的方法论工作，最近我们甚至发布了自己的Scrum估算扑克应用——Scrummer。
在Scrum中（其他敏捷方法也一样），我们用“用户故事”和“验收标准”这样的术语来描述需求，以确保清楚地描述最终用户将如何使用一个应用程序，以及团队应该如何完成每个任务。
当我们开始构建一个产品时，我们与客户合作定义用户故事。用户故事的编写格式如下：
作为(某个类型的用户)，我想(执行一些行动)，以便我(可以实现一些目标/结果/价值)。
As a (type of user), I want to (perform some action) so that I (can achieve some goal/result/value).
用户故事的目的是解释用户在系统中的角色，他们所期望的活动，以及他们打算通过成功完成一个用户故事来得到什么。对于敏捷团队来说，用户故事是识别用户需求的主要方法。
定义验收标准
那么，我们如何确保用户故事的正确完成，并符合客户的要求呢？这就是验收标准的作用。验收标准是一个正式的需求清单，它确保所有的用户故事都能完成，所有的场景都能被考虑在内。简单来说，验收标准规定了满足用户故事的条件。简明扼要的标准可以帮助开发团队避免对客户的需求产生歧义，防止沟通不畅。
撰写验收标准不仅对引起客户对产品的愿景很重要，对开发过程也很重要。不同的人会从不同的角度看同一个问题，这很正常。明确写出的标准为你打算实现的功能引入了一个单一的解决方案。
验收标准是用来干什么的？
- 确定边界。验收标准帮助开发团队定义用户故事的边界。换句话说，验收标准可以帮助你确认应用程序何时能如愿以偿地发挥作用，也就是说，一个用户故事已经完成。
- 达成共识。有了验收标准，开发团队与客户就会同步。团队清楚地知道应该满足哪些条件，就像客户知道对应用的期望一样。
- 作为检验的依据。验收标准是正常流程和异常流程测试的参考依据，旨在检查系统是否按预期工作。
- 进行准确的规划和估算。验收标准方案可以将用户故事正确划分为任务，从而正确估计和规划用户故事。
谁来写验收标准，何时写？
无论是客户还是开发团队都要写验收标准。通常情况下，由产品负责人（客户）撰写的标准会由开发团队的成员进行审核，以确保标准规定得很清楚，并且从开发的角度来看，没有任何技术限制或不一致的地方。如果产品负责人有一定的软件开发经验，并且知道如何编写项目文档，这样的流程是一种很好的协作方式。
如果你更愿意把编写验收标准的任务交给开发团队，那么需求分析师、项目经理或QA专家应该处理这项任务，因为他们知道技术和功能的可行性。
请记住，验收标准应该在迭代开始前确定下来，千万不要等开发开始后才确定。因此，团队和产品负责人应该在迭代前就交付物的最低标准达成一致。
如何写验收标准？
验收标准有几种类型。最受欢迎的是面向规则的（以清单的形式）和面向场景的（以场景的形式来说明每个标准）。面向场景的类型在敏捷团队中很受欢迎，因为它有助于跨越需求，设想各种用例，并进一步使用场景进行手动和自动验收测试。
使用面向场景的方法描述验收标准的常用模板是源于行为驱动开发(BDD)的Given/When/Then格式。Given/When/Then格式用于编写验收测试，以确保满足所有的规范要求。
这种格式对人类来说很方便（因为它是以熟悉的因果关系方式写的），对Cucumber和RSpec等自动化测试工具来说也很方便。例如，当我们建立一个有两种用户（注册用户和方可）的网站时，我们很可能为一个用户故事写下以下验收标准，定义注册用户的登录功能：
作为一个已注册的用户
我希望能够登录一个网站
以便我可以访问到我的个人资料
场景： 系统用户用有效凭证登录
Given：鉴于我是该系统的已注册用户
我在登录页面上
When：当我在 "用户名 "和 "密码 "字段中填写我的正确信息时
点击登录按钮
Then：然后我就登录成功了
Given/When/Then模板可以帮助你减少编写测试用例的时间，因为你在前期描述了系统的行为。我们更喜欢用第一人称 "我 "来写验收标准，因为这有助于我们从用户的角度来说话，让用户的需求铭记在心。
这里有几个小技巧，可以帮助你写出优秀的验收标准：
- 保持你的标准定义清晰，这样项目团队的任何成员都能理解你想要传达的理念。
- 保持标准的真实性和可实现性。定义你能够提供的最低限度的功能，并坚持下去。另一方面，不要试图描述每一个细节，因为你有可能使你的待办事项列表变得杂乱无章，并被埋在许多小任务之下。
- 与所有利益相关者协调，使你的验收标准建立在共识的基础上。
- 创建可衡量的标准，使您能够充分估计开发时间，以便能够在预算和时间限制内完成。
- 考虑提供检查表，使你能够看到验收标准覆盖了哪些用户故事。
清晰的验收标准有效地节省了开发时间
验收标准的例子
在本节中，我们将通过一些常见的功能来举例说明验收标准要怎么写。我们会先定义一下用户故事，因为验收标准是在用户故事指定了所有功能后写的。
例1
我们的第一个用户故事描述了网页搜索功能。
作为一个网站用户
我希望能在网页上进行搜索
以便我找到必要的信息
根据Given/When/Then模板，接受标准如下：
场景： 用户通过名称搜索一个项目
Given：鉴于我的角色是注册用户或访客
When：当我打开 "产品 "页面时
Then：系统就会显示出所有产品的列表
并且系统在屏幕右上角显示 "搜索 "部分
When：当我在 "搜索 "字段中填入产品列表中现有项目的名称时
我点击 "应用 "按钮或按键盘上的回车键
Then：系统就会在搜索结果部分显示出与输入的产品名称相匹配的产品
并且系统在搜索结果部分的顶部显示了搜索结果的数量
例2
下一个例子代表了一个反馈表页的验收标准，用户故事如下：
作为一个网站用户
我希望能够提交反馈意见
以便站长们在以后的网站更新过程中可以考虑我的意见或关注点
这块功能的接受标准是：
场景： 用户提交有效数据的反馈表
Given鉴于我的角色是登录用户或访客
When”当我打开反馈页面时
Then系统展示给我一张提交反馈表，包含 "电子邮件"、"姓名 "和 "评论 "字段，这些字段是必须的
When当我在 "电子邮件 "字段中填入有效的电子邮件地址时
我在 "姓名 "一栏填上我的名字
我在 "评论 "栏里填上我的评论
我点击 "提交反馈 "按钮
Then系统就会提交我的反馈
然后，系统显示 "您已成功提交反馈意见 "的闪动信息
然后，系统会清除提交反馈表的字段
例3
最后，我们再来看一个在博客发表评论功能的用户故事和验收标准。只有登录的用户才能添加评论。"添加评论 "功能的用户故事将是：
作为一个登录用户
我希望能够对博客文章发表评论
以便我可以得到问题的反馈
这个功能的验收标准是：
场景：登录的用户在博客文章上发表评论
Given鉴于我是已登录用户
When当我打开有特定博客的页面时
Then系统会在博文下方的 "评论 "部分显示出其他用户添加的评论列表
并且系统在 "评论 "栏目的上方显示 "添加评论 "字段
When当我在 "添加评论 "字段中填写我的评论时
我点击 "提交 "按钮
Then然后系统会保存我的评论
然后，系统在 "评论 "部分的最上方显示了我的评论
然后，系统从我的评论开始，左侧就显示出我的用户名和资料照片
然后，系统在我的评论下面显示 "删除 "和 "编辑 "图标
收尾工作
正如你所看到的那样，编写验收标准对于客户和开发团队来说，确实是一项双赢的活动：它不仅能帮助团队准确地知道他们必须做什么，而且还能让客户及时了解开发过程，让他们检查开发的软件是否符合实际的业务需求。
不要被用户故事和验收标准吓跑了——你在描述和详细说明所有功能上投入的时间最终会得到回报。验收标准作为用例建模和测试用例的基础，可确保您实现业务目标并生产出无错误的应用程序。
