什么是用户故事（User Story）和验收标准（Acceptance Criteria）

一个非常完美的基于现实场景的用户故事验收标准指南：

在软件开发行业中，“需求”一词决定了我们的目标是什么，客户真正的需求是什么，以及是什么可以使公司业务快速增长。

无论是作为开发软件产品的产品型公司还是以提供各种领域服务为主的服务型公司，最基本的、最主要的是需求，对于成功的定义就是如何更好满足需求。

在不同的项目方法论中，“需求”一词都有不同的名字。

在瀑布模式，它指的是“需求和spec文档”，在敏捷、SCRUM中它被定义为“Epic”,”用户故事”。

在瀑布模式下，需求文档是很多的，在一个产品阶段都有200页甚至更多。但是敏捷是不同的，因为需求都是小的功能或者模块（feature）的，产品都是循序渐进一步一步的方式去准备的（sprint）。

在这边文章中，我将以一种相对简单且容易理解的方式分享有关用户故事和他们验收标准的一些经验。

那么什么是用户故事呢？

一个用户故事就是一个功能或者feature的需求（requirement），被写出了也就一两行字，最多5行。一个用户故事通常是最简单的可能性需求，有且只能是一个功能或feature。

最常见使用的标准格式的用户故事如下：

作为一个用户/客户角色，我想要达到的目标是什么，以及达到目标的原因

e.g:

作为社交工具微信的用户，我想要在聊天对话框中有一个拍照图标去自拍和发照片，那么我就可以和朋友一起相互发照片。

什么是验收标准？

验收标准就是一系列可以接受的条件或者业务规则，且与功能或feature相互匹配和满足，同时也能被产品负责人和相关人接受。

这是用户故事完成很重要的一部分，它需要被产品负责人和业务分析人员认真的学习，因为错失一个很小的标准都会损失惨重。这是简单的编号或者编号列表。

格式如下：

在我做某些动作（action）之前请赐给一些先决条件，然后期望结果发生。

举个栗子：

1. 假设我正在和朋友聊天，我应该能够拍照

2. 当我点击照片时，我应该可以在照片上添加一些文字，然后发给朋友

3. 如果我的手机照相机有问题，一条错误信息，如“摄像头无法打开”…，相应的也应该出现

因此，用户故事为任何功能或feature定义了需求，另一方面，验收标准为用户故事或需求定义了“完成标准的定义”。

作为QA，理解用户故事非常重要，同时深刻理解验收标准，并且在测试开始前没有一点的疑惑。

深度挖掘的用户故事：

开始之前，让我们理解对一个基本的事情“深度”学习的重要性，比如用户故事

案例#1：

三年前，我当时在为一个手机app项目工作，这个app是一个快递系统的应用。

你当然会想到有人来寄快递，然后会要求在他们手机app上签名。这些签名会反映在快递服务商的网站上，比如顺丰。

问题：在某个冲刺（sprint）里，产品负责人对这个app有个用户故事是：“作为网站管理员，我应该能够在网站上看到用户寄快递的签名”。而这个网站相应做出变化和更新的以反映这些签名。

作为一名QA，你不得不去验证手机app的签名是否如期望的反映到网站上。

如果你看到这个用户故事，觉得很简单但是，这里有个隐藏的需求“对应历史的快递签名，没有签名反映功能，因此如果网站管理人员看到历史快递记录会发生什么呢？” 历史数据被清除吗？还是遇到这些数据报错？

当然不是，这些都应该被和谐的处理。

解决方案：当相应的数据表格被更新而为签名的位置增加一列，那些旧的数据应该变成NULL或者0值，而这些值需要被检查，一条信息“没有签名存在”被显示出来。

这个就被叫做来自产品负责人或者商业分析师的失误，但是必须做。成功完成一个功能但打破了一些东西就会令客户不满意。这些都是需要在一个相同的用户故事和冲刺中完成。

案例#2

6年前，我当时工作是关于“退休计划的金融软件”，这是个国际化的软件，金融顾问可以用它为不同的货币去做投资计划、储蓄等，服务很多的顾客。

