用户您好!请先登录!

敏捷测试那点事

敏捷测试那点事

什么是敏捷软件测试

敏捷测试的定义

Wikipedia对敏捷测试的定义:Agile testing is a software testing practice that follows the principles of agile software development.[1]

译文:敏捷测试是一种遵循敏捷软件开发原则的软件测试实践。这是通过一种敏捷的做事方法,可以让团队协作更紧密、工作效率更高,确保以可持续的速度频繁地交付客户所期望的业务价值。

敏捷测试与传统测试的区别

我对敏捷软件测试的理解与实践

传统模式是把软件开发分为软件需求、软件开发(设计&编码)、软件测试、软件发布等阶段,一般利用里程碑的方式对各阶段进行明确定义。软件测试是研发过程中的一个阶段,而且一般都属于项目的最后阶段;测试团队都是立场比较明确,与团队之间的沟通以正式为主;测试以需求为依据,要求有需求规格,自动化测试不作为要求;测试计划做得比较详细,对测试活动都会做好周密的安排;需求方确定需求后,中间环节参与较少。

在敏捷模式里,相对传统模式,软件测试不再是一个独立的阶段,测试是融入在软件开发过程中的一个组成部分,发生在每一次迭代中,也包含所有类型的测试,如单元测试、集成测试、系统测试、验收测试等。测试人员与开发人员工作更紧密,非正式的直接沟通成为了一种常态;测试以最终用户为准,辅以用户场景或用户故事作为测试的依据;测试追求快速高效,自动化测试在测试中扮演了及其重要的角色,敏捷测试人员辅以探索性测试跟踪核心业务场景;敏捷测试拥抱变化,测试计划比较灵活,按业务价值交付顺序执行;需求方需求定义后,参与每一次产品演示,确认每一次迭代产物,全程参与项目。(说穿了,敏捷测试要求测试参与全过程并始终以用户视角确保项目需求

典型的敏捷软件开发过程

我对敏捷软件测试的理解与实践

在敏捷的软件开发过程中,敏捷测试人员利用他们的专业知识从客户那获取需求所包含的业务行为,与开发团队协作,将这些行为转化为指导编码的可执行规范。

敏捷测试人员参与用户故事拆分,遵循比尔·维克(Bill Wake)的INVEST原则,即一个合适的用户故事应该是独立的(Independent)、有价值的(Valuable)、可讨论的(Negotiable)、小的(Small)、可估算的(Estimable)和可测试的(Testable)。[2]

测试人员参加需求说明会和计划会:产品经理给项目人员串讲用户故事,在这个过程中项目人员提出自己的建议和想法,并充分讨论。需求讨论清楚后,大家用敏捷牌估算工作量

参与每日站会:开发过程中每天早上有一个大约15分钟的每日站会,告知各自完成的工作、遇到的问题及接下来的工作

测试人员组织产品演示会:对每次迭代的产物提交评审,向需求方进行演示,对需求进行确认

参与每次迭代复盘会议:对整个迭代过程进行总结,并举行评优及奖励

敏捷软件测试的核心价值

为什么需要敏捷测试?因为有价值,那么敏捷测试能给我们带来什么价值呢?

缩短价值交付周期

我对敏捷软件测试的理解与实践

开发团队通过提供最小化可用产品获取用户反馈,并在这个最小化可行产品上持续快速迭代,直到一个相对稳定的阶段产品。在此过程中,敏捷测试人员快速验证团队的目标,快速试错。

降低软件质量风险

我对敏捷软件测试的理解与实践

敏捷测试要求测试人员尽早进入测试,与开发人员形成统一战线,尽早发现系统缺陷及其它问题,避免大量问题在项目后期才发现,形成质量风险不可控的结果。

启用日构建,通过BVT进行持续测试,让每天的迭代代码都能得到验证。

提高团队质量意识

我对敏捷软件测试的理解与实践

敏捷测试人员以专业的能力,引导项目全体成员开展测试,编写自动化测试用例,关注自动化测试执行结果,以稳定的每次编译及测试均未发现缺陷为目标。

节省项目研发成本

我对敏捷软件测试的理解与实践

敏捷开发偏向项目型的组织架构,测试人员与产品经理、程序经理、需求人员、开发人员等构成一个团队,采用扁平化的方式进行管理,构建一种和谐的工作氛围,共同为交付价值而努力。

加速个人能力提升

我对敏捷软件测试的理解与实践

在一个敏捷迭代周期里,一般团队规模7~8人,敏捷测试人员至少2~3人,测试工作不在是一个萝卜一个坑,每个人承担的事情种类较多,要求的知识面更广泛,个人技术栈会越来越丰满,独挡一面的能力更强。

敏捷软件测试的经验分享

经过普元多年敏捷测试的项目实施,要支持产品的快速迭代,达到敏捷测试的预期效果,我们重点在以下几个方面开展了工作。

组织文化的改变

我对敏捷软件测试的理解与实践

公司研发采用扁平化的管理模式,在敏捷的组织文化中,相比于流程,敏捷更关注人,所以敏捷测试组织是应该是以人为导向、自组织、协作式的一种文化氛围。

作为领导,工作中与大家一起共同进退,组织团队建设,发展团队成员间的友好关系。

建立敏捷型测试组织

我对敏捷软件测试的理解与实践

从项目特点来看,敏捷是属于“强项目型”管理的方式,但敏捷人员可以在自于静态的职能组织或将测试人员整合到敏捷项目中。

无论人员来自哪里,在敏捷团队中,测试和开发同属一个项目,大家的目标是一致的,敏捷测试人员在质量思想方面影响团队的其他成员。如测试人员可能会帮开发人员评审代码,开发人员也会帮测试人员进行测试,人员角色的职能可以模糊化。

敏捷测试团队还需要把客户纳入到组织中,学会一起工作并建立起彼此间的信任,一起做好软件的质量保证。

获得领导支持

我对敏捷软件测试的理解与实践

任何一个改变要想实施成功,都离不开领导层的大力支持。敏捷测试也强调领导的作用,从领导层的角度需要提供一个宽松的环境,让整个敏捷测试团队能够形成自组织的模式。当遇到问题时不是进行追责,而是给予足够的信任和支持,协调资源帮助团队解决问题,陪伴团队成长。

领导制订一些KPI考核指标,制定一些奖励办法,提高大家工作的积极性。

尽早进入测试

我对敏捷软件测试的理解与实践

测试人员需要了解敏捷,掌握敏捷的基本知识和原则,从而才能在整个敏捷体系中更快的融入到敏捷环境中,从而更好的开展整个测试工作。

测试工作不再是软件功能实现后再进行,而是测试工作前移,功能实现前就已经对测试做好规划,做好测试用例的设计及准备,等待测试的执行。

建立有效沟通方式

我对敏捷软件测试的理解与实践

敏捷测试人员需要与需求人员、开发人员保持沟通,建立一种相互合作的氛围。传统测试不同角色之间的接口可能主要是文档,在敏捷测试过程中,我们在弱化文档,不为文档而文档,主要还是以沟通为主,做为敏捷测试人员我们需要去变被动为主动,积极去做些改变。

为了取得更好的沟通效果,敏捷测试过程中的沟通方式不拘一格,可以实行正式的沟通和非正式的沟通,正式沟通的形式可以是邮件或会议,非正式的沟通工具可以是面对面、电话、Wiki、微信等。

引入CI、CD和CT

我对敏捷软件测试的理解与实践

敏捷测试要取得好的效果,CI、CD及CT[3]是必不可少,缺少任何一项,整个流程就会不顺畅,效果也就大打折扣。

但要做好这CI、CD和CT,除了需要合适的工具提供支撑,还需要项目整体团队紧密协作。测试团队还需要具备一定的技术能力,在过程中提供驱动力,推动整个过程有序进行。

持续集成

我对敏捷软件测试的理解与实践

自动化部署

我对敏捷软件测试的理解与实践

自动化测试

自动化测试是敏捷测试非常重要的组成部分。

在敏捷开发这种极短的交付周期内,如果仅仅靠手工测试,则非常难以满足快速发布要求的。所以自动化测试是必不可少的一种手段。

另外这里谈到的自动化测试不仅仅只是指功能的自动化测试,还包括单元测试、静态质量扫描、性能测试、安全扫描等,也涉及自动化测试如何集成在整个交付管道中,缩减整个交付时间,最终给项目带来价值。

提升敏捷测试能力

我对敏捷软件测试的理解与实践

回到测试的本质,作为敏捷测试人员需要做好敏捷测试的知识储备,无论是测试基础知识还是测试的技术技能,个人都需要考虑提升,组织上需要为个人提升打开空间,组织相关的培训,与行业先进测试理念接轨。

团队内部要经常进行团队分享,需要传道。对于敏捷测试的新思维,如果没有进行相关培训和了解,会让具体执行人觉得没有底气。同样,敏捷项目中测试人员在进行测试前也需要接受敏捷知识的培训。如果可能的话,最好是由具有丰富经验的敏捷测试教练帮忙进行指导,避免走错方向。

总结

敏捷软件测试不是独立存在的,它依赖敏捷的软件开发过程,强调的是敏捷项目团队的整体对质量的负责,测试团队不再是质量职责的全部。但敏捷测试团队需要以专业的知识驱动团队的质量意识,通过团队之间的紧密合作,实现敏捷研发的过程,快速推进业务价值的交付。

X-Eyes Admin
X-Eyes Admin

目前为止有一条评论

X-Eyes Admin
X-Eyes Admin 发布于10:06 上午 - 8月 28, 2019

在整个产品的生命周期过程中,关于测试是最容易引起问题,也最难的一部分;在中小企业中,测试体系的搭建,人员的培养,以及长久以来大家对于测试的不重视,让整个测试团队成为人员能力提升最弱,流动性也最强的团队。
而关于自动化测试与CI/CD的建设,更大的问题不是来源于团队,而是来源于公司的组织文化,对价值的理解,这一点上更需要公司层级的决策与支持。

要发表评论,您必须先登录

%d 博主赞过: