sun_0910答题目很有水平，赞一个，学习啦！
sun_0910，自从你回答怎样做一个人见人爱的测试经理以后，很久没有看到你答题目了，这次出来答题，真不容易呀，嘻嘻！！！希望您以后多多光临51Testing的每周一问答题。
调整研发人员的心态非常关键
对sun_0910测试牛人的补充，个人认为，很多时候都是开发人员嫌麻烦，懒惰的心态，不愿意修改Bug，而不是说递交的缺陷不是Bug。很晕吧，同行们！！！:'( :'( :'(
谢过21楼的大虾
好经验，值得我们新手借鉴和学习，谢过大虾！！测试如何更有效说服研发去修改bug？
说到这个问题,在我工作的时候会出现这种问题.但很少时候我发现的问题开发的不修改.首先你发现的是问题,能被重现出来的,你有足够的信心和足够的理由.如果开发不修改后,你可以有足够的理由说服它,如果你这种说法他还不修改的话,那也只能找第三者,也就是说是头了,应该是项目经理.
好贴，很值得一读
原帖由 sun_0910 于 2008-10-29 13:14 发表 http://bbs.51testing.com/images/common/back.gif好久没上51Testing上答题目，谈谈自己的一点看法：
1. 关键是建立一个完善的研发机制：
在大多数情况下，是不是软件缺陷或者需不需要修改，怎样修改不是测试人员和开发人员说了算的，应该是靠研发部门的相关 ... 我认为，主要参考需求说明书，大的功能性，肯定能修改。
我认为难点在于程序的强壮性上，可以找相同功能产品对比，描述其严重性。
很好，很强大
很好，很强大，我支持 主要是公司要有一个比较完善的bug管理制度 我个人觉得还是归根到对Bug定义的理解，软件的Bug指的是软件中不符合用户需求的问题，只要把这个问题谈清楚了，说服开发同事修改测试人员提交的Bug也就很明显、直接了。当然了除了用户需求，开发与测试人员间的沟通还是很重要的。:victory: 主要还是沟通吧.说服开发...用语言压迫他们,哈哈...自己的BUG要定义明确.告诉自己那是个BUG.跟开发谈的时候别人家一说什么你就想这到底是不是BUG啊,是不是自己错了.千万别有这样的想法,就算有,也不要在跟人谈的时候出现.还有就是通过需求.说明BUG不改客户是不能接受的.在就是像前面所说的.要软硬兼施，:victory: :lol
和研发人员搞好私人关系，做研发的听众
搞好私人关系,这样做故然好，不过要有个度。因为关系是关系，BUG是BUG不要混在一起，不然会有影响。不过楼上的人说的也没什么不对的 大家多说说可操作性强的例子吧~~~~~ -0-比如某次碰到开发扯皮的时候具体是怎么处理的
测试如何更有效说服研发去修改bug？
我认为首先领导要重视测试，重视BUG，如果有些小BUG连领导都不重视，那么开发人员也会很反感；其次要确定是BUG，并且可以重现；
还要描述清晰，注意沟通；
有充足的理由说明BUG存在的后果和影响；
如果开发人员实在不听，引导他们换位思考，或者从客户的角度出发；
再不行，找项目经理决策。 我觉得这个问题吧，最重要的是需要你找出来的确实是BUG，因为在测试过程中，有些问题是因为开发人员与测试人员对需求的理解不一样，导致测试人员认为是BUG，但是开发人员却不这么认为。所以如果要开发人员修改BUG，那么你一定要能够向开发人员证明这确实只一个BUG，有修改的必要，让开发人员意识到修改的重要性，这样的话他们自然就会去修改了 在测试过程中，发现很多bug都是因为需求不明确而出现的，有些直接是研发人员对需求只做一半，另一半需求未实现，
拿着需求上的东西直接去找研发人员谈，他们会直接说改需求。。。。无语了都
所以觉得重要的是在项目开始阶段就和研发人员确定好需求，没按需求来的都是bug。 据我个人的经验主要是下面几点：
1.bug本身的质量。这个非常重要，如果是严重的bug不用去说服，研发自然会去修改。
2.bug会产生的影响。这个考验测试人员的功力了，并不是要夸大bug的严重性，而是你有没有比开发看得更远。比方说是一个验证框颜色的bug，开发认为可改可不改，但你如果能说出如果用户是色盲就无法看清楚，也就无法登陆，进而无法使用我们的服务，而且中国色盲的人数是多少这么一报，那么他肯定得改。
3.对自己的能力的认同。需要说服的bug本身就存在争议，确实也存在可改可不改的bug，你如果认为确实需要改，就一定得坚持，找到充分的理由，然后在评审中一击必中，确立自己在研发心中的形象。就是说你发现的bug基本上在评审上都需要回去反工的，以后不用你自己说，他们自己就会去改了，也不存在什么说服了。
4.提升自己的能力。如果说前三点是技巧，最后一点可就是基础。开发人员和测试人员都是这样子，双方都有一个比较，让他们觉得在测试这块你就是权威你的能力起码不能比他们差，就算是没参与编码也需要一看就知道大概是他们会是怎么做的，通过少数几个问题即可知道问题容易产生的地方。
总的来说我个人觉得没有说服的bug，主要看你是否有充足的理由，和合理的方法。当然公司的评审制度也需要有，没有这个话完全靠测试个人是不行的。
这个是即兴发挥谈谈看法，没有完全总结几年的经验，欢迎大家的砖头。:) 我这边的流程如下：
1、bug记录QC中，通知研发员进行处理，研发员认为不影响、不是bug的标记为下一版本处理或拒绝。
这时测试人员先对研发员的处理已经修复的进行确认验证。
对于下一版本处理或拒绝的在定期的会议或一轮测试完成后开会讨论处理。
2、对于是bug，但研发员对严重程度与优先程度的标定不认同的，这需要测试人员与研发人员进行沟通，双方阐明问题在功能使用上或技术上各自的看法，这个阐明的过程我们是通过内Q完成，参与内Q的讨论的是项目组的所有人员，包括双方的头头，商务，还有测试跟研发。谈的过程中头头也会发表看法，其实这也相当于一次小的会议讨论。 个人认为，要制定一个完善的缺陷规范比较好！！ 首先要让研发或者开发的同事明确这的确是个问题，不去考虑问题本身的程度如何。
上策：闲暇时间以非正式的形式大家组织大家讨论，这就看个人沟通能力了。大家各抒己见，不但问题可以解决还可以加深同事之间的感情。
中策：“死缠烂打”，要求开发担当修改。
下策：上策行不通的情况下，将问题告知项目经理，由项目经理督促修改。
个人经验，一般这样的问题不修正的理由如下：
1.开发认为问题本身属于可修改或者不修改的情况，考虑到个人负责模块缺陷数量的问题，一般不愿意修改。
2.开发认为根本就不是问题（这样就返回到前提上说的）
3.开发担当懒惰（基本不会有这个现象）
规范公司的部门体系，非常必要
21楼的讲得比较详细，很好！！补充一点：我觉的，测试人员没有必要去要求开发人员一定修改某个缺陷，应该由QA人员去督促吧！！
不知道对不对，让大家见笑了。
