扫码阅读
手机扫码阅读

聊聊用户故事与测试启发

48 2024-01-31

这是鼎叔的第六十六篇原创文章。行业大牛和刚毕业的小白,都可以进来聊聊。

用户故事的概念于1998年被正式提出,在2001年开始逐步成熟。目前,市面上有关讲解用户故事方法的著作不少,在Scrum流程中配合使用,效果显著。我们先回顾一下用户故事最核心的知识内容。

用户故事核心知识

用户故事用来描述对用户有价值的特性或功能,相对于传统的需求规格说明书,它用简化的形式促进团队交流,降低修改的成本,能灵活的调整以响应变化。通过用户故事的验收标准驱动,让所有敏捷团队成员和干系人,对最终目标达成共识。

用户故事的描述格式通常为: As (特定的用户),I want(具体场景下实现的某个功能),So that(获得某种目的/价值)

用户故事要符合3C原则Card(卡片,上面是一句话概述,能让成员快速识别),Conversation(通过产品和技术的直接对话,了解背后的需求细节),Confirmation(验收条件- AC:Acceptance Criteria,确保清晰无歧义)。通常我们可以在一张Card的正面写上用户故事的描述,背面写上测试如何验收,因为空间有限,验收描述必须非常简洁。

用户故事也要符合INVEST原则Independent(彼此独立,相互间松散耦合,尽量减少依赖),Negotiable(用户故事可以协商,不是一成不变的,需要PO和成员以及客户的坦诚交流), Valuable (能体现对客户的明确价值),Estimable(能够被开发团队合理估算的), Size Appropriately(大小合适,能够在迭代中完成,如果偏大需要拆解用户故事),Testable(故事有明确无歧义的验收条件,能被明确客观的测试用例验证)。

用户故事鼓励推迟细节考虑,因此在进行讨论时不要过早涉及用户界面,也不用给用户故事卡片编号。

推荐学习书目:Mike Cohn的《用户故事与敏捷方法》。


测试启发

一、所有用户故事的验收标准是否明确,团队是否对验收测试用例达成一致?

验收标准通常写成GWT的格式:

Given(什么场景或条件下,如在首页新闻的搜索框)

When(采取了什么行动,如输入了品牌关键词)

Then(得到了什么结果,如输出了该品牌直接相关的热门新闻,可以浏览点击)

示例:

验收标准可以避免团队成员对需求理解的偏差,帮助测试人员快速掌握测试范围。但验收标准不是验收测试,验收标准定义了用户故事完成的标准,验收测试要基于验收标准,但是验证的具体场景更广,建议每个用户故事验收的测试用例不超过6个(通常是1-6个之间)。

特性团队对具体的验收测试用例达成一致,最大程度上保障开发人员能更好地进行验收测试驱动开发,交付的初版质量也会更高,更容易一次性通过验收。甚至在整个迭代的活动中,验收测试用例都可以作为团队统一的沟通语言,降低不同角色对需求理解的不一致性。

注意:验收测试用例不等于完整的测试设计用例,它通常仅仅只是完整用例集的子集,优先级很高。

二、所有用户故事是否具备可测性。

我们是否能明确测试它们的工具方法,判断测试通过的指标,如有疑问,需要在评审中和文档中获得澄清。

特别小心需求描述中不清晰的定义,比如性能要增加50%(具体什么场景,什么指标?),安全性要提升(具体哪一项产品规格的安全性,要通过什么工具的安全检查?)。

三、用户故事估算排期,必须考虑测试完成任务的耗时。

用户故事在迭代中达到“完成”的定义,通常是包含“相应测试任务完成”的。所以在估算时要纳入相应的开发自测和专业测试时间。

针对被拆解的用户故事,也需要我们在本迭代中对测试工作量做好评估。故事被拆解后,有利于测试工作量的评估更加精准。从故事验收及回归测试的经验来看,开发工作量在2-3人天的用户故事,其测试验收的效率是最高的,可以在收到版本的当天完成用例集测试反馈,便于开发快速修复问题。

如果评估出来的测试任务人手不足,需要采取一定的补救措施,如安排开发人员支持测试、降低非核心功能用例覆盖等。

针对客户端版本和重要服务的重构版本,正式发布的准备成本比较高,风险也比较高。我们通常会预留一个迭代做发布前的准备,包含缺陷修复和集中的系统测试投入,如兼容测试、回归测试和核心指标性能测试等。这个迭代就建议尽量不安排新功能的开发和测试了。

