Lisa分享了自己的故事：

　　我曾经加入过极限编程团队，只依赖于单元级的测试，以前从来没有过测试人员的角色。客户有时对结果不满意，所以他们决定聘用一名测试人员。当我参加每日站立会议时，他们不允许我说测试任务。用户故事评估中不包含测试时间，测试任务也不是迭代计划的一部分。只要编码任务完成，用户故事就被标记为“完成”。

　　团队超过发布日期后，计划在三个两周迭代后发布，我建议团队教练尝试整体团队运作的方式来测试。测试任务与编码任务一起进行。在测试任务没有完成之前，不能认为用户故事已经结束。程序员承担测试任务，我完全参与到每日站立会议中。团队此后再也没有错过他们设定的发布计划。

　　测试人员需要是开发团队的正式成员，测试任务需要和其他任务一样的重视。并且，用整体团队运作的方式来测试可以显著帮助确保测试任务在每个迭代及发布的末期完成。确保用回顾总结来评估测试人员需要与新敏捷团队整合什么，及需要获取什么技能。例如，测试人员可能需要程序员或某种特定类型的测试专家的更多支持。

　　组织转变到敏捷开发的良好规划会使这种成功的过程截然不同。请质量保证和开发经理指定出他们在新的敏捷组织中的角色。请他们计划如何帮助测试人员和开发人员在新的敏捷团队中高效地工作。提供团队敏捷实践培训。确保所有的团队可以相互交流。提供让每个团队不断学习的框架，团队就会找到成功的道路。

　　实例研究：转变质量保证和项目团队

　　Christophe Louvion是知名网络公司的首席技术官和敏捷教练。他告诉我们帮助公司使用敏捷开发的经历。作为敏捷教练，他希望真正地使用敏捷开发，避免常见的“小型瀑布”的错误，即开发人员花一周编码，测试人员下一周测试。

　　他的公司包括内部的IT部门当时有120名工程师。在转变到Scrum前，公司的组织正常工作。因为有质量保证和工程总监，基于产品的团队很难得到管理层的接受。这些团队的经理用下面的问题与之斗争：“我的工作现在是什么？”Christophe将这个问题转给经理们并说：“你们回答我。”他同工程和质量保证经理们一起工作来帮助他们明白在新的敏捷环境中的工作应该是什么。只有当他们用同样的声音说话时，他们才能融入团队并解释他们的发现。

　　在新的敏捷组织中，经理们处理特定领域知识、资源、优先级和提出的问题。工程和质量保证经理们每天联合工作来解决这些类型的问题。Christophe和两个经理研究测试人员在两周迭代的第一个星期没有工作效率的原因并指导他们如何帮助设计。对于程序员来说，问题是“我如何做才能让代码容易测试？”因为工程师们习惯于阶段周期的工作，没有过在持续集成方面的培训，需要测试驱动设计、持续集成和实践等方面的许多培训。经理保证了他们获得这些培训。

　　引入了配置管理（CM）专家来帮助构建过程。在公司中，CM团队与工程和质量保证团队是分离的，提供构建过程中所有方面的框架，包括数据库对象、硬件和配置。一旦实现了构建过程，集成编码和测试将会更加容易

　　管理层首先确定他们的角色，然后把所有东西都放入源码控制的构建过程框架，是成功转变到敏捷的关键。另一个成功因素是所有的团队——项目、质量保证、配置管理、网络和系统管理小组及产品团队——都有回顾总结，参与每日站立会议和计划活动。这样，当出现测试问题时，每个可以帮忙的人都可以解决。如Christophe所说，他们的方法引入了每一个人并且突出了测试。