背景
服务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个:
- 往近了说,这次变动如果全量测试时C出了问题,C的开发肯定和C的测试说服务C没有变动,去看看A变了什么,找A的开发去定位。我们会有插入的事情。
- 如果C全量测试时没出问题,而是到了客户那里出现问题。追责的话,A脱离不了关系。至少还需要定位,帮助解决。
因此我认为需要我强力的推动B和C去测试。我把ABC测试拉到一起开了会,然后他们起初还是想撇清自己,后来他们明白了我的担忧,去找他们的上级讨论。
结论
结果是A测试不需要参与测试服务C。C这边启动一个常驻任务,由B来进行测试,C帮忙看看结果对不对。