0%

请收下这波 BDD 安利

首先,听我讲一个关于王铁锤的故事。

版本一

新的Sprint开始了,产品经理/BA 王铁锤召集全组开会💬

**[王铁锤]**:这个Sprint咱们有个新需求,在网站上做一个用户注册登录功能。现在我来给大家说一下UserStory和AC都有啥。(PS:不知道UserStory, AC(Acceptance Criteria)和Sprint是啥意思的,你需要看看敏捷术语)
20分钟后。。。
**[王铁锤]**:大家有什么问题吗?
**[众组员]**:没问题了👌
**[王铁锤]**:好,散会。
2天后。。。
**[测试刘翠花]**:咦,李狗蛋,你做的登录页面密码输入框怎么没掩码?密码错了也没个提示?!还有你赵二毛,你做的注册功能还能注册两个一样的用户名?密码长度格式也没限制?!这不符合常理吧,这界面也太丑了点😂!
**[程序员李狗蛋]**:呀,我咋把掩码忘了,错误提示没说要做呀,别着急,我再看看UserStory是咋说的,咦,上边没写😓?!
**[程序员赵二毛]**:唉,这种情况还真没想过,得处理一下,UserStory里也没说这种情况咋整啊,还有密码长度格式上边也没说规则。
**[刘翠花]**:这问题也太多了,当时开会咋就没想到这些呢😕,直接按老王给的UserStory做了。不行,我们得去找他问问。
3分钟后。。。
**[王铁锤]**:呀,这些东西我创建UserStory的时候也没想到。嗯,我得去完善完善。界面显示问题我去找设计师看看。你们等一下。
两周过去了。。。
**[王铁锤]**:怎么样,这个功能做好了吗?客户那边等着呢
**[众组员]**:不行啊老大,我们还有一堆需求和问题没搞清楚,想跟你确认呢
**[王铁锤]**:这咋行呢,原计划这周就得上线呀, 唉,都有啥问题,我再看看吧
一个月后,经过王铁锤和众组员的数次沟通确认,功能终于做好了,比原计划推迟两周上线。。。
**[刘翠花]**:唉,上线后肯定又有一堆问题,到时候背锅的就只有我了


版本二

新的Sprint开始了,产品经理/BA 王铁锤召集全组开会。

**[王铁锤]**:下个Sprint咱们有个新需求,在网站上做一个用户注册登录功能。首先讲一下我和客户拟好的用户流程和场景。
5分钟过去了。。。
**[王铁锤]**:相信大家对这个功能已经有了初步的了解,一定也有一些想法。所以在拆分具体的UserStory之前,我想先组织大家玩个小游戏。
**[李狗蛋]**:玩游戏?这么嗨的吗😏,我喜欢。怎么玩啊?
**[王铁锤]**:假设你是用户,列出所有你能想象到的关于注册登录的用户行为场景。并写下这些场景中你希望的系统行为😎。包括但不限于我刚才讲到的场景哦,大家开始吧~
10分钟后。。。
**[王铁锤]**:我看大家都写好了,下面咱们一条一条过,拼凑出一个正常的用户操作流程,然后把相似的场景提取出来,讨论一下哪种方案更好。首先让赵二毛给大家讲下他的场景:

  • Step1: 进入系统首页,跳出登录注册弹窗.
  • Step2: 点击注册按钮进去注册页面。
  • Step3: 填写所有字段并点击注册。
  • Step4: 弹出注册成功页面,3秒后返回系统首页,用户状态为已登录。

[赵二毛]**:对,这里我写的是一个注册成功的场景,当然里面还有很多小点需要确认。比如说Step1、Step2、Step4中登录注册页面,以及注册成功页面的前端显示,需要设计稿。还有Step3中的字段需要在设计稿中体现,还需要一些字段的长度格式以及必填规则。Step4中注册成功后有一个3秒的返回延迟,还有返回首页后的登录状态,都是细节问题。
**[刘翠花]**:哇塞,二毛,平时看你写代码也没这么细心啊,想不到你还考虑的这么细多,真棒!
**[李狗蛋]**:二毛写的确实好,基本上涵盖了整个注册流程,跟我写的有很多相似之处。下面我来说说我们的不同点,其他人也可以提出自己的看法。
30分钟后。。。
**[王铁锤]**:好,大家已经讨论完了。对很多细节和功能已经达成了共识。当然还有一些问题我需要跟客户沟通,寻求他们的意见。很感谢大家提出的思路,很多场景我之前都没有考虑到。比如
刘翠花**提到的密码输入次数限制问题,狗蛋和二毛也从代码方面提供了自己的想法。我受益良多👏。对于我们在功能方面达成的共识,还有一些需要确认的问题,已经拍照留存,我之后会整理好给大家分享,散会~
2天后。。。
**[王铁锤]**:前两天大家讨论了下注册登录模块的具体流程,其中包含要实现的功能和细节。设计图和一些遗留的问题我都确认过了,并且写好了UserStory还有AC。接下来大家对比上次会议结果一起看一下。确认大家的理解一致,没有遗漏的点。
20分钟后。。。
**[王铁锤]**:大家有什么问题吗,我有没有漏掉什么点?
**[众组员]**:没问题了👌
**[王铁锤]**:好,看来都清楚了,散会~
一个月后,由于大家对登录注册功能的实现细节已经达成了一致。不仅比原计划提前一周完成,还提出了更多可以改进的功能,得到了客户的赞赏和肯定。


