各自分离的功能小组会让敏捷团队更困难。持续的交流至关重要。团队成员需要互相亲密地工作，不管工作是通过虚拟环境还是在同一个地点完成。敏捷测试专家Lisa和Janet分享了敏捷测试团队的组织经验。
独立的质量保证团队
许多组织，不管大还是小，为了得到关于产品质量的诚实的观点，认为拥有独立的质量保证团队或测试团队是很重要的。经常有人问我们：“在整体团队运作方式中有测试组织的位置吗?”以及“如果有，是什么角色?”希望保持质量保证团队与开发团队分离的原因有：
拥有独立的检查和审计角色很重要。
独立的质量保证团队可以对产品的质量提出没有偏见的外部观察的观点。
如果测试人员与开发人员过于亲密，将会像开发人员那样思考，丢失客户观点。
如果测试人员和开发人员向同一个人汇报，可能会有风险使得交付任何代码的优先级大于交付已测试代码的优先级。
团队经常混淆“独立的”和“分离的”。如果汇报结构、经费和过程保持在离散的功能区域，程序员和测试人员间的分离是必然的。这可能导致摩擦、竞争和“我们VS他们”的态度。时间浪费在重复的会议上，程序员和测试人员没有共同的目标，更不存在信息共享。虽然有许多原因需要质量保证经理和独立的测试团队。但是，我们建议改变原因和结构。与其保持测试人员作为对立的团队分离，在编码完成后测试应用，不如考虑将团队作为测试人员团体。提供一个学习性组织来帮助测试人员职业发展和分享想法及互相帮助。如果质量保证经理成为组织中的实践领导，人们将可以传授给测试人员技能使其变得更强并更好地适应不断变化的环境。
我们不相信将测试人员整合到项目团队会妨碍测试人员正常的工作。实际上，敏捷团队的测试人员感觉其客户代表的角色很明显，并且认为可以在质量思想方面影响团队的其他成员。
把测试人员整合到敏捷项目
敏捷开发中的整体团队运作方式已经促使很多采用敏捷开发的组织解散独立的质量保证团队，将测试人员与项目组一起工作。这听起来很好，但是有些组织发现事与愿违。不止一个组织已经导致大部分(如果不是)所有测试人员因为发觉他们在敏捷开发团队中不知道应该做什么而离职。培训开发人员结对编程、测试驱动开发和其他的敏捷实践，但是测试人员通常得不到任何培训。许多组织没有意识到测试人员也需要培训结对测试、处理不完整和变化的需求、自动化和需要的所有其他新技术。测试人员接受培训和辅导来获取技能并认识到这些将对于成功是很重要的，例如如何与客户一起编写面向业务的测试。程序员也可能需要辅导和理解面向业务测试的重要性以及整体团队运作方式来编写和自动化测试。
Janet曾帮助过整合几个独立的测试团队到敏捷项目。她发现大部分测试人员需要六个月的时间开始对使用新的过程感到有信心。
程序员和测试人员的结对只可能促进关于产品质量的交流。如果应用的行为不能在开发环境中重现，开发人员通常需要在测试人员的机器上观察应用的行为。测试人员有时与开发人员一起坐下重现问题会比他们尝试在缺陷报告中记录步骤更容易和快速。这种交互减少了用于非口头交流的时间。
测试人员关于这个话题的评价包含如下几条：
“更接近产品的开发让我成为更出色的测试人员。”
“与开发人员一起吃午饭可以构建更优秀的团队，这个团队希望并且喜欢一起工作。”
整合的项目团队的一个重要优势是只有一个预算和一个进度安排。如果所有的功能没有完成，不会减少“测试”时间。如果没有时间测试新的特性，则首先没有时间来开发它。正如贯穿本书强调的那样，整体团队对质量负责是非常强大的。
Lisa分享了自己的故事：
我曾经加入过极限编程团队，只依赖于单元级的测试，以前从来没有过测试人员的角色。客户有时对结果不满意，所以他们决定聘用一名测试人员。当我参加每日站立会议时，他们不允许我说测试任务。用户故事评估中不包含测试时间，测试任务也不是迭代计划的一部分。只要编码任务完成，用户故事就被标记为“完成”。
团队超过发布日期后，计划在三个两周迭代后发布，我建议团队教练尝试整体团队运作的方式来测试。测试任务与编码任务一起进行。在测试任务没有完成之前，不能认为用户故事已经结束。程序员承担测试任务，我完全参与到每日站立会议中。团队此后再也没有错过他们设定的发布计划。
测试人员需要是开发团队的正式成员，测试任务需要和其他任务一样的重视。并且，用整体团队运作的方式来测试可以显著帮助确保测试任务在每个迭代及发布的末期完成。确保用回顾总结来评估测试人员需要与新敏捷团队整合什么，及需要获取什么技能。例如，测试人员可能需要程序员或某种特定类型的测试专家的更多支持。
组织转变到敏捷开发的良好规划会使这种成功的过程截然不同。请质量保证和开发经理指定出他们在新的敏捷组织中的角色。请他们计划如何帮助测试人员和开发人员在新的敏捷团队中高效地工作。提供团队敏捷实践培训。确保所有的团队可以相互交流。提供让每个团队不断学习的框架，团队就会找到成功的道路。
实例研究：转变质量保证和项目团队
Christophe Louvion是知名网络公司的首席技术官和敏捷教练。他告诉我们帮助公司使用敏捷开发的经历。作为敏捷教练，他希望真正地使用敏捷开发，避免常见的“小型瀑布”的错误，即开发人员花一周编码，测试人员下一周测试。
他的公司包括内部的IT部门当时有120名工程师。在转变到Scrum前，公司的组织正常工作。因为有质量保证和工程总监，基于产品的团队很难得到管理层的接受。这些团队的经理用下面的问题与之斗争：“我的工作现在是什么?”Christophe将这个问题转给经理们并说：“你们回答我。”他同工程和质量保证经理们一起工作来帮助他们明白在新的敏捷环境中的工作应该是什么。只有当他们用同样的声音说话时，他们才能融入团队并解释他们的发现。
在新的敏捷组织中，经理们处理特定领域知识、资源、优先级和提出的问题。工程和质量保证经理们每天联合工作来解决这些类型的问题。Christophe和两个经理研究测试人员在两周迭代的第一个星期没有工作效率的原因并指导他们如何帮助设计。对于程序员来说，问题是“我如何做才能让代码容易测试?”因为工程师们习惯于阶段周期的工作，没有过在持续集成方面的培训，需要测试驱动设计、持续集成和实践等方面的许多培训。经理保证了他们获得这些培训。
引入了配置管理(CM)专家来帮助构建过程。在公司中，CM团队与工程和质量保证团队是分离的，提供构建过程中所有方面的框架，包括数据库对象、硬件和配置。一旦实现了构建过程，集成编码和测试将会更加容易
管理层首先确定他们的角色，然后把所有东西都放入源码控制的构建过程框架，是成功转变到敏捷的关键。另一个成功因素是所有的团队——项目、质量保证、配置管理、网络和系统管理小组及产品团队——都有回顾总结，参与每日站立会议和计划活动。这样，当出现测试问题时，每个可以帮忙的人都可以解决。如Christophe所说，他们的方法引入了每一个人并且突出了测试。