测试在敏捷开发中的特别实践V2.0-敏捷测试

Posted 大敏捷

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了测试在敏捷开发中的特别实践V2.0-敏捷测试相关的知识,希望对你有一定的参考价值。

引言:2009年3月,笔者阅读了ThoughtWorks覃其慧的《我和敏捷团队的五个约定》(现网址:https://www.infoq.cn/article/thoughtworks-practice-parti/#anch40464 ,搜索标题也可以获得 ),认为没有体现“ 敏捷团队的特点”,因而写下了《 独立测试团队在 敏捷开发中的几个特别实践》一文(见https://blog.csdn.net/zhangmike/article/details/78653154 ,也可点击下方的阅读原文)。时间过去了11年,回顾此文,发现对于当前实践仍然适用,因此改写升级到2.0。
标题上去掉了“独立测试团队”字样,因为这些敏捷测试实践没有一定要求由独立测试团队来完成,无论测试人员融入敏捷小团队,还是保持测试团队独立,如下实践都是可以采用的。


01

测试保护开发

通过快速的自动化测试跟进开发,确保新变化符合预期,也确保新变化不破坏已经获得的成果。

典型步骤如下:

1,开发人员根据需求,编写代码,实现界面和接口,无论是否采用TDD,ATDD,BDD。

2,几乎同步,或者略有滞后,测试人员编写自动化测试,首选是接口自动化测试,其次是界面自动化测试。也有做法是测试人员和开发人员一起维护自动化测试,这也是符合测试保护开发的特征。

3,一般保证,新实现代码出来后的第2天,相关的自动化测试得到并且运行通过。


这里紧密相关的实践有TDD、ATDD和BDD,这些都是超短反馈。如果测试人员先写测试再让开发人员实现,这样换人进行,是浪费时间。因此测试人员是难以参与到TDD、ATDD和BDD当中,反过来说,测试人员如果具备ATDD能力,那就不再是测试人员,而是开发人员了。而作为测试人员有测试人员的独立视角,就算开发人员通过诸如BDD已经提供了自动化测试集,测试人员仍然值得按测试视角去开发维护自动化测试。


02


测试人员深入参与敏捷团队的各项活动

  • 子实践1:参加团队相关会议,如果是SCRUM,参加SCRUM所有要求的会议。注意尤其要参加需求梳理-澄清会议,避免让诸如PO或者产品经理讲两遍。

  • 子实践2:可以阅读和修改最大范围的配置项(比如文档,代码,工作项)

  • 子实践3:一起工作,比如把位子搬到开发人员旁边,如果同时参加多个项目,选择一个较近距离的位子。

说明:这个实践本身的宗旨与传统做法并无根本区别,这里的区别在于程度,甚至有做法把测试人员放入到敏捷团队之内,不再有独立运作的测试团队。


03

高频定期运行自动化测试

自动化测试发挥最大作用的途径就是运行得越高频越好,传统理论上认为自动化测试用例至少运行5次,才能覆盖开发自动化测试的工作量成本。因此在敏捷开发下更加值得高频运行。
  • 子实践1:维护一套自动化测试环境,可以自动获得最新的自动化测试用例集和构建成果,并且运行自动化测试,至少每天1次。

  • 子实践2:测试结果自动发布到合适的地方,得到跟踪管理,确保所发现的问题得到及时解决。


04

更多场景化测试用例

关注于局部功能的测试用例在敏捷开发中往往已经被自动化实现了。因此值得设计更多黑盒手工场景化测试用例。选择一些典型场景化测试用例开发为自动化测试用例也是可以的,但是此类测试用例的自动化开发所需工作量较大,要看测试团队的投入和质量目标安排,如果有象早年微软那样的测试开发工程师,那么当然可以安排。
一般而言,从经济角度出发,黑盒手工场景化测试用例是发现潜在缺陷的有效且经济的手段。本实践在传统测试中也有,这里要强调的特别之处是可以考虑手工测试尽量多用场景化测试,大幅减少针对单一功能或局部功能的测试用例。

05

开展探索性测试

在2009年3月本文最初版本里面,在场景化测试一节,有如下文字:如果存在丰富经验的测试人员,随机场景测试也是值得更多采用的。当时探索性测试还没有广泛流传,采用了“随机场景测试”说法,其基本特征是没有提前设计的测试用例,由经验丰富的测试人员进行错误发现尝试,当然“随机”这词在这里不是一个恰当的词汇,会让人关联到猩猩随便敲击键盘来测试。
对照到现在,以上测试其实就是探索性测试,英文是Exploratory Testing。探索 性测试经过多年发展,已经得到了广泛的实践。其中的“自由式探索性测试”与随机场景测试极为接近。另外还有基于场景的探索性测试,基于策略的探索 测试,基于反馈的探索 测试。


06

小结

从以上实践可以看到,测试人员所要掌握的技能有自动化测试、场景化测试,最好也要常握每日构建和自动测试报告。
上述的实践是否有效、是否高效,可以观察如下几点:
  • 1,达到发布条件所需的测试是否及时地正常完成(没有过多加班)?

  • 2,发布后缺陷数量是否减少或者始终保持在0缺陷交付?

  • 3,获得快速发布的能力,工期或者时效是否缩短?


07

后记

最新2020年第14次敏捷年度状态报告刚刚发布,里面有个实践调查项是“Single Team(Integrated DEV and TEST)”,结果是51%, 去年第13次调查里面,这个数字是54%。经过了这么多年,这个结果恰恰反映了这方面的真实情况,独立测试团队在敏捷开发当中仍然有一席之地,而且几乎有半壁江山。本文V1.0时限定在了独立测试团队,最新2.0不再限定独立测试团队,但仍然适用于独立测试团队,当然也覆盖了融合开发测试的单一团队里面的测试。详见 ,里面剖析了独立测试团队和融合团队。


----全文完,以下欣奔敏捷星球介绍----


笔者自2018年12月开启欣奔敏捷星球,到现在有500多天,在这里记录敏捷教练一线实战情况,记录最真实的具体实例,积累达600多条内容,覆盖了IT敏捷+业务敏捷+DevOps的诸多细节。

本星球展示了更快交付的敏捷方法:在百人级规模,采用需求流模式,让创意从选择启动到上线只需要一个月时间,快速响应市场变化,更快捕捉市场机会。欢迎朋友们来看看:)

欣奔敏捷星球记录了从IT到业务的敏捷实践以及DevOps建设实战情况,提供最鲜活的真实案例。也有成员基于实践情况的提问和解答,星主提供远程教练咨询服务。目前积累内容包括全套敏捷项目管理教材,ScrumBan欣奔版,需求流模式,DevOps具体解决方案。

最新优惠见,截止6月30日12:00。


以上是关于测试在敏捷开发中的特别实践V2.0-敏捷测试的主要内容,如果未能解决你的问题,请参考以下文章

独立测试团队在敏捷开发中的几个特别实践

敏捷测试模式之Scrum及其实践

TiD系列线上沙龙 | 探索式测试在敏捷开发中的落地实践

CMMI V2.0丨如何通过CMMI真正在企业中的实施规模化敏捷开发

敏捷测试模式之Scrum及其实践

[案例]敏捷开发最佳测试实践经验分享