各自分离的功能小组会让敏捷团队更困难。持续的交流至关重要。团队成员需要互相亲密地工作，不管工作是通过虚拟环境还是在同一个地点完成。敏捷测试专家Lisa和Janet分享了敏捷测试团队的组织经验。

　　独立的质量保证团队

　　许多组织，不管大还是小，为了得到关于产品质量的诚实的观点，认为拥有独立的质量保证团队或测试团队是很重要的。经常有人问我们：“在整体团队运作方式中有测试组织的位置吗？”以及“如果有，是什么角色？”希望保持质量保证团队与开发团队分离的原因有：

　　● 拥有独立的检查和审计角色很重要。

　　● 独立的质量保证团队可以对产品的质量提出没有偏见的外部观察的观点。

　　● 如果测试人员与开发人员过于亲密，将会像开发人员那样思考，丢失客户观点。

　　● 如果测试人员和开发人员向同一个人汇报，可能会有风险使得交付任何代码的优先级大于交付已测试代码的优先级。

　　团队经常混淆“独立的”和“分离的”。如果汇报结构、经费和过程保持在离散的功能区域，程序员和测试人员间的分离是必然的。这可能导致摩擦、竞争和“我们VS他们”的态度。时间浪费在重复的会议上，程序员和测试人员没有共同的目标，更不存在信息共享。虽然有许多原因需要质量保证经理和独立的测试团队。但是，我们建议改变原因和结构。与其保持测试人员作为对立的团队分离，在编码完成后测试应用，不如考虑将团队作为测试人员团体。提供一个学习性组织来帮助测试人员职业发展和分享想法及互相帮助。如果质量保证经理成为组织中的实践领导，人们将可以传授给测试人员技能使其变得更强并更好地适应不断变化的环境。

　　我们不相信将测试人员整合到项目团队会妨碍测试人员正常的工作。实际上，敏捷团队的测试人员感觉其客户代表的角色很明显，并且认为可以在质量思想方面影响团队的其他成员。

　　把测试人员整合到敏捷项目

　　敏捷开发中的整体团队运作方式已经促使很多采用敏捷开发的组织解散独立的质量保证团队，将测试人员与项目组一起工作。这听起来很好，但是有些组织发现事与愿违。不止一个组织已经导致大部分（如果不是）所有测试人员因为发觉他们在敏捷开发团队中不知道应该做什么而离职。培训开发人员结对编程、测试驱动开发和其他的敏捷实践，但是测试人员通常得不到任何培训。许多组织没有意识到测试人员也需要培训结对测试、处理不完整和变化的需求、自动化和需要的所有其他新技术。测试人员接受培训和辅导来获取技能并认识到这些将对于成功是很重要的，例如如何与客户一起编写面向业务的测试。程序员也可能需要辅导和理解面向业务测试的重要性以及整体团队运作方式来编写和自动化测试。

　　Janet曾帮助过整合几个独立的测试团队到敏捷项目。她发现大部分测试人员需要六个月的时间开始对使用新的过程感到有信心。

　　程序员和测试人员的结对只可能促进关于产品质量的交流。如果应用的行为不能在开发环境中重现，开发人员通常需要在测试人员的机器上观察应用的行为。测试人员有时与开发人员一起坐下重现问题会比他们尝试在缺陷报告中记录步骤更容易和快速。这种交互减少了用于非口头交流的时间。

　　测试人员关于这个话题的评价包含如下几条：

　　● “更接近产品的开发让我成为更出色的测试人员。”

　　● “与开发人员一起吃午饭可以构建更优秀的团队，这个团队希望并且喜欢一起工作。”

　　整合的项目团队的一个重要优势是只有一个预算和一个进度安排。如果所有的功能没有完成，不会减少“测试”时间。如果没有时间测试新的特性，则首先没有时间来开发它。正如贯穿本书强调的那样，整体团队对质量负责是非常强大的。