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

场景:

测试中,我们经常遇到这样的问题,提交了个bug,开发却回复won't fix ,竟然说不是bug

什么bug会让开发认为不是bug?

1、测试人员描述不清晰

体现在步骤描述上有歧义,开发无法按照描述准确的复现步骤,导致可能对问题的描述理解上出现偏差

解决方法:修改bug描述步骤:做到清晰描述、无重复、无冗余,尽量附截图,截图重点位置,用红色标记,截图名字尽量符合截图内容

2、难以复现的bug

有的bug是偶现bug,难以按同样操作步骤复现&有的bug只是在测试环境出现,线上就正常了

解决方法

难以复现的bug:保存截图和log;尽可能详细的描述进行过的操作,像我们之前测试的棋牌的项目,经常出现卡死,这样的要提供4个玩家的log,因为无法确定是否是其他玩家进行的操作,引起的bug,这种我们就尽量用真人去玩了,更容易发现问题,机器人的话,无法提供机器人log日志

测试环境下出现bug:找研发在测试环境下确认,报告中指出风险

3、有争议的bug

多出现在建议类型的bug,测试人员在测试过程中会对根据经验或者对比竞品提供一些优化的建议,这e类bug特点需求上没有详细给出,肯定开发是没有做的

解决方法:是否需要修改要根据项目的实际需要进行确认,开bug评审会,讨论解决

在时间允许的情况下,项目测试收尾时,对buglist是否修复进行明确处理;时间比较紧产品又认为有修复必要的情况下,可能会延期到下期

4、功能性bug

与需求不符、与原型设计不符。开发对需求没有深入了解可能会忽略或者弄错功能;开发成员之间沟通上的偏差

解决方法

提bug时把需求、设计相关内容截图,指出依据,避免麻烦

5、当然也会有误提的情况

测试人员对需求理解不明确、出现偏差;环境错误

解决方法

反复理解需求、确认需求和环境

 

转载于:https://www.cnblogs.com/prince365/p/10551411.html

开发人员不认可一个 bug 或者不同意其作为一个真正的 bug 时,处理方式可以根据具体情况而定。以下是一些可能的处理方式: 1. 澄清需求:开发人员可能会认为bug 是由于需求不清楚或者不准确导致的。在这种情况下,你可以与开发人员一起仔细检查需求文档,确保对功能的理解一致,并修正任何可能引起歧义的地方。 2. 提供更多信息:有时候,开发人员可能认为 bug 报告中的信息不足以重现问题或者确认其有效性。在这种情况下,你可以尝试提供更详细的信息,例如复现步骤、屏幕截图、错误日志等,以帮助开发人员更好地理解和解决问题。 3. 沟通与讨论:如果开发人员对 bug 的存在性持有不同意见,可以进行进一步的讨论和沟通。你可以通过会议、邮件或其他沟通渠道与开发人员交流,解释问题的重要性,理解他们的观点,并尝试达成共识。 4. 跟踪和优先级管理:如果开发人员坚持认为bug 不是优先级较高的问题,或者他们认为可以通过其他方式解决,你可以与开发团队一起讨论并确定该 bug 的优先级。在这种情况下,可能需要在 bug 跟踪系统中记录该问题,并在合适的时候重新评估其优先级。 最终,处理开发人员不认可的 bug 需要通过有效的沟通和协商来解决。重要的是保持开放的态度,尊重并理解开发人员的观点,并寻求达成共识的方法。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值