敏捷测试中的挑战

组织文化

上一篇文章主要说了自己对敏捷测试的理解。其实很多事情都是说得容易做得难,从传统过渡到敏捷,我们会面临到很多的挑战,组织和团队的文化可能是阻碍向敏捷方式的一大障碍。在《敏捷软件测试一书》中,Lisa和Janet从12个方面去阐述了组织文化的内涵,这里我挑出几个来大体的讲一下我自己的认识。

1.整体团队负责质量: 在上一篇文章中也有提到“人人都是测试人员”的这一概念,一个敏捷团队一定要注意到这一点,改变开发人员和质量保证人员之间的敌对关系。当然这一点需要双方的共同努力,站在“质量保证人员”这一角度,我认为可以从每天给coder们笑脸,分发小饼干等小事做起,在开发过程中积极和其沟通,让他们感受到在开发过程中修复了所有BUG,避免了潜在的坑,从而在 后期上线环节有一个完美交付的快感,让开发人员也养成一个对质量负责的好习惯。

2.技能和适应能力:不能改变测试方式的测试人员很难和开发团队的其他人密切协作。作为测试人员要有很大的勇气去接受新鲜事物的挑战,要去发展自己熟悉范围内的新技能。从传统手工测试转换到自动化测试肯定是有困难,尤其是在一个没有系统的指导环境下,我们要有耐心,不能因为短期内没有见效而惴惴不安。

3.辅助因素:每个人不是说一上手就是专家,所以一开始不适应,没关系,要持续学习,寻求帮助。

4.沟通挑战:在敏捷的方式例如Scrum,拥有每日例会。大家可以交流自己的收获和接下来的任务,并且要去理性的认识每个人的“产出”。事实上,我在很多次的例会上都表明我前一天的任务是学习,这听起来很荒谬,但是不能不说,在以后的沟通中可以具体说一下学的是什么,也许会得到大家的建议和意见,有助于自己更好的成长,也可以给没有时间接触这些知识的人员长长姿势啦~~


测试团队适应敏捷的障碍

1.丧失身份:我个人认为这是对于测试团队转向敏捷的一个重大障碍。正如之前所说,敏捷团队中的测试贯穿于项目适中,测试人员贯穿各个团队。那这会让原来专门从事测试的人员想:那测试团队到底是做什么的?他们害怕丧失质量保证人员的身份,害怕分散于开发组织时自己的定位,害怕在这种需要更多新技能的敏捷团队中丧失自己的工作。这种恐惧让大家去拒绝敏捷。

2.缺乏培训:Agile2007大会中有这样一个例子,未经过任何培训的测试人员编入敏捷团队,结果未来三个月内,由于不能认清自己的角色而离职。所以我们需要专业的培训,这种培训可以从前辈获得,也可以通过研讨会获得,没有条件的话,可以利用网络培训。

3.不理解敏捷的概念:这一点也至关重要,我也是刚刚意识到,我所在的敏捷团队也许并没有get到敏捷的实质,我觉得我们更像是在经历一个小型瀑布过程。在小型瀑布模型中,编码部分加入了修改成分,并且在测试之后修改。但是编码和测试依旧是在两个模块中进行。如下图。其实在正真的敏捷开发中,编码和测试应该存在于同一单元。

敏捷测试中的挑战_第1张图片
小型瀑布模型

4.敏捷的实践:我们总是在理论上去讨论敏捷,在实践起来的时候并不能做到面面俱到。下面是极限编程雷达图,我认为也非常适用于我们的敏捷实践中, 对于之前就存在的短板我们选择忽略。这张图的左边代表着我们的期望,右边是大多数在适应敏捷模式的团队的行为。我们依旧在之前就比较“弱”的方面存在问题,我们需要去努力克服这些障碍,具体如何克服,之后我会再慢慢学习总结和实践。

敏捷测试中的挑战_第2张图片

5.陈旧的观点和经验:我相信在任何的创新性突破上,都会存在这样的阻碍。对于前辈留下来的经验和观点,我们不能够完全继承,要去自己评断它的可行性和适应性。毕竟也许年代不同,团队不同,适应的环境也会不同。我们要推陈出新,利用经验总结出适合自己的一套模式。



总结下来,就是改变并不是一件容易的事情,我们要正视转型过程中遇到的挑战和阻碍。发挥自己的优势,努力提升自己的技能来帮助自己所在的团队,也许你认为自己的努力是微不足道的,怎么可能一个人改变一个团队?说实话,我也不能确定这样能不能成功。但是未来的事,谁知道呢?我们还是需要去尝试,在创新过程中,总需要有人去当个领头羊,总需要有个人去更加努力的。相信你自己~

你可能感兴趣的:(敏捷测试中的挑战)