需求拆分被测试挑战：拆还是不拆？这是个问题……
本文字数：3349 字
阅读时间：10 分钟
本文对话来自于和外部小伙伴讨论需求拆分工作中的真实困惑，感谢小伙伴贡献话题。
另外，感谢半堂老师（ ThoughtWorks BA 孟辰 ）对本文内容作出的补充和梳理。
业务价值考量：Valuable
小A
晓南，我最近在梳理用户故事拆分的必要性，但是经常被测试同学挑战……
按流程步骤拆分的需求：
原故事：作为用户，我希望查询并购买商品
故事1：作为用户，我希望可以查询商品
故事2：作为用户，我希望将商品加购物车
故事3：作为用户，我希望选择发货地址
故事4：作为用户，我希望下单付款
小A
例如这个用户故事拆分后，测试同学说：我没有办法按照场景完成完整的测试，每个故事单独测意义不大，还不如最后一起测。你怎么看？
测试同学说得对，这其实是按照流程操作步骤来拆分了，最好不要这样拆，要按场景拆。
晓南
小A
那这样一个流程会不会太大了？感觉场景的粒度不太好把握。
一个流程能直接完成，就不会太大。如果你拆出来的小故事，每个都有子流程，或者有复杂逻辑需要单独验证的，就可以拆。如果拆出来每个故事只是流程中的一个操作步骤，就不拆。
晓南
小A
我之前的想法是让测试同学mock一些输入的数据，来验证单个步骤测试的结果；现在听起来应该是要有一个完整的测试闭环，输入和输出。
这是测试的事情，跟用户故事本身没啥关系。用户故事要提供独立的价值，“加入购物车”本身是没啥独立价值的，只是一个动作。
也不是一定要闭环，比如说“购物车的逻辑限制”：购物车总件数、总商品数、每件商品的最大件数……这就有独立价值，但这并不构成流程上的闭环。
晓南
小A
我看到需求拆分方法里的工作流，其实不是我之前说到的流程咯？
不是，上面的拆分已经细到操作步骤了。假设个内容发布的例子：
工作流：内容提交，审批，修改，发布…
操作步骤：上传图片，编辑文字，提交或撤回…
晓南
小A
所以拆分的前提应该是：对用户当前来说是有意义的故事，只交付这一个需求也是对用户有价值的。
Bingo，这句非常在点上。
这是Story的INVEST原则中的Valuable嘛~
但这对一些需要拆分的技术卡就不work了，可以这样想：这个技术卡不服务用户，而是服务系统或者某些服务，这样就有value了。
晓南
小A
我有个误解是：只要保证 release上线时候的整体对客户有价值就行了。
整体有价值没问题的，但是单独有价值是保证拆分的可工作性。记不记得讲AC时候说过，不要按交互步骤写AC？连AC都不要按步骤，更何况Story啦~
晓南
团队效率考量：Size Properly
小A
如文章发布工作流：内容提交，审批，修改，发布。
我需要拆分一个用户故事是能够完成整个工作流的，可以是很简单的工作流。
例如：提交、发布
又例如：很简单的提交、审核、发布
对的，先把骨架搭起来，再添皮肉。
刚才下单的那种拆法，就像我先摆个头骨，再摆个颈椎。
晓南
小A
那这里的提交、审核、发布，是不是也可以拆为三个故事？
如果步骤复杂可拆，如审核。
步骤不复杂就不用拆了，如提交，只是按一个按钮就不拆，但如果提交有一些复杂的校验逻辑，就可拆。
晓南
小A
如果把审核拆分出去了，那测试的时候单独测提交是有意义的吗？
审核你拆的不是提交，而是审批人审核的子流程哦~
注意一下，这里其实隐含了一点，用户变了，提交和审核不是一个用户。
审批人审核要在这个卡里测。提交当然也要测，但不是这张卡的范围，需要在提审的卡里测。
晓南
可以这样想：这个故事，用户脑子里要做一个有业务意义的事，不管他在提交页面做什么，都是为了提交过审，这就是一个故事，如果你说提交可以编辑文字，上传图片，这些都不是他的业务目的。
晓南
小A
这个能理解。所以提交、审核、发布，是可以写成三个故事的。
story1：提交
story2：审核
story3：发布
针对 story1 ，我可以继续强化功能，拆分更多提交的细节，比如提交时复杂的信息校验逻辑。
没错。再看回下单的例子，每一步只是一个操作，不需要验证某个步骤的复杂性，那其实就是一个事情。不用为了拆而拆。
晓南
半堂
补充一下，步骤复杂不复杂有两种情况：
一种是用户感知到页面复杂，比如复杂的表单校验，我们需要拆分页面去分别校验，每一步都有一个保存的结果，可以返回可以修改，这是用户感知的复杂；
另一种是实现或工作量的复杂，比如前端需要画20多个文本框，带有字符校验的，提交的时候还有交叉的业务校验，这也要拆。但是这是基于工作量的原则，不是从用户角度出发的，用户不能直接感知到这种复杂性。
#
团队效率考量的拆分思考点：
1. 一个故事太大，超过团队习惯的最大点数，或一个迭代内做不完
2. 某些功能的交互过程具备复杂性（用户感知），或实现具备复杂性（用户不感知），如某些算法、校验逻辑
3. 用户主体变了，不是一个人做的事情，比如提交和审批
4. 同一功能的增强，简单场景和复杂场景，如搜索和高级搜索
小A
这个可以理解。我在想，有没有真的需要用户很长流程才能做完的事情，然后在一个迭代内还做不完。
这取决于两件事：一个是事情本身的复杂性，另一个是迭代的大小。
晓南
半堂
现在大部分的流程设计上，不会去设计一个用户需要很长的流程都无法走到结果的功能，会在过程中做数据持久化，来记录用户行为的结果，比如加入购物车，展示详情页。其实有时候拆故事比较简单的就是看这个行为有没有被持久化，只要过程中会被持久化，一来说明这个故事可测，二来既然数据持久化了，说明对用户或客户有价值。
小A
对嘛~ 比如开始电商的例子，我需要查找商品、加购物车、选择地址、付款，虽然每个部分都可以做的很简单，但也有不少工作量了，还是比较想拆的。
半堂
查询商品可以拆，假设这是一个移动端的电商，搜索商品是一个单独的story没啥问题：填入文字搜索，给出搜索结果，页面的排序和分页，这一张卡差不多。
购物车的话，如果是一个0-1的项目，后台要有一个购物车的实体，前台的操作就进入到购物车，我不知道这张卡包不包括删改查，理论上其实增加到购物车，这一张卡工作量也不小了。
半堂
其实这就是一个持久化的案例：如果添加购物车直接进入的是订单页面，退出页面购物车里的商品需要重新添加，那购物车就不是一个业务实体，添加购物车也不能是一个story，得是产生订单才算；如果是淘宝那种可以添加，之后再统一下单，那购物车添加和下单就应该分开。
不知道我解释清楚没有。
非常清楚。
如果完成这一步有数据入库，其实就可拆，如果没有入库，说明整体是一件事，不可拆，拆了也没法单测。
晓南
半堂
对的。不过入库不是唯一标准，只要有持久化这个动作基本就是可拆的，比如有时候页面可以做浏览器缓存。
了解，所以数据持久化是判断可拆的因素之一。
我们现在敏捷交付上，多大的卡是大小合适的？
晓南
半堂
story的大小最好是在1人天~5人天之间，8人天基本是极限了。太大或太小都不行。
故事太大说明在敏捷实践中花在沟通上的时间太多，整体看团队效率就下降了。
太小也不好，story其实是一个最小的工作单元了，工作单元太小是会造成管理效率下降的，这不是敏捷希望达到的。
所以我们才说INVEST原则中的S不是Small，而是Size Properly。
只有大小合适，在敏捷实践中才更便于优先级排序和腾挪管理。
晓南
可测性考量：Testable
小A
看我们之前学过的例子，这个流程就拆的比较细了。
这个图就是比较复杂的流程了，这样拆是没问题的。每一个卡，比如预约登记、登记记录查询，虽然有依赖，但都是单独的事情，是可测的。没有预约，也可以查询登记记录。
但没有付款，是不能下单的，没法单独测。如果按步骤拆，测试最经济的做法是等都开发完一起测。
这里拆分的时候就考虑了INVEST原则中的Testable。
晓南
小A
对，这样拆下单这个事情确实是没有做完。只提交订单、不选择发货地址、不进入付款页面没啥意义。
我刚才陷入了大场景和小场景的漩涡。
对的，其实还是用户侧的独立价值考虑。
晓南
小A
这种场景下，怎么说服测试呢？我们很多团队就因为这样的部门墙，变成了小瀑布。
你要说服测试有独立验证的价值，来个拆分小技巧让QA服你。
可以这样描述拆分：
1. 完成下单流程
2. 商品高级搜索
3. 购物车添加删除逻辑
4. 付款方式的多方集成
这样写QA会明白：哦~这每个卡都有独立存在的意义，够复杂，够测阵子的。
晓南
小A
感觉确实是，测试好像特别重视场景，实际上测试的时候不也是一步一步测的？
是的，测试特别讲究端到端，也就是场景。一个测试用例的基本要素，就是要验证一个测试点，比如用户可以下单就是一个测试点，但是如果按步骤拆成故事，相当于让他单独验证搜索、加购物车、提订单，所以测试会觉得没意义。（虽然他测肯定也这么测，但每一步都不是这个用例里他想验证的东西）
可以把一个迭代想成一个产品，这个产品里，我先发什么，哪些可以独立交付（给测试验证），这样思考就好了。
晓南
小A
有道理。我最近就在梳理怎么说服我们的产品拆分需求，怎么说服我们的测试提前测试需求。跟你们讨论完之后更有信心了。谢谢晓南和半堂老师~
拆卡小结
故事拆分真有需求再拆，不要为了拆而拆。
要按端到端的使用场景来拆分，确保拆出的用户故事有独立的价值。
拆完后的每张卡，都需要符合用户故事的INVEST原则。
拆分时可考虑因素：业务价值、可测性、数据持久化、团队协作……
当需要拆分技术卡时，独立的用户价值体现在服务于系统内部程序调用，或外部集成。
故事的验收，确保交付用户价值是第一位的，不需要细到测试用例或用例的执行步骤。
团队协作时，不同角色的沟通可以试着站在对方的立场上思考问题，有助于达成一致。
本文中的拆分案例仅代表对话中三人的观点，具体项目中的需求拆分还请酌情考量。
圆小豆的美梦工场
于晓南
微信：yxn125
博客：qualityfocus.club