测试如何更有效说服研发去修改bug？（08-10-27）（获奖名单已公布）
测试过程中一些bug会被研发认为是无效bug,但从用户角度出发，测试认为该bug需要更改，此时测试如何更有效的说服研发去修改bug?感谢会员3ming3ming提供此精彩问题！如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！
获奖名单奖项获奖名单奖励答案链接一等奖sun_0910当当购物卡50元21＃二等奖吴如领300论坛积分46＃zengyixun85＃
三等奖maguschen100论坛积分
8＃
超越自我7＃
dulong38＃
hailan198760＃
这种情况确实存在，很希望看高人指点！！！ 项目经理施压。
需求+说服
我的经验不多，不过对这点倒是深有感触！在程序员做好程序的时候，我们首先看的是需求，所以我们首先是作为用户去了解这个系统，如果我们觉得对用户是bug，首先用需求去说明问提，假设不涉及到需求，也应该和我们的开发者提出，并说明情况，因为他们是开发的角度看问题，不是应用，系统不是给开发者用的，最终使用者是用户，所以可以说服程序员以用户的角度去思考，去使用这个系统，让他们亲身体验，体会，我们的开发者都是能人，所以我相信他们能够理解，接受！我遇到的情况就是这样解决的。 真正的高手会接受的，就算不接受，他也是会给你讲道理的，至少要能说服你，
至于蛮不讲理的，抱歉，他素质不行，建议公司换人:P
再次霸位置，改天答。
rt。:lol测试如何更有效说服研发去修改bug
首先,要确保自己能重现BUG的过程;(要真正能模拟到该问题的存在)其次,要将系统出现BUG给用户带来的影响要逐一解释和说明,让开发人员真正了解问题的所在,也节省开发人员的时间,
并分析系统存在瓶颈会引起更多问题,
再次,也要分析修改BUG后,将会带来什么问题,用户是否可接受?并要把修正BUG所引起的问题减少,
而不是增加另外的BUG,而通过自己对系统的熟悉程度,开发人员
也会对测试人员提交的BUG引起足够的关注度和重视,从而让BUG彻底解决,
最后,通过开发人员对BUG的修正,自己也进行一次回归测试,让开发人员觉得测试人员是对质量的负责,而不是针对开发人员,以便利于下一次问题的提交和修正!
总之:测试人员是对产品质量,而不是针对某一个人,而且也要把BUG及时提交,不要错过提交BUG的最佳时间,
因为BUG越不解决,积累的问题越多!
所以测试人员要对发现BUG要有信心和足够的时间重现BUG,让产品更具有质量性!
[ 本帖最后由 超越自我 于 2008-10-27 17:43 编辑 ] 1.把自己的Bug Report完善；有时候开发看到一些莫名其妙的Bug Report会很生气，这样首先就影响了你在他心目中的印象，要让别人改正，首先要保证自己是正确的、完善的。
2. 对事不对人；找开发的时候应该针对具体的问题，可以用“我们的软件出现了这样的问题”，而不要说“你这里写的不对”。
3. 摆事实；对于具体的bug，可以给开发说明一些事实，例如某个样式问题其实十分影响用户体验。
4. 挖历史；如果以前有类似的问题，可以把那个问题，以及造成的后果给开发阐述一下。
5. 平时跟开发拉好关系
6. 把更高层的人拉进来；很多时候都是公说公有理婆说婆有理，这时候就需要一些第三方的同事来帮忙，这个人通常要是能说事的才行，例如研发总监或者项目经理，但是主要不要让人觉得狐假虎威的感觉，这招不适宜经常用。 zhanwei 软硬兼施，内外兼修，综合治理。
让自己的bug有足够的说服力
首先得从自己身上开始着手，确保自己bug的描述有足够的清晰度和说服力 —— 描述的模糊不清一塌糊涂的bug，谁也不会想去改的。其次，如果上述那一条已经符合的前提下，自己费劲心力还是没办法让开发人员接纳修改的话，求助测试组长 —— 一般测试组长都是比较有经验也比较有威信的人，说出的话份量会不一样。
如果测试组长单独找开发人员还不能解决问题，那没办法，就只能让测试组长去找项目经理谈判，规范bug处理过程了 —— 也就是形成制度，不遵守采取惩罚措施。
让开发人员认清BUG的影响
有些BUG在研发看来根本不是什么问题，但是对客户可能造成比较大的影响，比如一个按钮的位置，开发人员已经习惯了操作，很容易找到，但是客户做完一步操作很可能不知道下一个操作从哪里入手。还有些其他的，比如可能造成数据问题的，那会造成更大的后果，一定要跟开发人员解释清楚对客户造成的影响。 感觉之所以提出这个问题，是因为公司的体制根本就不完善。测试人员的职责是测试，研发人员的职责是研发，测试人员提bug，研发人员改bug，谁赋予了测试人员去督促研发人员修改bug的权利了？测试人员又有什么义务去督促研发人员修改bug呢？
之前跟一个在NEC工作的哥们聊过，在他们单位，测试人员是不直接跟研发人员打交道的。测试和研发中间有个中间角色，我们暂称其为bridge。测试人员的bug提交给bridge，bridge鉴定其是否为bug，是bug，流转给研发，不是bug，驳回给测试。同样道理，研发人员如果reject，也是由bridge与其交流。当然，bridge不是随便抓个人就可以当，级别得相当于“技术总监”吧。
当然，目前接触的好多单位都把这个角色省掉了。一个产品或者项目的测试可能总共也就2-3个人，怎么舍得派这么个大牛给大家呢？所以题目描述的问题又是一个不得不面对的事实。
从我的经验来看，出现这样的情况通常不是一些重要的bug，所以测试人员应该尽量将自己的bug描述的细致清晰，然后将bug转交给项目leader处理或者留在评审会时讨论，而不应该跟研发人员在这个问题上做过多的争论，这样一来耗费时间，而来会影响在后续工作中的合作。
研发人员因为在开发技术上的优势，常常会对测试存在一定偏见，测试人员应该能够认识并理解这一点。 回答的很有道理，值得借鉴，谢谢了啊 我认为处理类似的问题，测试人员应该从3个角度去考虑：
第一，从技术角度去分析bug引入的原因，修改bug得成本有多大，从技术角度去判断这个bug修改的可行性，是否需要修改。
第二，从应用角度去分析这个bug，bug得存留会对用户造成多大的影响，是否可以从别的角度给与客户解释并获得客户的接受等等。
第三，此bug在该项目中所处的位置，是在影响项目周期的关键路径上吗？是在项目初期，还是项目后期发现的bug?
有了前面三项的分析思考之后，我想，大部分测试人员都可以比较容易的与开发人员达成共识了，只要大家始终坚持一点，大家都是对项目负责，而不是对某一个人负责。
当然了，一个合格优秀的bug report，一个可复现的bug是任何bug得基本要求。
最后，当测试人员做到了以上三点，还是很难跟开发人员达成共识，这个时候，就需要借助第三方力量了。我个人的处理习惯基本上是：
如果我认为这个bug更多的是从技术角度考虑，需要修改的，那么我会把SA引入到对这个bug得判断上来，由SA决定这个bug是否需要修改。
如果我认为这个bug更多的是从用户角度考虑，需要修改的，那么我会把CS引入到对这个bug得判断上来，由CS给出这个bug是否需要修改的建议。
最后，如果说这个bug得发现是在项目的敏感期（大部分都是项目后期，接近release的时候）f发现的，那么我会直接找到PM，告诉PM这个bug得相关情况，然后请PM决定是否需要修改这个bug. 看贴，顶下。
[ 本帖最后由 ersdfer 于 2008-10-28 06:59 编辑 ] 我们公司是这样的：
一切从用户需求出发，避免与开发人员直接争论。测试人员自认为是用户的需求，是否真的是用户的需求，以需求文档为准；如果需求文档中没有或与需求文档不符，应由项目经理（或需求调研人员）裁定，这样才能使开发、测试人员服气。 是不是BUG，首先需要一个很明确的需求或经过评审的测试文档。单靠主观因素去判断是不准确的，不负责的。
但是，目前国内的软件公司，真正能提供完善需求或严格遵守评审流程的寥寥无几。这时候，最需要的是测试人员主动，积极与开发交流沟通，交流可以提高我们对业务的了解，把握项目的进度，增进与开发之间的关系，这样在出现问题时，我们与开发之间能够更轻松的沟通，能更快的就某些问题达成一致。
下边是需要测试人员注意的地方：
1。有些问题在我们看来是BUG，但在开发看来，那个地方并不是他们关心的。
2。有些时候我们测试人员没有准确的描述BUG及危害，至使开发reject。 坐下 慢慢看 :lol
测试如何更有效说服研发去修改bug？
好久没上51Testing上答题目，谈谈自己的一点看法：1. 扭转研发领导的思想，提高研发人员的响应速度：
a). 让研发团队的领导重视缺陷：
很多研发团队的领导都是销售出生，懂技术的很少，他们和搞技术的想法明显不一样。我在的第一家公司，发布版本时很多时候，都是没有测试结束，功能开发的差不多就把产品卖掉了，后面再对版本不断升级，结果这个公司没多久大概3年不到就散伙了。后面一家公司的领导是做质量管理出生的，明显对测试的质量要求就不一样，每次要求都特严，对以前测试结束标准都做了进一步的修改。如果领导对缺陷都视而不见，你说研发人员还愿意花大量的力气去修改Bug吗？所以说，团队的领导的想法或意识，对缺陷是否修改起到非常重要的作用。我记得以前测试高手zhuzx也在每周一问中提到过，大家也可以借鉴一下。
b). 采用常用的缺陷管理工具（QC9.0），提高缺陷的透明度：
我们公司使用缺陷管理工具（QC9.0）,测试经理任管理员，给公司高层领导、项目经理、开发经理都分配了权限，自己可以登录系统查询相关信息。在测试后期，特别是要发布版本前后，领导们一有空，也随时上去浏览一把，无意识给开发人员施加了较大的压力。如果这个时候还有很多Open的缺陷，开发人员自然不敢怠慢。
c). 把开发人员的修改缺陷的响应速度，记入绩效考核内容：
由于公司总监特别关注产品质量，我们公司对缺陷修改这一点做得比较好，每次都是递交缺陷以后，开发人员响应特别快。如果有疑问，就马上和测试人员一对一交流，尽快修复或解决该缺陷。 我们公司的口号是：“宁愿花出100倍的代价，也不让发现的缺陷留给客户”。还有一点就是开发人员绩效考核的时候，我们测试人员要给开发人员打分，很重要的一点就是：开发人员对测试缺陷的响应速度，如果这一项很低的话，老大要找你谈话的，问具体原因是什么？呵呵。所以，我们公司很少有测试人员追着开发修改缺陷的情况，把修改缺陷的响应速度纳入个人绩效考核，我个人觉的是一种比较好的方式，值得借鉴或推广。
2. 组建一个合理的研发团队，规范测试规范：
a). 关键是建立一个完善的研发机制：
在大多数情况下，是不是软件缺陷或者需不需要修改，怎样修改不是测试人员和开发人员说了算的，应该是靠研发部门的相关制度或相关部门去约束。毕竟在国内软件的软件企业缺少这样的部门，所以说把修改缺陷相关的重任推到了测试人员的头上，其实对测试人员实在是太不公平了。要解决这个问题，最关键就是建立一个完善的研发机制，让QA等相关部门督促解决这类问题，比较好。
b). 分清团队成员的具体责任：
对于研发团队中的每个成员，必须责任明确，否则像督促缺陷修改这样的事情本来不是测试人员的责任，现在都推到测试人员头上了。很郁闷！！
c). 完善测试规范，明确Bug管理制度：
大部分的公司，都没有单独的部门来单独管理督促缺陷是否修改，都默认为是测试部门的事情。个人觉的最好是赋予项目组中相关人员一定的资质，让他们去处理这些琐事。经常碰到这样的情况，很多争议的缺陷都一直放到后面一个版本，一段时间下来，几个版本争议的缺陷就多于100个，弄得后面版本也不好发布。我们的做法是，发布前几天，对每个争议的缺陷用邮件先发给项目组成员先看，后面在召开缺陷评审会议，如果通过，毫无疑问修改，否则关闭或保留到下一个版本。
3. 从源头上杜绝无效缺陷的递交：
a). 测试前细化测试需求,避免递交歧义缺陷：
很多研发不愿意修改的缺陷，大部分都是由于需求不明确或者理解歧义引起的。所以，最好的做法是在测试以前，开个项目会议，细化一下测试需求，让研发去确认或项目组成员集体Review，达成一致观点。尽量减少理解上的歧义，力争尽早消除无效或争议的软件缺陷，避免递交的缺陷成争议的缺陷。测试人员无法说服研发，让研发去修复缺陷，长期这样，测试部的威信就大大降低了。
b). 把握不准的缺陷，递交以前最好讨论一下：
特别是在测试初期，由于测试介入项目时间较短，有时候测试人员对业务或需求了解不深，递交错Bug也是常有的事情。这个时候，往往测试认为自己递交正确了，开发人员认为自己开发软件是对的，互不相让，如果处理不好，很容易弄僵关系，弄得大家都不是很愉快。要是项目中出现这样的Bug，是很难说服研发去修改的，还有可能成为研发抓你的“小辫子”的有力证据，要是这样以后就更难做了。个人的一些做法：所有的测试缺陷相互审核后，才递交到缺陷系统上公开，是最为保险的方法。
c). 清楚无歧义的描述Bug，减少随机测试，带来不可重现的Bug：
很多时候，测试人员把缺陷描述不清楚或者缺陷有歧义，开发人员看不懂，不明白具体的意思，加上开发人员任务重时间紧，很容易产生逆反心里，这就让开发人员对测试人员有看法，以后递交的缺陷认可度就大大降低了。还有就是要减少随机测试，一定要保证递交的缺陷能够重复出现，最好要有截图、图片或者用数码相机照下来，让开发人员认识到这个问题确实存在，并且更具说服力。
d). 做好版本配置管理工作，保证测试环境的准确性：
很多同事发现的缺陷，只有在测试环境下重现，而在开发环境下不能够重现。这样的缺陷开发人员往往是看不到的，他们很容易得出结论，说测试人员递交无效的缺陷而被拒绝，大部分情况发现是版本弄错啦！！我们唯一能做的就是做好源代码的配置管理工作，保证测试环境版本的正确性和独立性，自己编译自己部署测试环境。只有这样，才会减少无效缺陷的递交，避免“费劲周折”说服开发人员修改缺陷。
4. 正确分析测试中的软件缺陷：
a). 为递交的每个缺陷准备几条充足的理由：
一般情况下，我们提到一个Bug时，开发人员都会说出很多可以不修改缺陷的理由，尽量搪塞住我们的口，要求我们关掉缺陷或者置为无效或者延期到下一个版本。如果你很牛，你可以为自己递交的每个缺陷准备很充足的理由去说服开发人员；如果你不是太强，那就可以求助部门同事，集中测试部门团队的力量，想一些好的、站得住脚理由，详细介绍给研发人员听，只要我们递交的Bug，每个都具说服力的话，我想他们也会尽快修改的。这种方法还真是不错，大家不妨试一试。
b). 详细分析缺陷给项目带来的各种可能影响或缺陷风险：
比如说，我们递交一个缺陷，如果研发的觉的这个缺陷可以修改或可以不修改时。我们一定要给研发分析修改这个缺陷的必要性，不修改，对客户带来哪种可能影响或存在哪些风险。要在修改缺陷的代价与修复成本的关系上去衡量。相信，当我们对缺陷分析的很详细时，研发人员一定会修改Bug的。
5. 做一个聪明的测试工程师：
a). 注意和研发人员的沟通技巧：
如果测试人员没有做过开发工作，理解也许就比较片面。有的测试人员，对待问题没有耐心，性情比较急，也是常有的事。如果没有较好的沟通技巧，也许就是几句话的功夫，就和同事争吵了起来，弄得大家都比较尴尬。个人建议：谈话时，要注意沟通技巧，要有换位思维的方式，做事情对事不对人，处理事情一定要有一颗宽容的心。只有这样，才能够很好的说服研发去修改Bug。
b). 和研发人员搞好私人关系，做研发的听众：
比较明智的测试人员，一定要学会倾听研发人员的心生。很多时候，开发人员碰到工作困难的时候，很希望和人倾述，如果测试人员是他的听众，那么你们的关系一定会不错。搞好了私人关系，工作中你递交的缺陷，他们就不会那么斤斤计较了，毕竟关系是基础，关系好了好说话呀，在中国就是如此。如果私人关系好了，说服研发修改Bug就是很容易的事情。不过得提醒一句：不能因为关系好就把Open的缺陷给关了。
6. 抓住时机，不要错过千载难逢的好机会：
a). 求助公司上层领导：
很多时候，测试到后期，开发人员把缺陷也修改的差不多了，公司领导（比如说老总、总监、项目经理或开发经理）就会随时来测试部门，找测试经理或负责人了解项目测试的具体情况。如果有一些问题都是争议问题，作为测试Leader的你不妨给领导聊聊，把更高层的人拉进来为测试部门说话，为测试部门撑腰，但是凡事都有一个度，不能太过分，否则很伤同事的和气。
b). 要求客户代表援助：
很多GUI的缺陷或可改可不该的缺陷，可能作为客户使用不是很方便。我们可以和客户代表聊聊这样的缺陷，如果客户代表同意这样做，那没问题，可以不修改；如果客户不同意，他自然会直接找项目经理或高层人员协调解决这个问题，这就不用我们测试人员操心了。因为客户就是上帝，这招不错吧！！！
我目前想到的就这么多，希望同行指正！！！
[ 本帖最后由 sun_0910 于 2008-10-31 17:37 编辑 ]