啥是BDD

定义

相信通过上边的例子,大家心里应该知道BDD是啥意思了。

BDD行为驱动开发(Behaviour-Driven Development)
是一种软件开发流程,这里’行为’指用户行为。’开发’指整个开发团队。顾名思义,BDD要求开发团队严格按照具体的、符合现实情况的用户行为进行开发,不断减小项目组成员在业务与技术两方面的理解差异,使团队对软件应该有的行为达成一致。

BDD与敏捷

我们知道,敏捷是现在最流行的软件开发框架,可以快速、稳定的进行软件开发。而BDD相当于是这个框架一个强有力的插件,能够帮助我们更高效地实现敏捷开发的目标。

就像上边故事的两个版本,都实行了敏捷实践。但版本二中的团队同时实行了BDD,因此产生了更好的结果。

类似定义对比

  • TDD: 测试驱动开发,敏捷开发的特点之一,概念上与BDD同级。但在实行过程中,团队必须在保证TDD的基础上施行BDD,否则只能是捡了芝麻丢了西瓜。
  • FDD: 功能驱动开发,是一种敏捷开发流程,概念上在BDD上级。

为什么要BDD

没有BDD以前(版本一)

技术人员(程序员/测试)对整个用户流程不熟悉,只分散开发具体的功能,没有产生业务价值的连通性,容易对需求理解产生歧义。
业务人员(产品经理/BA)对功能具体实现流程不熟悉,影响下一步需求的提出和产品交付。
两种角色对用户流程和业务需求的理解不一致,容易导致产品返工,而且需要浪费更多时间相互沟通。

有了BDD以后(版本二)

项目组成员对用户流程、开发顺序以及实现细节有一致的理解,可以更快速高效的交付产品。


怎么做BDD

要做好BDD,需要三步实践。

探索:做什么

第一步,开个会大家商量一下要做啥,执行者是整个团队。

还记得上边王铁锤让大家玩的游戏吗?其实这个游戏有个洋气的名字,叫做:Discovery Workshops。不像之前王铁锤直接拆分好UserStory告诉大家,DiscoveryWorkshops的关键在于让大家聚焦真实、具体的用户场景,一起决定业务规则和验收标准。动员大家去发现、定义系统该怎么工作。这么做的好处有:

  • 把团队不同角色对功能的理解误差暴露出来
  • BA/产品经理可以确认开发团队完全理解业务规则和细节
  • 帮助BA/产品经理更好的确定UserStory的粒度
  • 有了测试人员的介入,可以帮助预防一些bug的产生,而不是在产品开发完后再去找同样的bug。

要做好这个Workshops,有几点很重要:

  1. 在功能开发前的一两个Sprint进行。
  2. 从用户角度出发,关注具体、真实的业务场景。
  3. 总结大家对业务细节的不同看法和问题,暂时不能解答的要确认后再通知大家。

记录:怎么做

第二步,用程式化的文档把讨论结果记录下来,执行者一般为BA/产品经理。

在敏捷里,其实就是把讨论结果拆分成UserStory,并把验收标准写在UserStory中。然后再组织大家开个会,确认一下有没有遗漏的问题。这样做的好处有:

  • 提供一种快速的方法,再次确认大家的理解一致。
  • 对UserStory的粒度和验收标准得到更多的反馈。

检验:做了啥

第三步,根据拆分好的UserStory和验收标准,把不同用户场景编写成自动化测试,执行者一般为测试人员。

其实对于测试人员而言,这种是理想情况,因为在实际开发过程中,可能没有足够的时间来提前写好自动化测试。但最好还是在开发结束之前写好,这样做的好处有:

帮助团队跟踪功能完成度

好的自动化测试应该涵盖主要业务流程和场景。所以在开发工作完成前,失败的测试可以发现bug,也可以时刻提醒团队有哪些功能还没有开发完成。就像TDD,可以帮助开发在class,method层面发现问题。

减少测试工作量

像所有自动化测试的优点一样,它可以大大减少手工测试的工作量,后期还可以用来做回归测试。因此测试人员会有更多时间做更有价值的事情,比如关注一些不能自动化的功能、探索性测试、准备下一个功能用户场景的自动化等等。

系统功能维护和查询

好的自动化测试也应该像一份业务文档。有时候我们忘记了之前某些功能的业务规则是什么,就可以通过查询关于此功能的自动化测试找到答案。或者团队需要对某个功能进行维护或重构,也可以查看自动化测试,看看它现在是怎么工作的,与它相关的功能还有哪些,以确保不会影响别的功能。


对BDD的常见误解

不需要做Discovery Workshops

如果没有一个大家一起探索功能的过程, 那就不叫BDD了。就像故事的版本一,所有的User Story都由一个人(BA/产品经理)发现并编写,这就违背了BDD的灵魂:共享理解。

三步实践的顺序可以调换

如果没做Discovery Workshops,那直接拆分UserStory就是在浪费时间。如果没有拆分好UserStory,确认好验收标准,也就不能编写自动化测试了。所以,这三部实践必须按顺序做,否则不会达到我们想要的结果。

代码写完后再写自动化测试

其实现在大多数情况,都是等代码写完之后再进行自动化,这当然很合理。但这样也就不是BDD了。

参考文章

打个赏嘛小主~