问题：产品负责人给你的用户故事是：“作为金融顾问，我想要看到根据我的客户提供的金融资产详情的报告”。

这里有2个隐藏的需求，我称之为一个未完整的故事，因为：

a.这个报告应该考虑每天的汇率而不是历史的已经被查看过的报告

b.如果在提供详细的用户资产信息后，汇率变化，报告应该显示变化的汇率

解决方案：我直接跟产品负责人提出了这个担忧，使他意识到这2个必须尽快做的需求。他同意我的意见并且为即将到来的冲刺创建了2个不同的高优先级用户故事。

获取需求：这些需求被发现是因为我们很好的关注了产品、设计、结构等等。这些知识能够完成只有在彻底理解产品，理解模块间的交互，以及对即使只有2行文字说明的用户故事的深刻学习。

请注意，想使事情变得简单化就和商业分析师以及开发多讨论他们的想法。

深度看待验收标准

理解验收标准以及其他所有的条件&规则是特别重要的，比理解一个用户故事更重要。因为，如果一个需求是不完整的或是模糊的，需求可以在下个冲刺被开发，但是验收标准就会有缺失，进而导致用户故事不能上线。

假设我们都在用网上银行，甚至每一天都在使用它并且查看下载交易记录。如果你仔细观察的话，当你下载这些记录的时候有很多选项供你选择。比如有这么个选项信用卡/借款/所有。

现在假如产品负责人给你这么个用户故事“作为一个用户，我想下载我的账单以至于我可以看到我某个特定时间段的所有的交易”。

下面的是验收标准：

* 假设我在历史账单页面，我应该可以选择我需要下载账单的时间段

* 假设我在历史账单页面，我应该选择一个我需要下载账单的账户

* 假设我在历史账单页面，我不应该被允许选择一个将来的时间节点来下载账单

* 假设我在历史账单页面，我不应该被允许选择一个超过过去10年的时间节点来下载账单

* 假设我在下载账单，我应该能够看到下载的文件

* 假设我在历史账单页面，我应该可以选择下载不同格式的文件（Excel、pdf等）

如果你浏览这些标准，你发现3个事情丢失：

* 命名和下载文件名字的格式

* 有什么信息在文件里，每行都显示什么

* 交易的选项是哪个，信用卡、借款还是全部

像这些案例可能会在一段时间内发生，但是仍然需要很好的学习每个验收标准并且参考用户故事使其更加形象化。关于条件和业务你学的越深入，你的知识也会越多。

bug在初始阶段所带来的成本是难以和“测试”阶段相比较的。

发现用户故事和验收标准差异的重要性

在开发和测试开始之前的早期阶段，做一个深入的用户故事和验收标准的研究总是非常重要的。

因为涉及到：

#1) 时间的浪费：

如果是在开发或者测试进行中的时候，在用户故事/验收标准中发现一个差异或者错误，那么在剩余的冲刺时间内可能大量工作需要返工。

即使产品负责人有一些事情被遗失，返工也不会发生，他们会把用户故事移到下个冲刺。但是95%的概率是他们要求团队完成必要的东西以及在同个冲刺发布。

因此，就变成了整个团队的噩梦因为不得不花费额外的时间，周末加班或工作到深夜。在最早可能的阶段通过学习和讨论用户故事、验收标准就可以避免这种情况。

#1)工作努力（efforts）被浪费：

开发和测试不得不再一次重新审查完成的代码和测试用例。更新、增加以及删减，每个需求都不是一件容易的任务。这种情况就变得特别痛苦，再加上已存在的交付的压力。

在这种情况下，在开发和测试阶段就有可能出现一些错误。如果你遇到这种情况继续用“DevQA”配对，那么额外的工作也无法弥补。

结论：

深刻理解用户故事和验收标准只能通过花费巨大的时间去学习。

在市场上也没有特定的工具或课程去帮助你，因为一切都是关于产品的逻辑思维、经验、知识。

积极参与预先计划会议，和商业分析师探讨、自己学习都能够帮你完成。你花的努力越多，你学到和成长的越多。

作为QA还是开发，关于用户故事和验收标准每个人都必须在达成共识，然后来满足客户的期望来获得成功。