1.在创建bug的时候,测试可以初步调查下引发bug的原因,将调查的screenshot(例如:日志的截图)添加到bug的详细信息里面,以便开发人员参考;
2.如果之前有类似的bug出现过,也可以将之前的bug附加在bug里面,以便开发人员参考;
3.站在用户的角度上分析bug的严重程度和出现的概率,引导开发人员意识到bug的严重性,促使开发尽快fix bug;
4.如果开发人员和测试仍然无法达成一致,就需要和PM一起进行沟通确认,最终由PM决定。
5.如果遇到上线时间紧张,开发人员来不及进行修改,测试需要分析问题的严重性,然后和PM确认是否进行修改。
6.修改bug 改动较大,影响范围比较广,没有最优的解决方案等情况在项目即将上线的节点比较忌讳这种事情的发生。面对这种情况,建议开发人员做调研工作,请教其他的同事,或者组织一个临时会议,集众人之力研究好的修改方案。
7.如果是第三方应用的问题,开发无法修改。确认原因之后需要找相关的人员,例如PM,第三方的工作人员,反馈问题,尽快推动问题的解决。
总之,bug 修不修,测试应该有一个自己的原则,同时也要权衡利弊。不能因为推不动开发就放弃,由着bug 上线,也不能揪着一个bug 不放,影响上线时间。