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