一般开发人员认为不是bug的，有两种常见情况：需求不确定；认为bug不可能发生。那么针对这两种情况，应该如何与开发人员有效共同呢？
如果开发人员认为需求不确定的bug，那么测试人员需要找来产品经理或项目经理进行确认，需不需要改动，三方商量后再与开发确定是否要修改。
如果是开发认为bug不可能发生这种情况，那么测试人员需要尽可能描述清楚bug的依据，以及bug的不良后果。可能开发人员会给一堆莫名其妙的理由进行反驳。如果双方都坚定自己的立场，那么可以把问题提出来，跟开发经理和测试经理确认，是否要改。如果是确定bug的话，一定要坚持自己的立场；如果开发人员说的也没有错，那么可以站在开发角度换位思考。
那么，为什么测试人员认为是bug的，开发人员认为不是呢？是什么原因造成的，这个测试人员需要了解清楚。针对不同原因bug，测试人员需要不同解决。
测试人员描述不清楚造成的。
这个一般是测试人员把某些“Bug操作步骤”描述的只有自己看得懂，开发人员按照步骤复现Bug不知所云，搞错了问题所在。针对这个，测试人员需要修改Bug操作步骤：清晰描述、无歧义、无冗余步骤，要达到即使给一个不懂的人去重现这个Bug，也能按照你的操作步骤复现。
难以重现的bug.
因为不是所有的bug都能用同样的操作步骤重现，有的bug出现是随机概率的，或者是只在测试环境中出现。针对这类难以重现的bug，测试人员需要事先保存截图或者记录log保留证据;对于只在测试环境下才会出现的，找研发在测试环境进行确认。这类Bug要慎重对待，规避风险。
有争议的Bug.
有争议的Bug多发生于建议类型的Bug：与同类软件不符、易用性、美观性等类型的Bug。这类就需要我们跟项目相关人员进行讨论，开Bug评审会，在开发能实现的情况下说出自己的理由，改善产品。
功能性Bug.
这类bug产生比较常见，也合情合理，主要是有时候开发人员对需求没有深入了解可能会忽略或者搞错个别功能，造成与需求不符、与原型设计不符。这种，测试人员就需要找证据，拿需求或说明文档给开发人员看。
软件测试最重要的是沟通，但是因为不同岗位所在位置不同，考虑的面也不一样，建议在沟通时候多换位思考，毕竟大家的目标是相同的，都是想让产品更高质量提供给用户。
