，但是变化可以是缓慢的。采用敏捷的新团队将会较慢地掌握承诺使用的一些实践。我们曾遇到很多沮丧的测试人员，他们的“敏捷”开发周期实际上是小型瀑布周期。这些测试人员仍然在受压榨，只是频率更多。迭代在用户故事可以被测试前结束。 程序员拒绝或者不能适应关键实践，例如测试驱动开发或者结对。团队把质量的责任交给了测试人员，但是测试人员没有权力改变过程。
没有魔法使你的团队做出有益的变化，但是我们为想让团队以有益的方式改变的测试人员提供了一些技巧。
耐心
新的技术，如测试驱动开发是很难的。找到让你的团队有时间去掌握他们的方法。在你等待的时候找到可以独立做出的改变。例如，当程序员学习编写单元测试时，以最小的帮助实现一个你可以使用的GUI测试工具。帮助团队成长。记住，当人们恐慌时，他们会变回旧的习惯，即使这些习惯没有作用。关注微小的有益增长。
让他们感觉到痛苦
有时不得不看到火车失事。如果改进的建议被回绝了，团队失败了，再次提出你的建议并请团队考虑试用几个迭代。人们最希望在他们感觉到最痛苦的领域改变。
建立你的诚信
你可能现在同以前没有与测试人员亲密工作的程序员一起工作。向他们展示你如何帮助团队。告诉他们你发现的问题而不是开出缺陷报告。请他们在提交代码前和你一起检查代码。当他们意识到你提供了真正的价值，他们将会更听从你的想法。
从事你自己专长的开发
阅读书籍和文章，参加用户组会议和讨论，学习新的工具和脚本语言。开始学习你的应用编码使用的语言，如果可以同程序员结对或者他们会辅导你，那么就请教他们。同事会注意到你渴望增长自己的技能。如果本地用户组希望听你对于敏捷测试的演讲，或者软件通讯发表了你的自动化文章，团队伙伴可能会注意到你有很多值得考虑的想法。
警惕质量警察思想
做一个合作者，而不是强制实施者。如果程序员不遵循编码标准可能会影响你，但是确保他们遵循编码标准不是你的工作。向团队提出你的问题并请求他们的帮助。如果他们忽略了一个至关重要的确实会伤害团队的问题，可能需要请求你的教练或经理的帮助。但是用“请帮我找个解决方案”的语气，而不是“让这些人这么做”的语气。如果你发现一个问题，其他人很可能也发现了。
用离开表示拒绝
你已经耐心了。你已经尝试了能想到的所有方法，但是管理层不理解敏捷开发。程序员已经导致很多缺陷和不可以测试的代码，并且代码被发布了，尽管你已经尽最大努力了，包括每天工作14个小时。没有人关心质量，感觉到努力被忽略。这可能是时候寻找一个更好的团队了。一些团队满足他们的方式，并不感觉到足够需要改变的痛苦。Lisa曾在一个越来越混乱的团队中工作，因为有很多机会来解决为什么服务器会宕机并成为英雄。尽管采用了敏捷实践而且项目成功了，但是他们又回到了旧习惯，Lisa最终放弃改变他们。