由于开发人员和测试人员对需求的理解存在的差异，以及各自的工作角色，关于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，在后续的争论中不会出现测试经理搪塞的情况，对测试人员也是非常有利的。
三、有效的沟通
"牺牲色相"-----该方法要求测试人员为了工作，主动和开发建立良好的关系。譬如：请开发吃饭等等，这种方法最有效，也是百试百灵。但个人不建议这么做，工作就工作，耍手段是不好滴。
"良好的同事关系"----这种方法要求测试和开发平等的地位，测试要本着"我的工作职责就是让软件运行的更好"，通过合理的沟通手段，让开发能认同自己的观点，并进行BUG的修复。不要因为自己对技术了解不如开发深，就不敢提问题。
"强调BUG的影响"----沟通中提出修改BUG带来的好处，不修改BUG将要导致的问题，让开发明白问题的严重性。那怕是用户体验的BUG，也可以借助用户的场景，说明修复BUG的必要性
四、利用身边的资源
上级领导-----借助测试经理和项目经理，有时候个人不能协调解决的问题，就不要逞强，让测试经理和项目经理来协调，切忌不要悄悄的在项目经理面前说开发的坏处，大家都是打工的何必呢，况且不一定能起到作用。要记住--自己找项目经理和测试经理是协议矛盾的，解决问题的。
部门例会-----很多公司，每周或每月都会进行部门例会，方便各个部门间交流沟通，可以由测试经理反映下最近测试情况，测试员发现多少BUG，开发修改多少BUG，遗留多少BUG。如果通过公司的运营了解到，用户也出现了遗留BUG中的问题，那更好。通过数字让公司认识到测试的重要性，那么以后BUG的修复工作就更好进行。
公司制度-----在国内以前测试员的绩效考核往往是有开发组长来评分，现在很多公司都做到，通过测试发现的BUG数、BUG严重程度来衡量开发人员的工作水平，这也能促进测试工作的开展
BUG管理平台------目前，国内对BUG管理平台的使用还不成熟，个人见到过口述BUG的、纸制BUG单等等，个人不赞同这么做，口述BUG和纸制BUG单保留时间有限，对于有自己产品的公司，历史的BUG很有参考价值。确定BUG时可以拿出以往的BUG库做参考。
总结，个人只提出一些实际工作中的经验，也建议大家在工作中学习，不要只看大道理，在特定的环境中掌握的技能才是根本。呵呵，以上是自己的一些想法，希望大家都提出宝贵的意见。
文章来源于领测软件测试网 https://www.ltesting.net/