如何处理开发不认可的bug

加点油

Sample Text我面试的时候，问的问题，当时没有回答好，事后自己总结，好像是考虑你对bug的态度，首先自己确定这个是bug，并且坚持自己的意见，2是找项目经理或者技术经理来定夺这个到底算不算bug。大家说我想的如何？请高手给指点一下。

slide

有两方面的含义吧：
一方面是避免和开发进行正面的冲突，要和开发保持一个比较温和的关系比较有利于测试的工作，良好的沟通能力是测试人员必备的素质。
另一个方面，确认故障要有理有据，这样才能对事不对人，根据规范内容和故障判断准则来确定是否故障以及等级高低。
但实际情况中，很可能没有明确的规范来用于判断故障，或者开发人员不认可你的理由，这时候就需要把矛盾转移，往往要由具有权威的第三方，也就是你说的经理等来决定。

作为测试人员，要坚持原则，也要注意一些沟通技巧。

hubanmao

按需求走呗
再者,根据你客户的需要,,比如你编个具备计算弹道能力的软件,其实客户就用2位数加法,而bug出现在复杂计算上,我估计开发打死也不给你改

jihuli5

先自己确认一下是否为真正的BUG，如果是看有多严重，对于比较严重的BUG，可以和开发人员约个时间，把BUG重现给他，并说明BUG的严重性和修改后对开发人员本身的好处，如果还是不行的话，那么就找到自己的上司了。

Jimmyshao

公司应该有处理不同类型bug的标准流程的。。
按照流程走就可以了。。

tottawang

如果开发不能重现,那就把bug描述再具体点,甚至avi
如果是需求上的问题,都要通过PD来定夺.

siny0515

首先一定要坚持自己的观点，确认就是一个bug。因为开发的同学，往往来看这个bug的时候，他的第一想法就是肯定是你做了什么误配置，或者你理解有误，这个时候要是你立场不坚定，结果就是你“妥协”了。好的测试人员是能够说服开发人员承认bug并且修改bug的（这是我们测试部头最爱说的一句话）。
争论不过，就要求看设计文档和需求文档，看看到底这个地方是不是如同开发同学说的，这个不是bug，就是这么实现的，如果开发解释说是缺陷，那么一定要看到缺陷列表以后才能善罢甘休。
还有拿业界中该软件实现的功能说话（也就是权威机构的软件),比如网络设备就是思科最大，很多时候思科就是标准。
以上都不行的话，那么要求组织评审，请专家评审一下到底是不是bug

教你一招，一般出现bug的时候，先不要向开发说这是bug，应该先问一下开发，如果这样操作得到什么结果，开发告知的结果和你测试的结果不符合，没什么好说的，bug。这个开发也没有办法和你辩解了^_^

当然争论是需要技巧的，切记在争论过程中说一些讥笑别人的话，口气要很诚恳，而且要学会用客户来压制开发人员，这招很灵的。态度一定要和蔼，一定要有亲和力^_^

firemonth

坚持不放过BUG的原则。级别高的，分析后果，说服；级别非常低的，导致开发不认可，上提。

Joan2005

我们公司一般都是测试发现BUG以后，直接交于负责修改的开发工程师，没有通过项目经理讨论确认是否是BUG再交于开发修改的环节（我们只有一个主管，几乎对下面的工作不闻不问，只出了问题的时候才关心一下），有了争议的BUG后，我们再演示BUG出现的过程，有时BUG难以重现，只能把自己的操作仔细的将给开发听，他们会再检查出现问题的代码部分的。做到有理有据，双方都认可后，都会进行修改的，一般不做修改的也是那些很小，不影响使用的BUG。

null2

按流程走

lq810425

可是很多公司都没有规范的流程、连需求说明书、测试用例都没有，只有所谓的缺陷报告，这种情况下又该如何处理呢？我上周去面试的时候也被问到这样的问题？还有如果在开发过程中，需求进行了变更，那又该怎么办呢？
我是这样回家面试官的：自己反复测试，确定这个部分是错误的，并且能够重现的，把缺陷操作给开发人员看，如果开发还是认为这个不是缺陷的话，就提交缺陷报告。

xemeny

认真对需求进行分析，测试的服务对象是用户

chinacat

这种问题我也碰到过的。一般我是这样处理的。
1.首先看bug能否重现，能重现的，一般开发都会改的。
2.没法重现的，再来分析，这个bug产生的后果，是否在可以接受的范围内。若可以，这次不修改，备案，平时注意，留待下次修改。
3。若不在客户可接受范围内，即不符合最新需求，确定必须修改，然后和开发一起努力，尽可能详细的说明你的测试方法，让开发尽可能的减少代码的查看范围，减少debug范围。

一般这样都可以解决的，我一般都不会到上级去决定的。

xu_yongchao

哎
这个问题上次去华为面试的时候也被问到了,我是这样回答的不知道怎么样啊
一方面是避免和开发进行正面的冲突，要和开发保持一个比较温和的关系比较有利于测试的工作，良好的沟通能力是测试人员必备的素质。
另一个方面，确认故障要有理有据，这样才能对事不对人，根据规范内容和故障判断准则来确定是否故障以及等级高低。
但实际情况中，很可能没有明确的规范来用于判断故障，或者开发人员不认可你的理由，这时候就需要把矛盾转移，往往要由具有权威的第三方，也就是你说的经理等来决定

liangyi2208059

在软件测试中，一点鸡毛大的小缺陷软件开发人员都不屑改正。头痛哦~~~！

walker_lai

又是流程的问题啊