【工作笔记】记录工作中一次处理冲突

背景

服务C在之前某个环境使用了我们服务A提供的一个特性。服务B目前要在同样的环境使用类似的能力，希望能够使用我们服务提供的特性。服务B和服务C对于我们来说使用的地方很相似。因为当初为C设计这个特性时没想到别的服务也能用到，所以写的没有那么灵活。如今B也要用，重构有些来不及了，所以决定改动一下特性的具体实现，在不影响C使用（接口及预期）的情况下兼容B。

工作

我作为服务A的开发，需要和服务B的开发商讨本次具体适配细节。我还需要和服务C的人一起验证下修改后的特性是否会影响到C，因为这块之前测试用例就比较少。而且做为服务A，说没有改动不那么具备说服力，还是得由服务C来出人测试并给出结论。

冲突

服务A的测试认为只测A这边的改动即可，不需要测C的问题。
服务B的测试认为B的改动和C没关系，不需要测C的问题。
服务C的测试认为本次改动我们都没变化，不需要测C的问题。
三方测试都不想去测试，因为对他们来说都是费力不讨好的事情。
但是我认为应该测试C，原因至少有2个：

1. 往近了说，这次变动如果全量测试时C出了问题，C的开发肯定和C的测试说服务C没有变动，去看看A变了什么，找A的开发去定位。我们会有插入的事情。
2. 如果C全量测试时没出问题，而是到了客户那里出现问题。追责的话，A脱离不了关系。至少还需要定位，帮助解决。

因此我认为需要我强力的推动B和C去测试。我把ABC测试拉到一起开了会，然后他们起初还是想撇清自己，后来他们明白了我的担忧，去找他们的上级讨论。

结论

结果是A测试不需要参与测试服务C。C这边启动一个常驻任务，由B来进行测试，C帮忙看看结果对不对。