本文章转载于搜狗测试
测试过程中，经常会遇到多方团队配合的项目，遇到最多的问题是，沟通成本高，导致整个项目迭代效率低。小编对配合过程中所遇到的问题进行归类分析，欢迎大家给出建议和探讨。
1.多方团队配合--提测的需求不一致的问题
测试小杰同学：负责C模块的测试任务。C模块涉及4方团队配合，在测试环节中发现，多方的信息未能及时的同步，导致功能的测试阻塞。
解决方案：
需求任务下发后，需明确此任务相关的人员，建议此需求的所有人员需当面进行沟通一次，将需求及任务进行明确。如果不能聚在一起，也需要拉个讨论组在讨论组里进行同步。比如：此次需求涉及到开发团队有哪些，大家对需求的理解是否一致，各自提测时间点，彼此是如何配合的等。
2.多方团队配合--提测环境、上线节奏不一致问题
测试小杰同学：负责模块A的测试任务。开发提测后，小杰执行测试用例，执行阻塞。小杰去找开发沟通问题，开发A在本地的环境是没有问题的。可是在小杰的机器中始终不能调通。来回多次的沟通定位，发现此任务是依赖开发B提交配置文件的。而在上线环节中，因信息的不明确，其中一方delay了上线时间，整体的上线节奏和质量受影响。
解决方案：
开发提测后，需要与各方团队进行沟通，最好是各方团队都在，会议上梳理开发整体的实现流程（将各方实现的逻辑梳理清晰），测试环境的梳理（比如：是否需要依赖Https环境，各方的代码是否已经合并到测试环境中），各方待上线的代码（比如：此次代码上线需几方上线，上线的时机如何）等信息。并将各信息进行邮件公示。
3.多方团队配合--Bug归属不明确的问题
测试小杰同学：负责B模块的测试任务。最近测试不顺利，B模块涉及4方团队，遇到Bug后，报给相关的开发人员会被打回来。因为模块涉及的开发人员较多，很难定位是谁的问题。Bug隐藏的比较深，谁来接收这个Bug呢？
解决方案：
各方配合团队成立时，需要将此问题抛出，各方团队定义规范标准。比较成熟的处理建议是，当Bug的归属不明确时，直接找Bug的上游开发，由Bug的上游开发分析定位Bug的归属，分配给负责修改Bug的开发人员。
4.多方团队配合- -各方配合职责不明确的问题
测试小杰同学：负责D模块的测试任务。测试过程中，需要依赖于第三方团队提供的SDK，测试集成后发现sdk包的质量有问题，需与第三方团队多次沟通SDK包的Bug， 沟通跟进的成本比预期高出很多，测试效率受到影响。
解决方案：
涉及多方开发配合问题时，需要明确各方的职责。如果不明确，需要及时的与配合方沟通，明确流程规范及输出指标。比如：涉及第三方团队集成的任务，则需要第三方配合团队给出测试完成报告，结合项目的实际情况，给出各类的指标数据。
多方开发配合--沟通的关键点：
1.多方配合过程中，信息务必保持同步，沟通过程中，最好各方人员都在场。
2.各方达成阶段性结论后，一定要有邮件公示，周知相关人员。
3.遇到问题后，及时的梳理问题，明确职责，制定流程规范。
4.涉及到配合团队输出结果时，需要明确指标数据，定期给出产出结果。
