敏捷测试中的挑战

组织文化

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

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

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

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

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

---

测试团队适应敏捷的障碍

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

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

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

小型瀑布模型

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

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

---

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