关键要点
- 敏捷团队面临一些共同的问题。
- 有一个实现 ATDD 的明智做法。
- 在敏捷团队中实现 ATDD 有明显的好处。
- ATDD 使团队和组织能够在 SDLC 中充分利用自动化。
- 实现 ATDD 需要团队协作。
本文为任何有兴趣在他们的团队和项目中实现 ATDD 的人提供了一个快速指南。它概述了遵循我介绍的敏捷方法的好处,此方法基于的是我在企业软件开发团队的第一手经验。
协作是敏捷方法的核心价值观之一。有一次,当我在做一个大型项目时,我注意到开发人员、测试人员和有业务头脑的人之间缺乏协作 ; 缺乏明确的需求 ; 频繁出现需求范围蔓延的情况 ; 对已完成的测试缺乏可见性 ; 以及在项目生命周期后期才发现缺陷。对我来说最重要的是,没有人对我们的自动化框架有任何想法,所以所有的自动化测试都是在开发了特性并准备好进行测试之后编写的。因为这些发现,我开始研究人们是如何处理这些问题的。结果,我发现验收测试驱动开发(ATDD) 是用来减轻许多问题的其中一种方法。它通常与行为驱动开发(BDD)、故事测试驱动开发(SDD) 和实例化需求(SBE) 同义。与其他敏捷方法相比,ATDD 的主要区别在于,它的重点是使开发人员、测试人员、业务人员、产品所有者和其他涉众作为一体进行协作,并对需要实现的内容有一个清晰的理解。
根据我自己的经验,我将分享我的想法,关于团队如何在自己的项目中实现ATDD。
背景
我在一家有创业精神的大公司工作,所以团队鼓励任何创新的想法和反馈。我们很快就建立了原型,以了解一个想法是否会使我们的产品更好,或者有助于实现公司的总体目标。我在一个25 人团队中领导测试人员,该团队由一个scrum master、一个技术主管和多个业务分析师、设计人员、开发人员和测试人员组成。由于创新文化的影响,团队内部经常一片混乱,包括在功能需求上的频繁变化,个人在筒仓环境中各自为战,团队士气一直很低落。这对我来说很重要,所以我自愿协助寻找这些疼痛点的解决方案,于是我找到了ATDD。
我所有和ATDD 的相关总结经验可以分为以下3 个步骤。
ATDD 实施周期
由 Raj Subramanian 绘制
步骤 1 - 训练和实验。
处理任务的方法有很多,特别是考虑一下,每个人可能来自于当前组织内外的不同敏捷团队,具有截然不同的个人工作经验。为了能够对团队和组织的目标有一个共享的、共同的理解,提供适当的培训就很重要了。关于 ATDD 的具体问题,它应该包括目标、目的、期望以及使用这种方法所产生的结果信息。在培训之后,要先开始一个小规模的实现,尝试不同的事情并接收迭代反馈,这很重要。
例如,在研究了 ATDD 之后,我向不同的涉众解释了为什么我们需要探索这种方法,以及会从中得到什么好处。我强调了几个可能的优点, 如增加团队协作、更好的澄清需求、在软件开发生命周期 (SDLC) 中尽早发现缺陷, 增加可见性和在 SDLC 早期就使用自动化,以及整个团队参与提出明确的验收标准。
在与利益相关者的讨论中,我强调这需要一些实验,而如果不尝试,我们永远无法知道它的好处。经过长时间的讨论,我们决定将原来的 25 人分成 2 个小组:团队 A 由 12 人组成,它将实现 ATDD。团队 B 是剩下的 13 人,他们将继续保持现在的做法。
我为团队 A 计划了一个为期 2 天的培训研讨会,通过了解 ATDD,确定在我们的项目中哪些概念是合理的,以及我们如何在整个过程中利用自动化。我在训练中结合了理论和实践。下面是一些练习:
- 如何编写 Gherkin 陈述—给定 / 当 / 那么 (Given/When/Then:GWT)
- 一个好的用户故事的关键属性是什么?
- 演示了我们的自动化框架,包括它是如何工作的,以及它是如何构造的。还有关于如何编写简单的自动化测试代码作为团队的练习。在研讨会之前,一个团队成员和我修改了我们的自动化框架,以与 ATDD 方法一致。我们在我们的自动化框架中使用了带有 Java 和 Appium 的插件。
步骤2 - 增加可见性。
当一个项目在多个sprint 中运行时,很容易忽略需要遵循的不同流程。因此,关键是要让整个团队都能看到目标、目的和期望。
当我们开始使用ATDD 时,我只是简单地写下每一个需要在白板上执行的日常流程,将它放置在我们团队日常召开站立会的地方。在每个用户的故事中,我添加了一个待办事项清单,都完成之后才能认为这个故事完全完成了。这样,对于需要遵循的ATDD 过程就没有歧义了。其中一个清单项目是启动会议,在此期间,开发人员、测试人员和业务人员作为一个团队讨论了需求,确定哪些需求可以自动化,并以GWT 格式概述了这个故事的验收标准。另一个检查表项是QA-Dev(质保–开发) 接力,开发人员通过快速演示或讨论向测试人员展示需求是如何完成的,以及哪些单元测试是作为故事的一部分编写的。通过这种接力,测试人员了解了哪些区域没有被单元测试覆盖,并且对实现的特性有了更好的理解,从而会有更好的测试覆盖率。清单上的项目有时是显而易见的,但清晰说明有利无害。其中包括,确保所有与故事相关的缺陷已关闭; 另一个是业务代表在观看演示后的最终认可,确保这些功能是满足了先前设定的要求和期望。
我们还开始拥有了一名“过程鹰”。这是一个单独的团队成员; 它可以是scrum 管理员、项目经理或者任何可以确保团队遵循这个过程的人。在我的这个案例中,它是团队中的另一个高级测试人员; 他和我经常提醒每个人在所有的会议上遵循ATDD 流程,包括站立会、计划会、回顾会和其他团队会议。
步骤3- 迭代总结和反馈。
在实现任何敏捷方法(包括ATDD) 时,持续反馈循环是至关重要的。与整个团队进行每周或两周的回顾会议是了解过程中哪些部分实际上会有利于团队,哪些部分可能需要修改。正如我们已经知道的,一些对团队没有帮助的事情会浪费时间和精力。就像《吃掉那只青蛙》的作者布莱恩·崔西所说的:在更短的时间内,停止拖延和做更多事情的好方法是:“最浪费时间的一种做法就是做一些根本就不需要做的事情。”
在当今信息技术时代,组织不能浪费时间和精力在无效的方法上; 相反,我们需要精简和有效的过程。这与有效学习的精益创业原则有关:构建、度量、学习周期。
考虑到这一点,我开始每星期四与团队A 进行30 分钟的会议,检查团队是如何执行的新流程。用这种办法可以很好地根据团队的反应判断需要做出哪些改变。这种会议是在两周迭代结束后的回顾会议上单独举行的。这种方法带来了团队的持续反馈,使我们能够做出即时有效的改变。反馈并不仅仅来自每周的流程检查; 每日站立会议也被证明是一个宝贵的信息来源。单体团队成员补充讨论发现的与此过程相关的危险信号,我们能够在它们影响团队其他成员之前立即解决这些问题。
总结
由于采用了ATDD 实现周期,团队A 开始在团队士气、协作和需求方面看到了相当大的差异。
团队士气
每个人都开始以团队的形式工作,感到自己被赋予了权力。每个人都能从头到尾掌握一个故事。他/ 她确保掌握了这个故事开展开发和测试工作所需的所有必要信息。该团队成员也确保了所有与故事相关的工作得以完成。最后,这个人负责在sprint 结束时向所有利益相关者展示这个故事。这种能够自主掌控的感觉极大地提升了团队的士气。
协作
启动会将业务人员、开发人员和测试人员聚集在一起,以开发对用户故事的共同理解。在质保与开发的对接在把构建包发到测试环境之前就完成了,帮助开发人员和测试人员明白测试应作为故事的一部分来完成,并对实现的特性有了更好的理解。因为整个团队都拥有了自动化的所有权,而不仅仅是测试人员,所以这方面的自动化的可视性也提高了。最后,在规划会上,整个团队一起讨论这个故事,从而产生更多的想法、问题和讨论。更多的协作也带来了更多的学习,团队决定进行点对点的培训加强互相学习,测试人员开始进行结对的探索性测试,并且由不同的团队成员组织了午餐交流会,讨论关于技术的各种主题。所有这些都带来了团队更好的协作。
需求
我们以前的流程存在一个主要问题,那就是需求和范围频繁地变化。使用ATDD 方法,一旦开发人员开始编写一个故事,需求就会被锁定。任何改变都必须与其他即将到来的故事放在一起,并添加到即将到来的迭代中。这减少了开发人员和测试人员的工作量,并防止了涉众对已完成的特性抱有不切实际的期望。
在看到上述所有改进后,B 团队也开始实施ATDD。因此,在常规的实验和反馈之后,最初的整个团队都使用了这种方法。
结论
我建议使用ATDD 的方法,它与“左移范式”是一致的,也就是在SDLC 中所说的开发和测试尽早介入。当我们开始在SDLC 开始编写自动化测试时,它为自动化带来了更多的可视性,这反过来又增加了团队内部的协作。
记住,ATDD 不是一个“放之四海而皆准”的解决方案。在我的项目中,敏捷方法是最有意义的,但是在团队中有很多其他的方法来改进流程。我使用这种方法是因为关注更好的验收测试,但更重要的是它强调协作。协作部分是这种方法的一个组成部分,我认为它是最有价值的。
关于作者
Raj Subramanian曾是一名开发人员,他后来激情满满地转向测试。Raj 目前是 Testim.io 的一名开发者传道师,他们为 Netapp、Swisscom、Wix 和 Autodesk 等企业提供稳定、自修复的基于 ai 的测试自动化。他还为各种客户提供移动培训和咨询服务。他通过在会议上发言、撰写文章、写博客、在 youtube 上发布视频以及直接参与各种与测试相关的活动,对测试社区做出了积极的贡献。他目前居住在芝加哥,可以通过 raj@testim.io 联系他。这是他的网站和推特账号。他有关测试、领导力和生产力的视频可以在这里找到。
评论