测试团队在从传统开发模式向敏捷模式转变的过程中存在各种障碍，敏捷测试专家Lisa和Janet从自身经验出发探讨了其中的原因和解决方法。

任何变化都面临成功路上的障碍。组织文化可能是要克服的最大障碍。组织文化一旦建立就很难改变。组织文化的形成需要时间，一旦就绪，员工会忠于该文化，这使得对改变相当的抵制。

丧失身份

由于很多原因，测试人员坚持独立的质量保证团队，但是主要原因是害怕，特别是：

害怕丧失质量保证人员的身份
   害怕如果向开发经理汇报，会丧失支持，程序员会获得优先权
   害怕缺乏在敏捷团队中工作的技能从而丢失工作
   害怕当分散于开发团队时，得不到需要的支持
   害怕他们和经理在新的组织中迷失
   其他角色

按照我们的经验，新的团队往往缺少使项目成功的关键专家。Lisa的团队曾经遇到巨大的障碍，唯 一能做的事情是停工和询问：“我们的团队缺少什么角色导致我们停止不前？我们需要什么？另外一个开发人员、另外一个测试人员，还是一个数据库设计人员？” 我们知道测试是一个宽广的领域。也许需要一个对敏捷团队的测试有经验的人员，或者可能需要一个性能测试专家。需要花时间去分析产品的成功需要什么角色，是 否需要从团队外引入这些角色，这很重要，一定要做。产品团队中的每一个人都需要理解他们的角色并认识到他们是新的敏捷团队的一部分，这很重要。但是这需要 时间和培训。

缺乏培训

我们曾在Agile 2007大会中一次会议上询问人们在敏捷团队中有什么测试相关的问题。其中一个与会者告诉我们，他们根据敏捷资料的建议分拆了测试组织。但是，他们没有经 过任何培训就把这些测试人员编入开发团队。在三个月中，所有的测试人员由于没有理解他们的新角色而离职。这类问题可以通过正确的培训和指导来避免。

当开始在第一个敏捷团队中工作时，没有太多的资料能够帮助我们理解敏捷测试人员应该做什么以及我 们应该怎么同团队一起工作。如今，你可以找到很多能够帮助培训测试人员适应敏捷环境及帮助测试团队进行敏捷转变的先行者。本地用户组、会议、研讨会、在线 介绍和邮件列表都为想学习敏捷的测试人员和经理提供了有用的资料。当你需要帮助时，不要害怕寻求帮助。出色的培训会为你的投资带来良好的回报。

不理解敏捷概念

不是所有的敏捷团队都是相同的。敏捷开发有许多不同的方式，例如极限编程、Scrum、 Crystal、特征驱动开发、领域定义模型、Open UP。我们认为一些自称为“敏捷”的团队其实不是使用敏捷。许多团队只是简单采用对他们有用的实践，并不管来自于哪里还是自己的发明。这是允许的，但是如 果他们不遵循任何核心敏捷价值和原则，我们会怀疑他们的敏捷身份。按月发布和丢弃文档并不等同于敏捷开发！

如果不同的团队成员对“敏捷” 的构成有相反的想法，例如，使用什么实践或者这些实践应该是怎么样的，那么将会有麻烦。例如，如果你是推动团队使用连续迭代的测试人员，但是程序员拒绝使 用，那么你就处于麻烦的境地。如果你是不能参与一些实践的程序员，例如通过面向业务的测试来推动开发，那么，也会引起冲突。

团队必须就如何实现向敏捷的成功转变而达成一致意见。很多敏捷开发实践是相互协作的，因此如果单 独使用这些实践，可能得不到团队希望的效果。团队也许可以同意在一定的迭代中试验某些实践并评价其效果。可以寻找外部的帮助来协助他们理解这些实践并如何 将它们协作。多样化的观点对团队是有益的，但是每个人都需要朝同一个方向努力。

过去的经验/观点

很多人经历过改变，但没有延续下来。一些开发组织已经有过一连串的“方法”。他们质疑：“我们为 什么还要再次做这个？”人们坚持陈旧、失败的模式。即使当他们试验新的方法时，也可能在压力下重复坏的老习惯。下面是一些例子，列举了人们由于过去的经历 和对事物的误解而抵制变化：

测试人员坐在座位上不与程序员讨论存在的问题。抱怨程序员不能理解他想要什么。
测试人员无法改变看法：开发人员不知道如何写出好代码或如何测试。他完全没有谦逊的态度，作为测试人员的威信也受到质疑。
客户发现程序员做了其不喜欢的事情时提出抗议，因为程序员总是为所欲为。
当面临到敏捷开发的转变时，这样的人经常迅速离开，不给新的过程机会。敏捷开发不适合所有人，但是培训和实验的时间可以帮助改变这个态度。让每个人成为解 决方案的一部分，协同工作来发现对其特定情况最适用的过程和实践。自组织的团队是一个可以用来保证开发团队所有成员掌握他们自己的命运的强大工具。

角色间的文化差异

每个敏捷团队的新成员都在从不同的角度转变。程序员经常习惯于编写产品代码并使其尽可能快地发布。系统管理员和数据库专家可能习惯于在他们自己的领域工作， 根据自己的进度执行需求。客户可能从来不与开发团队成员直接谈话。测试人员可能习惯于在项目的末期参与而且不与程序员有太多的交互。

毫无疑问，到敏捷的转变可能引起惊慌。团队可以通过规则和方针帮助他们交流和顺利地协同工作。例如，Lisa曾经加入一个新的敏捷团队，团队有一条规则是，如果有人要求和你结对，你必须同意。你可能一开始无法适应，一旦融入进来，你就需要帮助团队伙伴。

