是不是BUG是个问题？

yezhaohui520

不知道你们看懂这个标题的意思了没？ 我转行做了快一年的软件测试了，在测试工作中我发现我以前对于BUG的理解有一个很大的误区，也不知道是不是误区，我原来以为是不是BUG是确定的，就是说是BUG就是BUG，不是BUG就不是BUG，但我在工作中发现并不是这样的，有时一个问题我说是BUG，开发人员说不是BUG，有的测试人员也说不是BUG，有的测试人员又说是BUG，到底是不是没有一个根本的裁决者。比如说吧，你点击一个界面上一个按钮，发现有时会弹出一堆提示，开发人员说你点击太快了，但是我是正常操作啊，客户也完全会以这个速度去点击啊，但是需求、概设、详设没有哪个地方说明了要点击多快。于是一般这样的问题我们公司都是开发占上风，大不了一句：不是什么大问题，改动不划算，了事，要知道类似这样的问题有的也是我们测试人员也是花了精力与时间去发现的。再说如果老这样，很多时候测试人员发现了问题如果感觉不会改就不再提了，那么试问软件质量会不断的改进提高吗？这半年来我总是被类似这样的问题所困扰，希望哪位点拨下，不胜感激！

yezhaohui520

非常谢谢各位的回答，我还以为就是我碰到这个问题呢？看了你们的回答我现在对这个问题有了一个比较客观的认识了，特别是10楼的朋友说的一个bug之所以是bug是因为这个bug涉及的功能受人关注，却实，如果你的BUG一提出来别人都非常认同那肯定就是BUG，因为别人也关注这一点。至于我纠结的问题已经不是是否是BUG的问题了，是我自身处的公司大环境问题，因为公司产品功能错综复杂，没有人对所有业务功能都熟悉的，包括项目经理，如果你提的BUG刚好项目经理根本不了解那一块的功能，可能测试组里有少数熟悉的也认同你的BUG，但是还是要你自己去说服开发，而开发如果没有站在测试的角度或者说用户的角度，就很有可能不认同你的BUG了，于是乎就不改了，就是这么回事。

zhangting85

这么说吧。
一个bug之所以是bug是因为这个bug涉及的功能受人关注（这个关注者可能是项目经理，可能是开发，可能是测试组长，可能是用户，可能是产品经理，总之任何相关人士，甚至有可能算上入侵者，比如入侵者很喜欢你们软件里的某一个漏洞，那这个漏洞也是bug）。

假如没人关注的功能，有没有bug报不报都无所谓。（当然我们一般不能确定这个bug即使现在没人关注，以后会不会有人关注，所以还是都要报）

什么是质量，你的软件在不同人眼里所包含的不同的价值就是质量（James Bach语，不是我说的）
换句话说，有人关注的问题是质量问题，没人关注的问题不是质量问题。

你想想有没有人关注你报的这个bug，这个bug是“一定”会产生严重后果还是“有可能”会产生严重后果，可能性有多少，相关领域的专家怎么说，公司内同类产品是怎么设计的，是否有这个问题，竞争对手的产品是怎么设计的，是否有这个问题。然后把你想的这些写在bug报告里，抄送给可能关注这个bug的人。还是那句话，假如没人关注这个问题，报或者不报就都没意义了。

楼主你说的那些不会改的问题，基本就属于没人关注的bug，假如有那么你可以借助关注这种bug的人的力量来说服开发进行修复。


另外一种情况是考虑到风险和成本，某些bug就会暂时不改了。这种情况一般会在项目组空下来的时候或者以后的版本中渐渐修复。

楼主你这个问题很好，这是测试的五个基本问题之一的oracle问题。你可以搜索一下cem karner的视频讲座，里面有详细的展开来讲这个问题。

rogerliu0303

做测试估计都遇到过楼主的问题。

首先我觉得楼主理解的没错，BUG就是BUG。
那么，为什么我们测试觉得是BUG而开发又说不是BUG呢。这里面的因素相当之多。
同一个问题，在不同的阶段，其定性是不一样的。
比如，对话框字体奇丑无比这种问题，在项目初期你提出来，它肯定是BUG ，因为开发没有压力，肯定会改。但如果在项目尾期，你把这个问题提出来，那么开发多数不会改，因为要赶进度，而且产品已经发布多个版本了，在这个阶段下，除严重功能性问题外基本不修改其它问题，避免引入新问题。所以它又不是问题了。
楼主何必纠结这个问题？
开发测试抱团打天下，我们都是为了产品。
是不是BUG这种问题无需计较。

zgzhmh

缺乏统一的机制

微笑流淌

感觉好像见过这个贴子里举的例子……
提不提是测试的事情，改不改则是开发的事了。
提交上去后，如果开发认为不是BUG，则让领导来决定或研计决定
这样的事情如果多了，应该会知道大概的尺度，但也应该坚持自己的原则！

楠族开心果

bug很多时候还是需要协商的，如果时间紧急，一般很隐蔽的bug也没多余时间修改的

msnshow

要有标准

千里

统一一下就好了

archonwang

缺乏bug的定义规则以及争议处理的机制。完善一下。

愚人

bug包含在需求、概设、详设，代码中……
对于某些争议的bug并不应该完全由开发说了算，要讨论决定……
当然这种问题最好还是有测试负责人（经理）去解决，单是靠下面的人很难推动……