在很多年以前,有一种测试类型叫文档测试(暴露年龄了,不知道有多少读者记得这项测试活动),主要测试的对象就是需求文档。在版本初期,测试人员需要阅读一份很长的需求文档,这份文档会包含这个版本的所有功能点、交互方式及页面字段信息。研发团队通过这份文档来对齐需求。
在当下的敏捷环境中,我们显然不会这么玩。所有的需求都会被拆解成用户故事(User Story),从用户角度对系统的某个功能模块所做的简短描述(需求文档刚好相反,关注的是系统功能,很少会提及用户场景)。一个好的用户故事包括三个要素:
角色:谁要使用这个功能。
活动:需要完成什么样的功能。
商业价值:为什么需要这个功能,这个功能带来什么样的价值。
基于用户故事,我们如何获取我们所需要的信息呢?需要经过反复的沟通和确认,通过用户场景提问,把需求逐步澄清,并形成验收条件(Acceptance Criteria),产、研、测三方共同确认,形成共识,以保证大家对需求的认知不发生偏差,为后续团队正确的做事提供有价值的指导。
注意下 AC 与 TC(Test Cases)的区别,AC 是针对需求内容的说明和解释,根据需求制定验收标准,每一条 AC 应该体现业务价值,是需求交付时必须满足的一组条件。而 TC 主要是由测试来编写,而且 TC 会比 AC 更详细,必须包含 AC 所有的内容。TC 通常还应该包含很多异常用例,以确保系统对异常功能的处理。关于 TC,后续会专门来聊聊。
在对齐用户故事的过程中,我们可以通过上图的方向进行思考和提问,以达到澄清需求的目标。至于用户故事的最终呈现形式,并不是那么的重要。
如上图,用户故事地图,就是一堵用户故事墙,大级别的用户故事排在第一列,根据优先级,描述用户需求。对第一排故事成纵向分解。通过地图方式,可以让团队能够有一个空间充分思考各类可行方案,从而找到一条可以最大化投入产出的路子。可以让各种干系人对功能需求有相对一致的理解和整体认识。同时,根据这些故事排列出每个迭代的用户故事优先级。
用户故事地图还可以传送出很多的信息,比如它的橫纵坐标,其实是非常有意义的,横轴代表了用户的使用路线图,纵轴代表了需求的优先级。那几条红色的虚线,就代表了每个迭代需要做的基本内容了,相当于一个粗粒度的迭代待办列表(Sprint Back log)。
注意:这个地图是动态变化的。每经过一段时间,团队都应该重新审视这张用户故事地图,看看我们的规划是否发生了偏差?还有哪些需要补充的?有没有更好的意见或者建议?是否有些功能是不必要的?
分享一份我司内部关于需求的管理方式,基于 Confluence 工具,模板如下图(实际使用由于保密问题就不放出来了)。好像要填很多的内容,很多人可能会有疑问,敏捷不是不提倡写文档么,怎么你们还要写这么多内容?澄清下,敏捷从来都没有提不写文档,而是提倡写有价值的文档。通过下面这个文档,我们可以很清晰的知道用户故事的信息:在哪个迭代被研发,需求内容是什么,如何去做验收。不好么?
独立性(Independent):要尽可能地让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划,确定优先级,工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。
可协商性(Negotiable): 一个用户故事的内容要是可以协商的,用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述,不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节,实际上限制了和用户的沟通。
有价值(Valuable):每个故事必须对客户具有价值(无论是用户还是购买方)。
可以估算性(Estimable):开发团队需要去估计一个用户故事以便确定优先级,工作量,安排计划。通常让开发者难以估计故事的问题来自:对于领域知识的缺乏(这种情况下需要更多的沟通),或者故事太大了(这时需要把故事切分成小些的)。
短小(Small):一个好的故事在工作量上要尽量短小,最好不要超过 3 天的工作量(我们的实践,具体可根据团队自行定义),用户故事越大,在安排计划,工作量估算等方面的风险就会越大。
可测试性(Testable):一个用户故事要是可以测试的,以便于确认它是可以完成的。如果一个用户故事不能够测试,那么你就无法知道它什么时候可以完成。
在需求评审的阶段,从用户使用场景的角度出发,通过提问,把需求逐步澄清,并形成验收条件,产、研、测三方共同确认,形成共识,以保证大家对需求的认知不发生偏差,为后续团队正确的做事提供有价值的指导。根据用户故事的基本特性,做到业务可验收、研发可实现、测试可验证、部署可交付。
把 “确认正确的事” 说明白了,接下来,我们聊点什么呢?敬请期待。