开发认为不是bug，你该如何处理？

一、需求不肯定
能够找来产品经理进行确认需不须要改动，三方商量肯定好后再看要不要改。
二、这种状况不可能发生，因此不须要修改
这个时候，我能够先尽量的说出是BUG的依据是什么？若是被用户发现或出了问题，会有什么不良结果？程序员可能会给你不少理由，你能够对他的解释进行反驳。若是仍是不行，那我能够把这个问题提出来，跟开发经理和测试经理进行确认，若是要修改就改，若是不要修改就不改。其实有些真的不是bug，我也只是建议的方式写进TD中，若是开发人员不修改也没有大问题。若是肯定是bug的话，必定要坚持本身的立场，让问题获得最后的确认。
其实参考答案已经很完整了，可是能够看到上面的答案明显是偏向测试人员的，但有时开发说的并没错，测试要站在对方的角度换位思考。因此回答这个问题还能够从开发人员的角度延伸。
（小编只是搬运工，加入了一些本身的经验实践在里面）
分析什么Bug会让开发认为不是bug
一、测试人员描述不清晰
工做中也有测试人员把某些“Bug操做步骤”描述的只有本身看得懂，开发人员按照步骤复现Bug不知所云，搞错了问题所在。
解决方法：
修改Bug操做步骤：清晰描述、无歧义、无冗余步骤，要达到即便给一个不懂的人去重现这个Bug，也能按照你的操做步骤复现。
（重要的是：有图有真相，带有清晰说明的截图比一大推描述来得直观，易懂。注意对问题区域以强调色（如红色）标识，并配以名字说明）
二、难以复现的Bug
不是全部的问题都能用一样的操做步骤来复现的，有的Bug几率出现甚至偶现，或者是只在测试环境里出现。
解决办法：
针对难以复现的Bug，须要保存截图或者记录log保留证据；对于只在测试环境下才会出现的，找研发在测试环境进行确认。这类Bug要慎重对待，规避风险。
三、有争议的Bug
有争议的Bug多发生于建议类型的Bug：与同类软件不符、易用性、美观性等类型的Bug。
解决办法：
这种问题是否要修改须要根据公司的项目类型进行讨论。开Bug评审会，在开发能实现的状况下说出本身的理由，改善产品。
（在时间容许的状况下，在项目测试接近收尾时开一个bug清除会议，对于剩余bug是否修复作明确处理）
四、功能性Bug
与需求不符、与原型设计不符。有时候开发对需求没有深刻了解可能会忽略或者搞错个别功能。
解决办法：
拿证据（需求、设计说明书）给他看，这种bug天然合情合理。（最好在提bug时，就把需求、设计截图带上，天然省去了大多争议，除非开发确实以为设计有问题，须要从新进行讨论设计的）