我们公司一般提交的bug开发都会改的，不管是不是个bug或者有歧义的一般都会注明原因的，所以不存在测试和开发之间为bug而产生矛盾的！如果提交的bug开发迟迟为改，那么上patch或者上一个新的版本就不能通过，必须等开发改完所有的bug后才会安排上线的！
回复 21# 的帖子
貌似大多数人对这种长篇大论不感冒吧............我晕，来不来就给我投3课蛋，貌似这文章我见过，我去找找，看能不能找到...3个鸡蛋....让混不了？？？
[ 本帖最后由 89757 于 2008-10-29 18:23 编辑 ] 偶喜欢21楼的帖子，很详细，很具有参考价值或指导作用，顶一个！！！ 原帖由 yetties2005 于 2008-10-29 16:46 发表 http://bbs.51testing.com/images/common/back.gif
主要还是沟通吧.说服开发...用语言压迫他们,哈哈...
自己的BUG要定义明确.告诉自己那是个BUG.跟开发谈的时候别人家一说什么你就想这到底是不是BUG啊,是不是自己错了.千万别有这样的想法,就算有,也不要在跟人谈的时 ...
用语言...貌似没什么作用吧，你要真正说服他，必要的时候，让他复述下.... 由于开发人员和测试人员对需求的理解存在的差异，以及各自的工作角色，关于BUG的争论在日常的项目中是经常遇到的，如何保证BUG及时修复，非BUG不影响项目的进度至关重要。
让开发心甘情愿的修改BUG，我们可以从下面几个方面来考虑：
一、为什么定为BUG
[*]BUG描述------测试员在提出BUG时，要注意对BUG进行必要的描述，例：BUG出现的环境、出现该BUG进行的操作、预期结果和实际结果、BUG出现的几率，如果使用的BUG管理工具的允许，可以对该BUG添加一些附件：截图、脚本等，Jira、Lotus好像都可以添加附件。一方面增加开发对BUG的阅读、定位，另一方面能通过有利的论据证明该问题是BUG[*]BUG复现------提交BUG后要保证BUG复现，这样在项目经理、测试经理、开发人员争论BUG时，能强有力的证明该BUG是存在的。[*]BUG依据-------理论上，产品中不满足用户提出的需求就可以定为BUG，这也是测试前期进行需求评审的原因。但是，目前很多公司的软件项目对其中的细节描述很不具体，导致了开发与测试关于BUG的歧义。在定BUG的时候我们可以本着这样一个原则：和当今流行产品做对比，比如说公司在做个搜索引擎，开发将搜索引擎的位置放在页面的底部，我们就可以说这是一个BUG。理由很简单，百度、google的搜索框都在页面的上部。二、测试经理对BUG的认同
[*]测试经理的经验-----测试经理一般来说都是工作几年，有相当丰富的项目经验，我公司测试人员提出的BUG，一线的测试经理都要审核，审核通过才转到项目经理，这样避免了由于测试员工作经验不足和个人主观意愿导致BUG错误认定的情况。[*]测试经理的信赖-----测试经理对BUG认同后，也就说明了该问题是BUG，在后续的争论中不会出现测试经理搪塞的情况，对测试人员也是非常有利的。三、有效的沟通
[*]"牺牲色相"-----该方法要求测试人员为了工作，主动和开发建立良好的关系。譬如：请开发吃饭等等，这种方法最有效，也是百试百灵。但个人不建议这么做，工作就工作，耍手段是不好滴。[*]"良好的同事关系"----这种方法要求测试和开发平等的地位，测试要本着"我的工作职责就是让软件运行的更好"，通过合理的沟通手段，让开发能认同自己的观点，并进行BUG的修复。不要因为自己对技术了解不如开发深，就不敢提问题。[*]"强调BUG的影响"----沟通中提出修改BUG带来的好处，不修改BUG将要导致的问题，让开发明白问题的严重性。那怕是用户体验的BUG，也可以借助用户的场景，说明修复BUG的必要性
四、利用身边的资源
[*]上级领导-----借助测试经理和项目经理，有时候个人不能协调解决的问题，就不要逞强，让测试经理和项目经理来协调，切忌不要悄悄的在项目经理面前说开发的坏处，大家都是打工的何必呢，况且不一定能起到作用。要记住--自己找项目经理和测试经理是协议矛盾的，解决问题的。[*]部门例会-----很多公司，每周或每月都会进行部门例会，方便各个部门间交流沟通，可以由测试经理反映下最近测试情况，测试员发现多少BUG，开发修改多少BUG，遗留多少BUG。如果通过公司的运营了解到，用户也出现了遗留BUG中的问题，那更好。通过数字让公司认识到测试的重要性，那么以后BUG的修复工作就更好进行。[*]公司制度-----在国内以前测试员的绩效考核往往是有开发组长来评分，现在很多公司都做到，通过测试发现的BUG数、BUG严重程度来衡量开发人员的工作水平，这也能促进测试工作的开展[*]BUG管理平台------目前，国内对BUG管理平台的使用还不成熟，个人见到过口述BUG的、纸制BUG单等等，个人不赞同这么做，口述BUG和纸制BUG单保留时间有限，对于有自己产品的公司，历史的BUG很有参考价值。确定BUG时可以拿出以往的BUG库做参考。
总结，个人只提出一些实际工作中的经验，也建议大家在工作中学习，不要只看大道理，在特定的环境中掌握的技能才是根本。呵呵，以上是自己的一些想法，希望大家都提出宝贵的意见。 用户第一！有问题当然要改正！！:)
扔鸡蛋友情提醒
建议：各位朋友扔鸡蛋一定要慎重，每个人有自己的看法很正常，不要动不动就给高手扔鸡蛋。本来现在答题目的高手就很少了，要是老是扔鸡蛋，估计后面也不会来答题了，为了我们共同学习的目的，恳请大家学会容忍，做一个文明有礼貌、有道德的测试人！！ 48楼朋友的话，很中肯，赞成！！ 纯占位置sun_0910牛人，送给你的鲜花可以看出喜欢你的人还真不少！！
希望您以后多出来答题目，哈哈！！！ 望大家不要讨论扔鸡蛋是事了，就此打住吧！！答题目才是主要的！！个人观点，仅供参考：
让测试人员去说服研发去修改Bug，本来就不是一件正确的事，并且也不是测试人员该干的事情，现在倒像是测试人员的责任了呢。该题目的讨论，是否起到了误导作用？？？？？？？
欢迎大家发表自己的意见！！！！
软硬兼施
这种情况经常会出现，我的经验就是软硬兼施，在实际工作中也是比较奏效的，具体是这样：1.软跟开发搞好关系，偶尔一起吃饭什么的，不用特意去怎么做，不过经常是微笑的面容容易让人家记住你并对你有好感，很多时候出现BUG去跟开发沟通的时候，他们大多不会好意思拒绝.
2.硬一个两个BUG的，考虑到开发的工作紧张程度，在合适的时候追一下，如果BUG堆积比较多，开发有推托的嫌疑的时候了，这时就要硬了，请召积开发和测试，开发老大一定要叫上，开会，把所有的BUG一起都拿出来，然后跟他们老大讲明历害关系，并请他去跟踪，当然这时候，也要拿出测试的水平来，BUG重现步骤、BUG描述都要准确，BUG的分析也尽我们可能的写出来方便开发了解，一般这就不由得他们不改了
以上是我在工作中的一点方法，抛砖引玉. 这个问题一直困扰不少当前在前线奋战的战士们，中国人做事，凡事都得讲依据，没有依据很容易被拒绝。
首先对自己从客户角度看问题确实是个BUG，但也得考度，测试者只是从谋一角度来看是认为是，但没有根据，就会没有说服力，对研发来说他可以是拒绝不是BUG，所以觉得是不是BUG还是从软件需求规格说明书为依据。
其次，如果测试更多的从客户角度去看问题，确实是个BUG，提交又被拒绝，需求上并没有说明，可以向高层反映该问题，得到个解决方案。
以上观点，才粗学浅，如有不对，欢迎各位高手指正。 呵呵，大家被把问题牵扯的面推广
同意楼上的楼上，
是不是bug最终是要有我们测试人员根据需求、从用户的角度及其需求方的意见等去综合考虑的
（1）确实是一个程序bug（测试环境中可以重现）
a、测试人员需要与开发进行必要沟通，这个bug出现原因及出现结果，会影响到用户什么，或是影响到其它功能。最终会导致用户电话投诉，甚至出现外网故障（与KPI挂钩）
b、测试人员需要和需求方一起评估bug的风险
c、测试人员、需求方和开发一起评bug修改的风险
D、最后决定bug是本次修改掉，还是延迟处理
（2）确实不是一个程序bug,有可能是其他的问题导致，譬如测试环境配置导致的（web测试往往是测试环境配置导致的一些非程序bug）
[ 本帖最后由 Jon 于 2008-10-30 13:05 编辑 ] 哈哈 我这一排鸡蛋... :lol 我认为，开发人员说不是bug，有2种情况，一是需求没有确定，所以我可以这么做，这个时候可以找来产品经理进行确认，需不需要改动，3方商量确定好后再看要不要改。
二是这种情况不可能发生，所以不需要修改，这个时候，我可以先尽可能的说出是BUG的依据是什么？如果被用户发现或出了问题，会有什么不良结果？程序员可能会给你很多理由，你可以对他的解释进行反驳。如果还是不行，那我可以给这个问题提出来,跟开发经理和测试经理进行确认,如果要修改就改,如果不要修改就不改。
其实有些真的不是bug，我也只是建议的方式写进TD中，如果开发人员不修改也没有大问题。如果确定是bug的话，一定要坚持自己的立场，让问题得到最后的确认。
2次答题都很精彩
sun_0910，看了你2期的答题，收益匪浅，再次表示感谢！！！测试如何更有效说服研发去修改bug
1 首先要保证我们的BUG报告是完善的，并且每个BUG的描述都是正确的。特别是具体是重现这个BUG的具体步骤。并且要尽量在最早的时候提出。以免到最后增加修复的代价。2 BUG报告中的描述语气要尽量的委婉一点，最重要的是要针对软件所出现的问题，而不是针对某个人。
3 尽量让开发人员做为软件的用户来运行软件，比如自己用到的软件中出现了这样类似的问题，会如何对待。
4 做好与BUG所在功能相关的功能的测试，及类似功能的测试，说明BUG的影响程度
5 如何还是不能说服，那只有找软件项目负责人了，让他出面来解决
注： 测试人员本来就是为了保证软件质量而存在，我们的目标一切都向质量看。平时多与开发人员沟通，相信大家都会做到最好。 高手好多，学习~~~~~
