如何看待开发的随意变更模块功能

       这几天也有在51test上浏览一些文章，关于开发和测试之间的关系的文章，非常的多。

        大部分比例的观点都会描述开发和测试之间存在居多的问题，比如开发认为测试爱找茬，喜欢钻牛角尖，测试认为开发不懂测试，质量意识不强，等等。

       今天，在工作中，我经历了一件事情。项目即将发布了，开发对一个模块某个功能的实现换了别的逻辑，而这个变动作为这个项目的测试负责人的我是透明的，我不知道开发改变了这个逻辑。但幸好在项目冒烟测试阶段，我就编写了所有模块的主流程的自动化脚本，并进行每天的回归测试。在今天发现部分脚本执行失败，排查原因发现变更了逻辑的地方脚本报错了，于是和开发确认后，是变更逻辑所致。

       后来我又排查了另外几个失败的脚本，发现又有一个文本输入限制的逻辑也变更了。

       对于这种情况，我觉得对于开发来说，功能的变更太随便了，在他们的意识里没有完整的质量意识，认为自己变更的只是一个小功能，没有必要知会测试。但是，往往是开发的这种习惯，最后却导致线上的故障。

       对于开发的这种习惯，也有几个相应的措施来监控，一个就是监控他们每次提交的代码，二个就是通过自动化脚本进行持续集成，不断的校验系统各模块的功能。当然，也幸好有后者，让我发现了这个问题的所在。

      在这里，虽然问题在发布前被发现，但我们想想，如果我们没有这个条件，在已经测试好几轮后，开发又偷偷改动了其他的功能，悲剧迟早会发生的。

      思考再三，我觉得自己还是唱个黑脸，在项目交流群里，把这几个问题抛出来，并表明我的观点：在即将发布前，开发随意的变更功能，不知会测试，这样的项目质量让测试如何有信心来保证。

      开发也抛出了自己的观点，说这都是一些小的功能，没有必要事事都告知测试吧，觉得我是在钻牛角尖。但我觉得，这不单单仅仅是功能大小的问题，而是一种意识，一种习惯。即使我也觉得这几个小变更确实不会对系统造成大的影响，但是，我很害怕开发的这种习惯，或许哪天，因为这种情况，人算不如天算，在发布后因为小功能导致重大问题，这种情况不是没可能，我情愿做个悲观者。

      对于开发来说，测试有责任去杜绝开发的这种习惯，去培养他们良好的质量意识，现在很流行的缺陷预防，我想，如果开发也有良好的质量意识，未尝不是在进行有效的缺陷预防。