识别不同角色的人的需求，并想办法来提供帮助。客户需要途径来获得开发进度和了解他们的条件是否 会被满足。开发人员需要知道业务优先级和需求。测试人员需要途径来获取实例和将其转变为测试。所有的团队成员希望感觉到他们是有价值的，是优秀的团队成 员。每一个团队成员也需要安全感和可以自由地提出问题，以及尝试新观点。了解每个角色的观点可以帮助团队完成转变。

对于以上问题，测试团队应该如何面对呢？Lisa和Janet提供了以下建议：

讨论恐惧

当开始迭代开发时，使用回顾总结来提供讨论恐惧和获得反馈的机会。让人们知道感觉到恐惧是正常 的。保持开放态度，告诉大家感到恐惧和不适应是可以接受的。讨论每个恐惧的根源，从讨论中学习，作出决定并继续前进。恐惧是对变化的正常反应。强迫人们做 他们不想做的事情必定会反对变化。

赋予团队权力

一个关键的成功因素是团队是否有权决定自己的方式。如果得到正确的帮助，人们将会改变他们的观点 和感觉。Lisa曾经观察Mike Cohn在团队中作为教练的情况。作为一个自组织的团队，团队需要确定并解决他们自己的问题。Mike确保他们有时间和资源来实验和改进。他确保业务人员 理解质量比数量和速度更重要。每个团队，即使是自组织的团队都需要一个可以有效的与组织的管理层沟通的领导。

庆祝成功

变化需要时间并且会遇到挫折，所以，一定要庆祝你的团队获得的所有成功。当达到在迭代的第四天为所有用户故事写出高层次的测试用例这个目标时，你应该庆幸。 当成功完成一个迭代，让团队一起做小游戏或者吃午饭。认可成果对于变化的巩固很重要。

在让测试人员继续向质量保证经理汇报的同时，融入开发团队是帮助转变到敏捷开发的好办法。测试人员可以发现从对程序员的敌对关系转变到协作关系的方式。可以展示他们如何帮助团队理解客户需求并交付满意的业 务价值。可以举办令人愉快的活动来建立良好的团队交互。给团队成员准备饼干和巧克力是让他们走近你的一种好的方式。耐心和幽默是巨大的优势。

但是，Lisa和Janet也提醒测试团队——改变并不容易。

敏捷开发可能更快速，但是变化可以是缓慢的。采用敏捷的新团队将会较慢地掌握承诺使用的一些实践。我们曾遇到很多沮丧的测试人员，他们的“敏捷”开发周期实际上是小型瀑布周期。这些测试人员仍然在受压榨，只是频率更多。迭代在用户故事可以被测试前结束。 程序员拒绝或者不能适应关键实践，例如测试驱动开发或者结对。团队把质量的责任交给了测试人员，但是测试人员没有权力改变过程。

没有魔法使你的团队做出有益的变化，但是我们为想让团队以有益的方式改变的测试人员提供了一些技巧。

耐心

新的技术，如测试驱动开发是很难的。找到让你的团队有时间去掌握他们的方法。在你等待的时候找到 可以独立做出的改变。例如，当程序员学习编写单元测试时，以最小的帮助实现一个你可以使用的GUI测试工具。帮助团队成长。记住，当人们恐慌时，他们会变 回旧的习惯，即使这些习惯没有作用。关注微小的有益增长。

让他们感觉到痛苦

有时不得不看到火车失事。如果改进的建议被回绝了，团队失败了，再次提出你的建议并请团队考虑试用几个迭代。人们最希望在他们感觉到最痛苦的领域改变。

建立你的诚信

你可能现在同以前没有与测试人员亲密工作的程序员一起工作。向他们展示你如何帮助团队。告诉他们你发现的问题而不是开出缺陷报告。请他们在提交代码前和你一起检查代码。当他们意识到你提供了真正的价值，他们将会更听从你的想法。

从事你自己专长的开发

阅读书籍和文章，参加用户组会议和讨论，学习新的工具和脚本语言。开始学习你的应用编码使用的语 言，如果可以同程序员结对或者他们会辅导你，那么就请教他们。同事会注意到你渴望增长自己的技能。如果本地用户组希望听你对于敏捷测试的演讲，或者软件通 讯发表了你的自动化文章，团队伙伴可能会注意到你有很多值得考虑的想法。

警惕质量警察思想

做一个合作者，而不是强制实施者。如果程序员不遵循编码标准可能会影响你，但是确保他们遵循编码 标准不是你的工作。向团队提出你的问题并请求他们的帮助。如果他们忽略了一个至关重要的确实会伤害团队的问题，可能需要请求你的教练或经理的帮助。但是用 “请帮我找个解决方案”的语气，而不是“让这些人这么做”的语气。如果你发现一个问题，其他人很可能也发现了。

用离开表示拒绝

你已经耐心了。你已经尝试了能想到的所有方法，但是管理层不理解敏捷开发。程序员已经导致很多缺 陷和不可以测试的代码，并且代码被发布了，尽管你已经尽最大努力了，包括每天工作14个小时。没有人关心质量，感觉到努力被忽略。这可能是时候寻找一个更 好的团队了。一些团队满足他们的方式，并不感觉到足够需要改变的痛苦。Lisa曾在一个越来越混乱的团队中工作，因为有很多机会来解决为什么服务器会宕机 并成为英雄。尽管采用了敏捷实践而且项目成功了，但是他们又回到了旧习惯，Lisa最终放弃改变他们。