从测试看需求

话接上回（需求端到端交付管理），当产品团队确认了做正确的事（需求）后。研发团队如何对齐这件事呢？在很多年以前，有一种测试类型叫文档测试（暴露年龄了，不知道有多少读者记得这项测试活动），主要测试的对象就是需求文档。在版本初期，测试人员需要阅读一份很长的需求文档，这份文档会包含这个版本的所有功能点、交互方式及页面字段信息。研发团队通过这份文档来对齐需求。

01

什么是用户故事

在当下的敏捷环境中，我们显然不会这么玩。所有的需求都会被拆解成用户故事（User Story），从用户角度对系统的某个功能模块所做的简短描述（需求文档刚好相反，关注的是系统功能，很少会提及用户场景）。一个好的用户故事包括三个要素：

角色：谁要使用这个功能。

活动：需要完成什么样的功能。

商业价值：为什么需要这个功能，这个功能带来什么样的价值。

例：

作为信用卡客户Jack

希望可以从取款机中用信用卡取现金

这样能够购买只能用现金购买的商品

02

验收条件

基于用户故事，我们如何获取我们所需要的信息呢？需要经过反复的沟通和确认，通过用户场景提问，把需求逐步澄清，并形成验收条件（Acceptance Criteria），产、研、测三方共同确认，形成共识，以保证大家对需求的认知不发生偏差，为后续团队正确的做事提供有价值的指导。

注意下AC与TC（Test Cases）的区别，AC是针对需求内容的说明和解释，根据需求制定验收标准，每一条AC应该体现业务价值，是需求交付时必须满足的一组条件。而TC主要是由测试来编写，而且TC会比AC更详细，必须包含AC所有的内容。TC通常还应该包含很多异常用例，以确保系统对异常功能的处理。关于TC，后续会专门来聊聊。

在对齐用户故事的过程中，我们可以通过上图的方向进行思考和提问，以达到澄清需求的目标。至于用户故事的最终呈现形式，并不是那么的重要。

03

用户故事地图

如上图，用户故事地图，就是一堵用户故事墙，大级别的用户故事排在第一列，根据优先级，描述用户需求。对第一排故事成纵向分解。通过地图方式，可以让团队能够有一个空间充分思考各类可行方案，从而找到一条可以最大化投入产出的路子。可以让各种干系人对功能需求有相对一致的理解和整体认识。同时，根据这些故事排列出每个迭代的用户故事优先级。

用户故事地图还可以传送出很多的信息，比如它的橫纵坐标，其实是非常有意义的，横轴代表了用户的使用路线图，纵轴代表了需求的优先级。那几条红色的虚线，就代表了每个迭代需要做的基本内容了，相当于一个粗粒度的迭代待办列表（Sprint Back log）。

注意：这个地图是动态变化的。每经过一段时间，团队都应该重新审视这张用户故事地图，看看我们的规划是否发生了偏差？还有哪些需要补充的？有没有更好的意见或者建议？是否有些功能是不必要的？

04

实例分享

分享一份我司内部关于需求的管理方式，基于Confluence工具，模板如下图（实际使用由于保密问题就不放出来了）。好像要填很多的内容，很多人可能会有疑问，敏捷不是不提倡写文档么，怎么你们还要写这么多内容？澄清下，敏捷从来都没有提不写文档，而是提倡写有价值的文档。通过下面这个文档，我们可以很清晰的知道用户故事的信息：在哪个迭代被研发，需求内容是什么，如何去做验收。不好么？

05

延伸：用户故事的六个特性

独立性（Independent）：要尽可能地让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。

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

有价值（Valuable）：每个故事必须对客户具有价值（无论是用户还是购买方）。

可以估算性（Estimable）：开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。通常让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。

短小（Small）：一个好的故事在工作量上要尽量短小，最好不要超过3天的工作量（我们的实践，具体可根据团队自行定义），用户故事越大，在安排计划，工作量估算等方面的风险就会越大。

可测试性（Testable）：一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。

06

小结

在需求评审的阶段，从用户使用场景的角度出发，通过提问，把需求逐步澄清，并形成验收条件，产、研、测三方共同确认，形成共识，以保证大家对需求的认知不发生偏差，为后续团队正确的做事提供有价值的指导。根据用户故事的基本特性，做到业务可验收、研发可实现、测试可验证、部署可交付。

把“确认正确的事”说明白了，接下来，我们聊点什么呢？敬请期待。

END

如果想阅读更多文章，请关注我的公众号