响应变化是敏捷实践的重要价值，但是我们发现这对测试人员来说却是最困难的概念之一。测试人员渴望的是稳定，所以他们会说：“我已经测试过了，任务完成了”。持续的需求变化是测试人员的噩梦。但是，作为一名敏捷测试人员，我们不得不拥抱变化。周三，我们可能期望启动故事A和B，下周五做故事C。但是到了周五，客户重新设定了优先级，现在需要故事A、X和Y。只要我们持续与客户交流，我们就能处理这些变化，因为我们与团队的其他成员保持同步。
有些敏捷团队尝试提前准备下一次迭代，比如编写高层次的测试用例、捕捉业务满足条件或者记录示例。如果故事的优先级发生变化则这种行为可能只是浪费时间。但是，分布式团队非常需要额外的反馈周期为迭代做准备。
----------------------------------------------------------------------------------------------------------------------------------------------------
Lisa的故事
一个远程团队成员曾经是我们的现场经理。他在帮助企业客户编写和设定故事优先级方面起到了关键作用。他对编程和业务都有深刻理解，这有助于他提出创造性的解决方案以满足业务需求。当他搬到印度时，我们设法留住他以发挥他的专长作用。我们会定期安排与他开会，与产品负责人通过电话会议讨论未来的故事。我们不得不在能使用的各种工具中切换（从低技术含量的索引卡到在线工具）。
因为团队乐于通过有效的方式做出改变，寻找工具以确保跟得上变化，所以我们能够使他的专长继续发挥作用。
—— Lisa
----------------------------------------------------------------------------------------------------------------------------------------------------
某些团队的分析人员花费较多的时间与业务专家做提前规划。每一个团队不得不在头脑风暴式的预先解决方案和每一次迭代的第一天从头开始之间寻找平衡。敏捷测试人员与团队一起适应变化。
自动化测试是一个关键的解决方案。有一件事情我们可以肯定：如果只是手动测试，没有敏捷团队会获得成功。我们需要健壮的自动化方案以在有效的时间内发挥价值。
（8）自我组织
敏捷测试人员是自组织敏捷团队的组成部分。团队文化贯彻于敏捷测试理念。当开发人员、系统管理员、分析员、数据库专家和客户团队持续关注测试和测试自动化，测试人员就会获得全新的视角。自动化测试很困难，但是当整个团队都在为此努力时就会简单得多。当大家具有多重技能和多层次视角时，任何测试问题都会更容易解决。
----------------------------------------------------------------------------------------------------------------------------------------------------
Lisa的故事
我的团队是一个自我组织的好示例。当我们实施Scrum时，面对一个问题很多的遗留系统而且没有自动化测试。对代码的任何更改都存在风险。经理可能知道如何解决这个问题，但是他没有提出来。相反，我们研究了一下并拟定了一个计划。
开发人员开始在新的可测试的架构中实现新故事，采取测试驱动开发的模式。测试人员编写手动回归测试脚本，整个团队—— 开发人员、测试人员、系统管理员、数据库管理员—— 在每个迭代的最后两天执行。与此同时，测试人员将执行用户界面的自动化冒烟回归测试。最终，新代码的架构让我们可以通过某些工具（如FitNesse）自动化功能测试。
我们在起步阶段实施了这项计划，并在每次迭代中改进方法。利用团队每一位成员的技能比我独断专行地决定自动化策略要好得多。
—— Lisa
----------------------------------------------------------------------------------------------------------------------------------------------------
当敏捷团队面对一个严重问题时，比如进度障碍或者构建失败，该问题将是所有人的问题。最高优先级的问题需要整个团队解决。团队应该立刻讨论并决定解决的办法和相关参与人员。
毫无疑问，Lisa的经理本来可以指定团队采用这个办法来解决自动化问题，但是团队自身能够提出一个有效的计划。当团队创建一个自己的方法并作出承诺，成员就会对测试采取新的态度。
