测试那些事儿（十五）- 用户故事编写模板

用户故事概念&内容

这里罗列概念比较干，但还是不得不说，因为这些是引出用户故事编写思路的引子。如果已经了解了可直接看后面“我的用户故事模板”部分～

用户故事三要素

角色、目标（收获）、价值

用户故事3C原则

卡片(Card)、交谈(Conversation)和确认(Confirmation)

• 卡片（Card）：最初的用户故事一般在小卡片上写着故事的简短描述，规则和完成标准（AC-用例）。

  
  
  卡片（Card）
  
  

  现在都电子化了，所以如果觉得用物理卡片麻烦，可以用电子文档记录。

• 交谈（Conversation）：用户故事背后的细节来源于和客户或者产品负责人的交流沟通，确保各方对故事的理解正确。同时也是卡片中的规则和完成标准的来源。

  
  
  交谈（Conversation）

• 确认（Confirmation）：通过验收测试确认用户故事被正确完成，也就是保证满足卡片中的规则和完成标准。

  
  
  确认（Confirmation）

用户故事INVEST原则

Independent（独立的）；Negotiable（可协商的）；Valuable（有价值的）；Estimable（可评估）；Small（小的）；Testable（可测试的）。

INVEST原则

1. Idependent（独立的）
   要尽可能的让一个用户故事独立于其他的用户故事。用户故事间保持独立性不仅便于排列和调整优先级，使得发布和迭代计划更容易制定，便于独立地理解、跟踪、实现、测试以及频繁交付，也使得用户故事的大小估算所涉及的范围更清晰，从而估算偏差更小。

2. Negotiable（可协商的）
   一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事只是对用户故事的一个简短的描述，不包括太多的细节；具体的细节在沟通阶段产出。一个用户故事带有了太多的细节，实际上限制了用户、团队的想法和沟通。

3. Valuable（有价值的）
   每个故事必须对客户具有价值（无论是用户、购买方还是公司内部角色）。用户故事对于最终的用户是有价值的，因此应该站在用户的角度去编写，描述的是一个一个的feature，而非一个一个的task。
   这个特点促进团队的开发和测试成员由传统的指令式工作方式向自驱动的价值导向工作方式转变，使团队中的每个人知道自己每天做的工作价值。

4. Estimatable（可评估）
   计划会议里面一个很重要的环节，那就是故事点的估计。实际上就是对要开发的User Story进行一个粗量级的估算，以便于团队能够知道这个user story的复杂度（工作量）。
   重点放在当前迭代里能否按照该用户故事的接收条件和团队定义的DoD(完成标准)来完成这个用户故事，如果不能完成，给出理由，由PO来决定是否拆分或者重新设计用户故事。
   让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。

5. Small（小的）
   一个好的故事在工作量上要尽量短小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。

6. Testable（可测试的）
   一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：软件应该是易于使用的。

我的用户故事模板

上面的都是死的概念，为了能真正理解，咱们可以推导自己理解的用户故事模板。我根据前面提到的用户故事三要素来思考：角色、目标（收获）、价值

角色：作为XX角色，
目标（收获）：我 希望/想要/需要 得到 XX 服务/结果/数据/承诺品如合同/声望等，
价值：以便达到满足角色XX需求（马斯洛需求层次理论-生理、安全、归属、尊重、自我实现）

马斯洛需求层次理论

注意这个模板中：

• 目标（收获） 中大部分时间不是表述具体的做什么，而是做什么后拿到的东西。具体做什么的一系列展开更像是根据用户故事写出的AC（用例）。描述收获而不是具体做什么，恰恰可以激发为怎么得到想要的东西让大家面对面的去聊方案，这样才能让思维发散出去（INVEST中Negotiable原则）。
• 价值 中角色需求的根本能归结到马斯洛需求层次理论，但用户故事往往需要更具像化的表述，用来更清晰的体现角色需求，如具像化的需求可能是：更高效、更省力、更好体验、更实惠（高性价比）、更健康、更安全、更满足、更受尊重等等（INVEST中Valuable原则）。可参考马斯洛需求层次理论的细粒度划分。
• 过程中，如果一个用户故事很大，可以再将其尽可能拆分为独立的小故事并且是可以验证的（INVEST中的Idependent、Small、Estimatable、Testable原则）。

实践一下

几乎每个公司都有客服人员，那我们就拿他们作为角色来写一下他们的需求吧。作为员工，绝大部分人其实是为了获得报酬而工作的。这么想的话整个过程就可以定义用户故事为：

作为客服，我希望能够获得工作报酬，以便让我能够活着。

大家也许要笑了，但是我觉得这就是一个用户故事，因为它符合我之前说的用户故事模板。但这个故事并没有意义，一是它太大了，二是它不能指导产品需求的扩展，更不用说用来优化客服的工作。
想一想，一个客服来找产品经理提需求，肯定是要结合客服平日最主要工作的收获，如接受客户咨询并给予解答获得好评。那这个用户故事该怎么写？

作为客服，我希望能够尽可能多的得到客户好评反馈，以便我能获得更多的报酬。

相对第一个故事，这个用户故事好多了是不是，起码我们具像化了用户的收获，为之后的沟通讨论奠定了基础。但它还是有些大，因为根据这个故事我们起码还无法评估怎么做。我们可以进行故事的拆分有：
作为客服，我希望能够尽可能多的得到客户好评反馈，以便我能获得更多的报酬。

• 作为客服，我希望能够在客户咨询时得到通知，以便我立即能够给予回应。（更高效）
• 作为客服，我希望能够在客户咨询时获得客户基本信息，以便我快速准确的解答用户的问题。（更高效）
• 作为客服，我希望能够获得客户的评价，以便我的工作可被评估。（更客观）

上面拆分的3个用户故事的用户收获和价值更加的具像化了，而且也更好评估了。我们拿第一个用户故事来模拟下可能的AC（用例）：
作为客服，我希望能够在客户咨询时得到通知，以便我立即能够给予回应。（更高效）

• AC1：在客户发起咨询时，客服能在电脑上收到一条弹出框提醒。
• AC2：客服能在弹出框提醒上直接进入反馈页面。
• AC3：N个客服不会出现同时收到同一个客户咨询单的情况。
• AC4：。。。

测试人需关注

了解用户故事可以让测试人员更好的了解产品经理的思路和产品的重心，为我们分析产品需求提供工具，同时也帮助我们对不符合用户需求的产品设计提出质疑，保证产品的走向。实践中，可以将用户故事作为分析需求、跟踪需求的方法，起到纲领作用；而用例作为记录需求细节的工具。