由于开发人员和测试人员对需求的理解存在的差异，以及各自的工作角色，关于BUG的争论在日常的项目中是经常遇到的，如何保证BUG及时修复，非BUG不影响项目的进度至关重要。

让开发心甘情愿的修改BUG，我们可以从下面几个方面来考虑：

一、为什么定为BUG

BUG描述------测试员在提出BUG时，要注意对BUG进行必要的描述，例：BUG出现的环境、出现该BUG进行的操作、预期结果和实际结果、BUG出现的几率，如果使用的BUG管理工具的允许，可以对该BUG添加一些附件：截图、脚本等，Jira、Lotus好像都可以添加附件。一方面增加开发对BUG的阅读、定位，另一方面能通过有利的论据证明该问题是BUG

BUG复现------提交BUG后要保证BUG复现，这样在项目经理、测试经理、开发人员争论BUG时，能强有力的证明该BUG是存在的。

BUG依据-------理论上，产品中不满足用户提出的需求可以定为BUG，这也是测试前期进行需求评审的原因。但是，目前很多公司的软件项目对其中的细节描述很不具体，导致了开发与测试关于BUG的歧义。在定BUG的时候我们可以本着这样一个原则：和当今流行产品做对比，比如说公司在做个搜索引擎，开发将搜索引擎的位置放在页面的底部，我们可以说这是一个BUG。理由很简单，百度、google的搜索框都在页面的上部。

二、测试经理对BUG的认同

测试经理的经验-----测试经理一般来说都是工作几年，有相当丰富的项目经验，我公司测试人员提出的BUG，一线的测试经理都要审核，审核通过才转到项目经理，这样避免了由于测试员工作经验不足和个人主观意愿导致BUG错误认定的情况。

测试经理的信赖-----测试经理对BUG认同后，也说明了该问题是BUG，在后续的争论中不会出现测试经理搪塞的情况，对测试人员也是非常有利的。