四、产品经理的需求文档是否支撑了各个用户故事需要的三要素信息?尤其是否说清楚了-对什么用户提供了什么价值?

我希望推动产品经理在需求文档中给出明确的用户价值描述,原先觉得这个要求是不是略高,但结合用户故事的核心知识,我认为这是非常有必要的基础要求,因为需求就是由一系列用户故事组成。既然能说清楚其单个故事的价值是什么,当然能进一步度量最终交付的效果并改进。

五、技术需求也应该拆解为技术故事。故事作为团队展开工作的基本单元,它不仅仅是功能描述,还可以是性能,安全,技术债务改造描述。举例如下:

对于通用型的非功能需求,即适用于所有用户故事的质量标准,如性能指标不低于多少,合规不违反,不能有资金损失等,可以用相应的约束卡片来书写,让团队在迭代活动中能关注到,但约束卡片的故事点是0。

测试技术故事也要能识别,合理排期。

测试技术故事通常是重要不紧急的事项,而且不太好通过用户视角来描述其价值和验收标准,因此很容易被PO和团队忽略。测试人员需要主动澄清这个故事对特性团队的长期收益。越早还债,收益越大。

比如,基本接口的自动化测试覆盖,引入更好的性能测试工具和漏洞扫描工具,给看板增加质量告警等。测试技术故事也需要每个迭代能看到具体的成果,避免团队对未来的故事排期失去耐心。

有同学可能会问,有些技术需求很难估算到底需要多少时间完成,怎么办?那我们就用探针法拆解它:当前这个迭代只安排该需求的调研分析(我们称之为探针需求),输出关键结论报告,例如技术背景、行业案例、建议的实现方案及其风险等。下个迭代再根据调研结论进行一定开发工作量的技术故事实现。

六 用户故事描述中的角色(As Who),团队可以为角色建模,从而避免用户故事的角色遗漏。

通常建模的流程是:集体脑爆出角色集合,用人物卡片的方式展现。在根据使用频率、使用水平、使用目的来区分典型人物,同时保留一定的极端人物(有利于发现更多体验风险)。根据最后精选出的代表人物创造虚拟身份信息和形象,这样可以提升生动性,让成员们有代入感。

七、鼓励客户参与用户故事及验收条件的编写,客户可以用更商业化的语言来描述。

技术人员很多时候是无法直接接触到用户的,那如何获取有用的需求信息呢?我们可以和下面这些角色合作获取信息,但是要小心不同角色出发点的局限性。

和客户销售人员合作。要注意销售人员会更关注收入和利润,对用户价值可能会短视。

和领域专家或分析师合作。专家角色会带来很多洞见,但也可能不接地气,忽视用户真实细节。

组建用户代表团。需要注意代表团成员的差异性,比如,是否兼顾收费和免费用户,是否充分包含了不同背景的用户,是否熟悉竞品等。

八、用户故事不是什么。

用户故事不是国际软件需求规范(IEEE830),用户故事基于敏捷会严格控制成本。IEEE830侧重于需求清单,而不是用户目标,每个需求成本是不可见的。

用户故事也不是记录系统需求的用例,用户故事比系统用例小,后者往往是完整需求中的多个场景的大而全描述。用户故事寿命短,不包括界面细节,更关注商业目标。用户故事更能传播隐形知识,但是在大型团队还需要把重要交流记录下来。

缺陷集合也可以当成一个用户故事。

九、用户故事和XP/Scrum的关系。

用户故事起源于XP实践,其方法体系非常契合XP的价值观。

用户故事方法和Scrum流程深度融合。比如我们在scrum站会中会同步上一天的故事进展。高层管理者可以参加站会,但是不能提问打乱。

原文链接: http://mp.weixin.qq.com/s?__biz=MzkzMzI3NDYzNw==&mid=2247484289&idx=1&sn=8c131773f2990aede36673bcfaa02151&chksm=c24fb6e3f5383ff5f6e00a54dab37119070abdce17702603cd5e00b46bab5ea983e637f69fde#rd

《无测试组织-测试团队的敏捷转型》主题探讨。从打造测试的组织敏捷,到敏捷测试技术的丰富实践,从一线团队的视角来聊聊我们是怎么做的。面向未来,拥抱敏捷原则,走向高效能组织。

81 篇文章
浏览 5425
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设 白皮书上线