在软件测试工作中，我们经常会发现，有的缺陷明明很容易修改，但是开发就是不修改。
开发能给出很多不同的理由，比如没时间、问题不严重、不影响软件使用、不是缺陷，各种各样的理由。
为什么很容易就能修改的缺陷，开发为什么不愿意修改？
表面上看起来是开发人员的个人原因和意愿，实际上可能是缺陷修改的机制有问题。
缺陷的严重程度和优先级是否有清晰的定义，缺陷修改的时效性是否有清楚的定义，缺陷的流转是怎样的，如果开发和测试对缺陷有争议又该如何决策，这些都会影响到缺陷的修改。
我现在所在的项目，对于缺陷的管控就没有很完善的机制。
开发人员主导，测试人员处于弱势一方。
主要原因就是甲方一直没有制定一套有效的缺陷管理机制。
有的问题对于用户来说，体验非常不好。
比如用户在做了提交动作后，系统返回的是面向开发人员才能理解的报错码和报错信息，开发人员一眼能看出是什么原因导致的。
但是对于用户来说，这些报错信息完全是看不懂，用户体验非常不好。
用户想要知道报错码代表的问题是什么，就只能拨打客服电话。
而开发完全可以将报错信息修改为用户能看懂的内容，但是多年过去了，开发就是没改，问题一直遗留在系统。
甲方也没有推动这个问题的解决。
对于同类的问题，测试人员也就不再报缺陷，就这么让问题安静的躺在系统里面了。
所以不是缺陷很难修改，是缺陷修改的机制出了问题。
只是靠开发人员的自觉性，而没有一套有效的机制去推动，缺陷只会越积越多。
对于测试人员的积极性，也是打击。
哪怕是测试和开发打起来了，开发也不一定会修改。
有的时候，还真不是测试人员沟通的问题，就是机制的问题。
要想改变缺陷的处理效率，必须从根源上制定有效的缺陷处理机制。
就像一个房间采光不好，是因为旁边有棵大树挡住了阳光，不修整大树，开再大的落地窗光线也进不到房间，难道去责怪施工人员落地窗开的不够大？