当软件开发组织采用敏捷开发时，测试或者质量保证团队通常需要花很长的时间来完成转变。在很多的公司中，独立的质量保证团队已经根深蒂固。当他们开始适应新的敏捷组织时，会遇到难以接受的文化差异。敏捷测试的团队结构也将发生变化，测试人员如何真正融入团队。传统的测试活动，例如记录缺陷，跟踪进度和编写测试计划，是否不适合敏捷项目。

　　敏捷测试团队的文化将要进行很大的挑战：组织文化（质量哲学，可忍受的速度，客户关系，组织大小，壮大你的团队），成功的障碍（丢失身份，额外的角色，缺乏培训，不理解敏捷概念，过去的经验，角色间的文化差异），引人变化（讨论恐惧，赋予团队权力，庆祝成功），管理期望（经理的文化变化，使用经理的语言），变化并不容易（耐心，是他们感到痛苦，建立你的信用，专业的发展，谨防质量警察思想，用离开表示拒绝），文化影响测试人员和团队成功地转变到敏捷测试。在做任何变化之前都应考虑组织文化，当整个组织重视质量的时候，测试人员可以容易地敏捷团队，但是具有“质量警察”思想的测试人员很难融入敏捷团队。客户团队和开发团队一起工作，展示了测试人员如何在促成这种关系的时候发生重要作用。测试人员采用敏捷成功的障碍包括恐惧，丧失身份，缺乏培训，以前使用新的开发过程的失败经历和角色间的文化差异。经理也面临自己的文化挑战，他们需要向测试人员提供支持和培训来使他们在敏捷团队中获得成功。测试人员可以通过提供经理追踪进度和确定投资回报率需要的信息来帮助团队达到经理的期望。改变并不容易，需要耐心，努力提升自己的技能可以帮助自己的团队。

　　敏捷团队的构成也有些不一样。团队构成：团队结构（独立的质量保证团队，把测试人员整合到敏捷项目中，敏捷项目团队），人员分布，资源（测试人员与开发人员比例，聘用敏捷测试人员），建设团队（自组织团队，引人其他团队，每个团队成员有同等的价值，业绩和奖励，你可以做什么）。敏捷团队强调面对面的交流这对于项目的成功是至关重要的，他们也鼓励使用“整体团队运作”的方式，这对测试人员意味做什么呢？

　　敏捷团队从传统的方式迁移到敏捷方式下，有很多的改变。在传统项目中有很多过程不能很好地迁移到敏捷模式，因为它们需要重量级的文档，或者是阶段性过程的固有部分，需要在每个阶段结束时执行退出手续。

　　迁移传统过程有：寻找轻量级过程，度量标准（精简测算，为什么我们需要度量，与度量无关的事情，沟通，度量的投资回报率），缺陷沟通（为何应该使用缺陷跟踪系统，为何我们不需要缺陷跟踪系统，缺陷跟踪工具），测试计划（测试策略及测试计划，可跟踪性），现有过程（审计，框架，模型和标准）。我在若干组织中运用过这种方法并取得了成功，对于所有项目通用的过程将被记录在一个文档中，使用这种方式解决了大多数制度需求，其中一些主题包括：测试实践，故事测试，解决方案验证测试，探索性测试，负载和性能测试，测试自动化，测试结果，缺陷工作过程，测试工具，测试环境。