51Testing软件测试论坛

标题: 测试如何更有效说服研发去修改bug？（08-10-27）（获奖名单已公布） [打印本页]
作者: 默默巫    时间: 2008-10-27 10:30
标题: 测试如何更有效说服研发去修改bug？（08-10-27）（获奖名单已公布）
测试过程中一些bug会被研发认为是无效bug,但从用户角度出发，测试认为该bug需要更改，此时测试如何更有效的说服研发去修改bug?

感谢会员3ming3ming提供此精彩问题！如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！




　
获奖名单
奖项
获奖名单
奖励
答案链接
一等奖
sun_0910
当当购物卡50元
21＃
二等奖
吴如领
300论坛积分
46＃
zengyixun
85＃
三等奖
maguschen
100论坛积分
8＃
超越自我
7＃
dulong
38＃
hailan1987
60＃
作者: wtfc    时间: 2008-10-27 11:13
这种情况确实存在，很希望看高人指点！！！
作者: wxm2004734    时间: 2008-10-27 12:10
项目经理施压。
作者: kathia    时间: 2008-10-27 12:49
标题: 需求+说服
我的经验不多，不过对这点倒是深有感触！
在程序员做好程序的时候，我们首先看的是需求，所以我们首先是作为用户去了解这个系统，如果我们觉得对用户是bug，首先用需求去说明问提，假设不涉及到需求，也应该和我们的开发者提出，并说明情况，因为他们是开发的角度看问题，不是应用，系统不是给开发者用的，最终使用者是用户，所以可以说服程序员以用户的角度去思考，去使用这个系统，让他们亲身体验，体会，我们的开发者都是能人，所以我相信他们能够理解，接受！我遇到的情况就是这样解决的。
作者: 89757    时间: 2008-10-27 15:20
真正的高手会接受的，就算不接受，他也是会给你讲道理的，至少要能说服你，
至于蛮不讲理的，抱歉，他素质不行，建议公司换人
作者: archonwang    时间: 2008-10-27 16:37
标题: 再次霸位置，改天答。
rt。
作者: 超越自我    时间: 2008-10-27 17:36
标题: 测试如何更有效说服研发去修改bug
首先,要确保自己能重现BUG的过程;(要真正能模拟到该问题的存在)

其次,要将系统出现BUG给用户带来的影响要逐一解释和说明,让开发人员真正了解问题的所在,也节省开发人员的时间,
并分析系统存在瓶颈会引起更多问题,

再次,也要分析修改BUG后,将会带来什么问题,用户是否可接受?并要把修正BUG所引起的问题减少,
而不是增加另外的BUG,而通过自己对系统的熟悉程度,开发人员
也会对测试人员提交的BUG引起足够的关注度和重视,从而让BUG彻底解决,

最后,通过开发人员对BUG的修正,自己也进行一次回归测试,让开发人员觉得测试人员是对质量的负责,而不是针对开发人员,以便利于下一次问题的提交和修正!

总之:测试人员是对产品质量,而不是针对某一个人,而且也要把BUG及时提交,不要错过提交BUG的最佳时间,
因为BUG越不解决,积累的问题越多!
所以测试人员要对发现BUG要有信心和足够的时间重现BUG,让产品更具有质量性!

[ 本帖最后由 超越自我 于 2008-10-27 17:43 编辑 ]
作者: maguschen    时间: 2008-10-27 17:39
1.把自己的Bug Report完善；有时候开发看到一些莫名其妙的Bug Report会很生气，这样首先就影响了你在他心目中的印象，要让别人改正，首先要保证自己是正确的、完善的。
2. 对事不对人；找开发的时候应该针对具体的问题，可以用“我们的软件出现了这样的问题”，而不要说“你这里写的不对”。
3. 摆事实；对于具体的bug，可以给开发说明一些事实，例如某个样式问题其实十分影响用户体验。
4. 挖历史；如果以前有类似的问题，可以把那个问题，以及造成的后果给开发阐述一下。
5. 平时跟开发拉好关系
6. 把更高层的人拉进来；很多时候都是公说公有理婆说婆有理，这时候就需要一些第三方的同事来帮忙，这个人通常要是能说事的才行，例如研发总监或者项目经理，但是主要不要让人觉得狐假虎威的感觉，这招不适宜经常用。
作者: 阿七    时间: 2008-10-28 00:07
zhanwei
作者: davy_chen    时间: 2008-10-28 09:31
软硬兼施，内外兼修，综合治理。
作者: apron    时间: 2008-10-28 09:35
标题: 让自己的bug有足够的说服力
首先得从自己身上开始着手，确保自己bug的描述有足够的清晰度和说服力 —— 描述的模糊不清一塌糊涂的bug，谁也不会想去改的。
其次，如果上述那一条已经符合的前提下，自己费劲心力还是没办法让开发人员接纳修改的话，求助测试组长 —— 一般测试组长都是比较有经验也比较有威信的人，说出的话份量会不一样。
如果测试组长单独找开发人员还不能解决问题，那没办法，就只能让测试组长去找项目经理谈判，规范bug处理过程了 —— 也就是形成制度，不遵守采取惩罚措施。
作者: creatysun    时间: 2008-10-28 09:54
标题: 让开发人员认清BUG的影响
有些BUG在研发看来根本不是什么问题，但是对客户可能造成比较大的影响，比如一个按钮的位置，开发人员已经习惯了操作，很容易找到，但是客户做完一步操作很可能不知道下一个操作从哪里入手。还有些其他的，比如可能造成数据问题的，那会造成更大的后果，一定要跟开发人员解释清楚对客户造成的影响。
作者: 男孩子    时间: 2008-10-28 11:06
感觉之所以提出这个问题，是因为公司的体制根本就不完善。
测试人员的职责是测试，研发人员的职责是研发，测试人员提bug，研发人员改bug，谁赋予了测试人员去督促研发人员修改bug的权利了？测试人员又有什么义务去督促研发人员修改bug呢？

之前跟一个在NEC工作的哥们聊过，在他们单位，测试人员是不直接跟研发人员打交道的。测试和研发中间有个中间角色，我们暂称其为bridge。测试人员的bug提交给bridge，bridge鉴定其是否为bug，是bug，流转给研发，不是bug，驳回给测试。同样道理，研发人员如果reject，也是由bridge与其交流。当然，bridge不是随便抓个人就可以当，级别得相当于“技术总监”吧。

当然，目前接触的好多单位都把这个角色省掉了。一个产品或者项目的测试可能总共也就2-3个人，怎么舍得派这么个大牛给大家呢？所以题目描述的问题又是一个不得不面对的事实。

从我的经验来看，出现这样的情况通常不是一些重要的bug，所以测试人员应该尽量将自己的bug描述的细致清晰，然后将bug转交给项目leader处理或者留在评审会时讨论，而不应该跟研发人员在这个问题上做过多的争论，这样一来耗费时间，而来会影响在后续工作中的合作。

研发人员因为在开发技术上的优势，常常会对测试存在一定偏见，测试人员应该能够认识并理解这一点。
作者: ruifengkeji    时间: 2008-10-28 11:46
回答的很有道理，值得借鉴，谢谢了啊
作者: 乐游    时间: 2008-10-28 13:09
我认为处理类似的问题，测试人员应该从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 14:52
看贴，顶下。

[ 本帖最后由 ersdfer 于 2008-10-28 06:59 编辑 ]
作者: vickywang_no1    时间: 2008-10-28 16:29
我们公司是这样的：
一切从用户需求出发，避免与开发人员直接争论。测试人员自认为是用户的需求，是否真的是用户的需求，以需求文档为准；如果需求文档中没有或与需求文档不符，应由项目经理（或需求调研人员）裁定，这样才能使开发、测试人员服气。
作者: yangtesting    时间: 2008-10-28 18:17
是不是BUG，首先需要一个很明确的需求或经过评审的测试文档。单靠主观因素去判断是不准确的，不负责的。
但是，目前国内的软件公司，真正能提供完善需求或严格遵守评审流程的寥寥无几。这时候，最需要的是测试人员主动，积极与开发交流沟通，交流可以提高我们对业务的了解，把握项目的进度，增进与开发之间的关系，这样在出现问题时，我们与开发之间能够更轻松的沟通，能更快的就某些问题达成一致。

下边是需要测试人员注意的地方：
1。有些问题在我们看来是BUG，但在开发看来，那个地方并不是他们关心的。
2。有些时候我们测试人员没有准确的描述BUG及危害，至使开发reject。
作者: zemg    时间: 2008-10-28 18:39
坐下 慢慢看
作者: sun_0910    时间: 2008-10-29 13:14
标题: 测试如何更有效说服研发去修改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 编辑 ]
作者: 海洋世界    时间: 2008-10-29 13:43
标题: sun_0910答题目很有水平，赞一个，学习啦！
sun_0910，自从你回答怎样做一个人见人爱的测试经理以后，很久没有看到你答题目了，这次出来答题，真不容易呀，嘻嘻！！！

希望您以后多多光临51Testing的每周一问答题。
作者: hsbc    时间: 2008-10-29 14:16
标题: 调整研发人员的心态非常关键
对sun_0910测试牛人的补充，个人认为，很多时候都是开发人员嫌麻烦，懒惰的心态，不愿意修改Bug，而不是说递交的缺陷不是Bug。很晕吧，同行们！！！

作者: zzhix    时间: 2008-10-29 14:23
标题: 谢过21楼的大虾
好经验，值得我们新手借鉴和学习，谢过大虾！！
作者: carry1986    时间: 2008-10-29 14:28
标题: 测试如何更有效说服研发去修改bug？
说到这个问题,在我工作的时候会出现这种问题.但很少时候我发现的问题开发的不修改.
首先你发现的是问题,能被重现出来的,你有足够的信心和足够的理由.如果开发不修改后,你可以有足够的理由说服它,如果你这种说法他还不修改的话,那也只能找第三者,也就是说是头了,应该是项目经理.
作者: 云里雾里    时间: 2008-10-29 14:53
标题: 好贴，很值得一读
[quote]原帖由 sun_0910 于 2008-10-29 13:14 发表
好久没上51Testing上答题目，谈谈自己的一点看法：

1. 关键是建立一个完善的研发机制：

  在大多数情况下，是不是软件缺陷或者需不需要修改，怎样修改不是测试人员和开发人员说了算的，应该是靠研发部门的相关 ...
作者: ask2650    时间: 2008-10-29 16:38
我认为，主要参考需求说明书，大的功能性，肯定能修改。

我认为难点在于程序的强壮性上，可以找相同功能产品对比，描述其严重性。
作者: yangyingtesting    时间: 2008-10-29 16:41
标题: 很好，很强大
很好，很强大，我支持
作者: panqingyu    时间: 2008-10-29 16:43
主要是公司要有一个比较完善的bug管理制度
作者: yanqiang    时间: 2008-10-29 16:44
我个人觉得还是归根到对Bug定义的理解，软件的Bug指的是软件中不符合用户需求的问题，只要把这个问题谈清楚了，说服开发同事修改测试人员提交的Bug也就很明显、直接了。当然了除了用户需求，开发与测试人员间的沟通还是很重要的。
作者: yetties2005    时间: 2008-10-29 16:46
主要还是沟通吧.说服开发...用语言压迫他们,哈哈...

自己的BUG要定义明确.告诉自己那是个BUG.跟开发谈的时候别人家一说什么你就想这到底是不是BUG啊,是不是自己错了.千万别有这样的想法,就算有,也不要在跟人谈的时候出现.还有就是通过需求.说明BUG不改客户是不能接受的.在就是像前面所说的.要软硬兼施，
作者: 31463683    时间: 2008-10-29 16:46
标题: 和研发人员搞好私人关系，做研发的听众
搞好私人关系,这样做故然好，不过要有个度。因为关系是关系，BUG是BUG不要混在一起，不然会有影响。不过楼上的人说的也没什么不对的
作者: lanlanlan    时间: 2008-10-29 16:46
大家多说说可操作性强的例子吧~~~~~ -0-

比如某次碰到开发扯皮的时候具体是怎么处理的
作者: yangyingtesting    时间: 2008-10-29 16:50
标题: 测试如何更有效说服研发去修改bug？
我认为首先领导要重视测试，重视BUG，如果有些小BUG连领导都不重视，那么开发人员也会很反感；
其次要确定是BUG，并且可以重现；
还要描述清晰，注意沟通；
有充足的理由说明BUG存在的后果和影响；
如果开发人员实在不听，引导他们换位思考，或者从客户的角度出发；
再不行，找项目经理决策。
作者: bichenlu    时间: 2008-10-29 16:54
我觉得这个问题吧，最重要的是需要你找出来的确实是BUG，因为在测试过程中，有些问题是因为开发人员与测试人员对需求的理解不一样，导致测试人员认为是BUG，但是开发人员却不这么认为。所以如果要开发人员修改BUG，那么你一定要能够向开发人员证明这确实只一个BUG，有修改的必要，让开发人员意识到修改的重要性，这样的话他们自然就会去修改了
作者: openfly    时间: 2008-10-29 17:01
在测试过程中，发现很多bug都是因为需求不明确而出现的，有些直接是研发人员对需求只做一半，另一半需求未实现，
拿着需求上的东西直接去找研发人员谈，他们会直接说改需求。。。。无语了都
所以觉得重要的是在项目开始阶段就和研发人员确定好需求，没按需求来的都是bug。
作者: coffeg    时间: 2008-10-29 17:03
据我个人的经验主要是下面几点：
1.bug本身的质量。这个非常重要，如果是严重的bug不用去说服，研发自然会去修改。
2.bug会产生的影响。这个考验测试人员的功力了，并不是要夸大bug的严重性，而是你有没有比开发看得更远。比方说是一个验证框颜色的bug，开发认为可改可不改，但你如果能说出如果用户是色盲就无法看清楚，也就无法登陆，进而无法使用我们的服务，而且中国色盲的人数是多少这么一报，那么他肯定得改。
3.对自己的能力的认同。需要说服的bug本身就存在争议，确实也存在可改可不改的bug，你如果认为确实需要改，就一定得坚持，找到充分的理由，然后在评审中一击必中，确立自己在研发心中的形象。就是说你发现的bug基本上在评审上都需要回去反工的，以后不用你自己说，他们自己就会去改了，也不存在什么说服了。
4.提升自己的能力。如果说前三点是技巧，最后一点可就是基础。开发人员和测试人员都是这样子，双方都有一个比较，让他们觉得在测试这块你就是权威你的能力起码不能比他们差，就算是没参与编码也需要一看就知道大概是他们会是怎么做的，通过少数几个问题即可知道问题容易产生的地方。
总的来说我个人觉得没有说服的bug，主要看你是否有充足的理由，和合理的方法。当然公司的评审制度也需要有，没有这个话完全靠测试个人是不行的。

这个是即兴发挥谈谈看法，没有完全总结几年的经验，欢迎大家的砖头。
作者: dulong    时间: 2008-10-29 17:15
我这边的流程如下：
1、bug记录QC中，通知研发员进行处理，研发员认为不影响、不是bug的标记为下一版本处理或拒绝。
这时测试人员先对研发员的处理已经修复的进行确认验证。
对于下一版本处理或拒绝的在定期的会议或一轮测试完成后开会讨论处理。
2、对于是bug，但研发员对严重程度与优先程度的标定不认同的，这需要测试人员与研发人员进行沟通，双方阐明问题在功能使用上或技术上各自的看法，这个阐明的过程我们是通过内Q完成，参与内Q的讨论的是项目组的所有人员，包括双方的头头，商务，还有测试跟研发。谈的过程中头头也会发表看法，其实这也相当于一次小的会议讨论。
作者: uestc    时间: 2008-10-29 17:22
个人认为，要制定一个完善的缺陷规范比较好！！
作者: tianmimi521    时间: 2008-10-29 17:29
首先要让研发或者开发的同事明确这的确是个问题，不去考虑问题本身的程度如何。
上策：闲暇时间以非正式的形式大家组织大家讨论，这就看个人沟通能力了。大家各抒己见，不但问题可以解决还可以加深同事之间的感情。
中策：“死缠烂打”，要求开发担当修改。
下策：上策行不通的情况下，将问题告知项目经理，由项目经理督促修改。

个人经验，一般这样的问题不修正的理由如下：
1.开发认为问题本身属于可修改或者不修改的情况，考虑到个人负责模块缺陷数量的问题，一般不愿意修改。
2.开发认为根本就不是问题（这样就返回到前提上说的）
3.开发担当懒惰（基本不会有这个现象）
作者: 奥运宝贝    时间: 2008-10-29 17:30
标题: 规范公司的部门体系，非常必要
21楼的讲得比较详细，很好！！

补充一点：我觉的，测试人员没有必要去要求开发人员一定修改某个缺陷，应该由QA人员去督促吧！！

不知道对不对，让大家见笑了。
作者: 暗涧幽火    时间: 2008-10-29 17:46
我认为建立完善的研发机构和BUG管理流程比较重要！
我们公司一般提交的bug开发都会改的，不管是不是个bug或者有歧义的一般都会注明原因的，所以不存在测试和开发之间为bug而产生矛盾的！如果提交的bug开发迟迟为改，那么上patch或者上一个新的版本就不能通过，必须等开发改完所有的bug后才会安排上线的！
作者: 89757    时间: 2008-10-29 18:15
标题: 回复 21# 的帖子
貌似大多数人对这种长篇大论不感冒吧............
我晕，来不来就给我投3课蛋，貌似这文章我见过，我去找找，看能不能找到...3个鸡蛋....让混不了？？？

[ 本帖最后由 89757 于 2008-10-29 18:23 编辑 ]
作者: 第一桶金    时间: 2008-10-29 18:18
偶喜欢21楼的帖子，很详细，很具有参考价值或指导作用，顶一个！！！
作者: 89757    时间: 2008-10-29 18:20
原帖由 yetties2005 于 2008-10-29 16:46 发表
主要还是沟通吧.说服开发...用语言压迫他们,哈哈...

自己的BUG要定义明确.告诉自己那是个BUG.跟开发谈的时候别人家一说什么你就想这到底是不是BUG啊,是不是自己错了.千万别有这样的想法,就算有,也不要在跟人谈的时 ...

用语言...貌似没什么作用吧，你要真正说服他，必要的时候，让他复述下....
作者: 吴如领    时间: 2008-10-29 19:50
由于开发人员和测试人员对需求的理解存在的差异，以及各自的工作角色，关于BUG的争论在日常的项目中是经常遇到的，如何保证BUG及时修复，非BUG不影响项目的进度至关重要。

让开发心甘情愿的修改BUG，我们可以从下面几个方面来考虑：

一、为什么定为BUG
二、测试经理对BUG的认同

三、有效的沟通

四、利用身边的资源

        总结，个人只提出一些实际工作中的经验，也建议大家在工作中学习，不要只看大道理，在特定的环境中掌握的技能才是根本。呵呵，以上是自己的一些想法，希望大家都提出宝贵的意见。
作者: 乘风摘月    时间: 2008-10-29 20:12
用户第一！有问题当然要改正！！
作者: wtfc    时间: 2008-10-30 09:47
标题: 扔鸡蛋友情提醒
建议：各位朋友扔鸡蛋一定要慎重，每个人有自己的看法很正常，不要动不动就给高手扔鸡蛋。本来现在答题目的高手就很少了，要是老是扔鸡蛋，估计后面也不会来答题了，为了我们共同学习的目的，恳请大家学会容忍，做一个文明有礼貌、有道德的测试人！！
作者: gmt    时间: 2008-10-30 09:53
48楼朋友的话，很中肯，赞成！！
作者: 忘记了    时间: 2008-10-30 09:57
纯占位置
作者: lucy-lucy    时间: 2008-10-30 10:10
标题: sun_0910牛人，送给你的鲜花可以看出喜欢你的人还真不少！！
希望您以后多出来答题目，哈哈！！！
作者: 朝九晚五    时间: 2008-10-30 10:16
望大家不要讨论扔鸡蛋是事了，就此打住吧！！答题目才是主要的！！
作者: 51tchina    时间: 2008-10-30 10:26
标题: 个人观点，仅供参考：
让测试人员去说服研发去修改Bug，本来就不是一件正确的事，并且也不是测试人员该干的事情，现在倒像是测试人员的责任了呢。

该题目的讨论，是否起到了误导作用？？？？？？？

欢迎大家发表自己的意见！！！！
作者: Robel.Yi    时间: 2008-10-30 10:31
标题: 软硬兼施
这种情况经常会出现，我的经验就是软硬兼施，在实际工作中也是比较奏效的，具体是这样：
    1.软  跟开发搞好关系，偶尔一起吃饭什么的，不用特意去怎么做，不过经常是微笑的面容容易让人家记住你并对你有好感，很多时候出现BUG去跟开发沟通的时候，他们大多不会好意思拒绝.
        2.硬  一个两个BUG的，考虑到开发的工作紧张程度，在合适的时候追一下，如果BUG堆积比较多，开发有推托的嫌疑的时候了，这时就要硬了，请召积开发和测试，开发老大一定要叫上，开会，把所有的BUG一起都拿出来，然后跟他们老大讲明历害关系，并请他去跟踪，当然这时候，也要拿出测试的水平来，BUG重现步骤、BUG描述都要准确，BUG的分析也尽我们可能的写出来方便开发了解，一般这就不由得他们不改了
     以上是我在工作中的一点方法，抛砖引玉.
作者: most2008    时间: 2008-10-30 11:30
这个问题一直困扰不少当前在前线奋战的战士们，中国人做事，凡事都得讲依据，没有依据很容易被拒绝。

       首先对自己从客户角度看问题确实是个BUG，但也得考度，测试者只是从谋一角度来看是认为是，但没有根据，就会没有说服力，对研发来说他可以是拒绝不是BUG，所以觉得是不是BUG还是从软件需求规格说明书为依据。

       其次，如果测试更多的从客户角度去看问题，确实是个BUG，提交又被拒绝，需求上并没有说明，可以向高层反映该问题，得到个解决方案。

      以上观点，才粗学浅，如有不对，欢迎各位高手指正。
作者: Jon    时间: 2008-10-30 12:10
呵呵，大家被把问题牵扯的面推广
同意楼上的楼上，
是不是bug最终是要有我们测试人员根据需求、从用户的角度及其需求方的意见等去综合考虑的
（1）确实是一个程序bug（测试环境中可以重现）
   a、测试人员需要与开发进行必要沟通，这个bug出现原因及出现结果，会影响到用户什么，或是影响到其它功能。最终会导致用户电话投诉，甚至出现外网故障（与KPI挂钩）
   b、测试人员需要和需求方一起评估bug的风险
   c、测试人员、需求方和开发一起评bug修改的风险
   D、最后决定bug是本次修改掉，还是延迟处理
（2）确实不是一个程序bug,有可能是其他的问题导致，譬如测试环境配置导致的（web测试往往是测试环境配置导致的一些非程序bug）

[ 本帖最后由 Jon 于 2008-10-30 13:05 编辑 ]
作者: 89757    时间: 2008-10-30 12:35
哈哈 我这一排鸡蛋...
作者: ianshine    时间: 2008-10-30 14:02
       我认为，开发人员说不是bug，有2种情况，一是需求没有确定，所以我可以这么做，这个时候可以找来产品经理进行确认，需不需要改动，3方商量确定好后再看要不要改。
      二是这种情况不可能发生，所以不需要修改，这个时候，我可以先尽可能的说出是BUG的依据是什么？如果被用户发现或出了问题，会有什么不良结果？程序员可能会给你很多理由，你可以对他的解释进行反驳。如果还是不行，那我可以给这个问题提出来,跟开发经理和测试经理进行确认,如果要修改就改,如果不要修改就不改。
       其实有些真的不是bug，我也只是建议的方式写进TD中，如果开发人员不修改也没有大问题。如果确定是bug的话，一定要坚持自己的立场，让问题得到最后的确认。
作者: testontest    时间: 2008-10-30 15:02
标题: 2次答题都很精彩
sun_0910，看了你2期的答题，收益匪浅，再次表示感谢！！！
作者: hailan1987    时间: 2008-10-30 15:11
标题: 测试如何更有效说服研发去修改bug
1 首先要保证我们的BUG报告是完善的，并且每个BUG的描述都是正确的。特别是具体是重现这个BUG的具体步骤。并且要尽量在最早的时候提出。以免到最后增加修复的代价。
2 BUG报告中的描述语气要尽量的委婉一点，最重要的是要针对软件所出现的问题，而不是针对某个人。
3 尽量让开发人员做为软件的用户来运行软件，比如自己用到的软件中出现了这样类似的问题，会如何对待。
4 做好与BUG所在功能相关的功能的测试，及类似功能的测试，说明BUG的影响程度
5 如何还是不能说服，那只有找软件项目负责人了，让他出面来解决
注： 测试人员本来就是为了保证软件质量而存在，我们的目标一切都向质量看。平时多与开发人员沟通，相信大家都会做到最好。
作者: Peyton    时间: 2008-10-30 17:57
高手好多，学习~~~~~
作者: testingisfirst    时间: 2008-10-31 09:32
标题: 好贴，值得欣赏，值得一看
[quote]原帖由 sun_0910 于 2008-10-29 13:14 发表
好久没上51Testing上答题目，谈谈自己的一点看法：

1. 关键是建立一个完善的研发机制：

  在大多数情况下，是不是软件缺陷或者需不需要修改，怎样修改不是测试人员和开发人员说了算的，应该是靠研发部门的相关 ...
作者: fairy-lu    时间: 2008-10-31 09:48
我认为，测试人员应该很明确的记录这个bug，然后查看设计中是否有相关的设计，如果是设计中有而开发人员没有实现，那么就拿着设计文档和开发人员谈。如果设计中没有，就看需求中是否有相关内容，如果有就要找项目经理来看，是不是需要在设计中加入这一块内容。如果需求中都没有，但是测试人员仍旧认为是一个bug，那么就应该找项目经理谈，由项目经理决定是否确认其为bug，是否需要修改。总之，不能够随意放过任何一个测试出来的bug，也不能够和开发人员弄僵关系。我们应该让他们知道，我们做的一切都是为了项目能够更好的完成，而且就算我们找来项目经理讨论，不是打小报告，而是找来比较权威的人士来做决策。
作者: hanshui0001    时间: 2008-10-31 09:54
原帖由 吴如领 于 2008-10-29 19:50 发表
由于开发人员和测试人员对需求的理解存在的差异，以及各自的工作角色，关于BUG的争论在日常的项目中是经常遇到的，如何保证BUG及时修复，非BUG不影响项目的进度至关重要。

让开发心甘情愿的修改BUG，我们可以从下 ...



很实用，帅哥 做测试leader很有方法~
作者: 鬼城    时间: 2008-10-31 13:20
标题: sun_0910你回答的思路很清晰，学习啦
不愧是一名测试经理，回答的思路特别清晰，值得我们新手学习！！

作者: 望川    时间: 2008-10-31 13:30
标题: 回复21楼的帖子
前辈，从你回答帖子可以看出，你一定是一位优秀的测试经理，向您讨教一个问题。请加我的MSN：wangchuan@msn.com，给个面子，哈哈！！！
作者: 九角树    时间: 2008-10-31 13:50
标题: 号召各位答题高手向21楼朋友学习
原帖由 sun_0910 于 2008-10-29 13:14 发表
好久没上51Testing上答题目，谈谈自己的一点看法：


1. 让研发团队的领导重视缺陷：

很多研发团队的领导都是销售出生，懂技术的很少，他们和搞技术的想法明显不一样。我在的第一家公司，发布版本时很多时候， ...


个人觉的：21楼朋友，观点新颖，标题或小标题，一目了然，很值得我写文档是时候参考。
作者: 软件测试专家    时间: 2008-10-31 14:01
标题: 这次上51Testing总算有点收获
学会了sun_0910编写文档的方法或技巧，这点我觉得深有感触。

补充一下自己的观点：
建议编写相关的缺陷管理流程和规范，并且要用制度去约束比较好！！
作者: 915SW    时间: 2008-10-31 14:17
标题: 赞同67楼的观点
答题采用sun_0910的大标题或小标题的答题方式，很好！！牛人可以只阅读大标题，也不浪费他们的宝贵时间。像我们这些新手，就逐句研读，肯定能学到很多东西！！！

作者: 怪好    时间: 2008-10-31 14:29
标题: 回复21# 的帖子
很佩服你的写作水平，文字功底也不错。请问朋友，你能加我的QQ吗？我已经给你短消息了，收到后请回复，感谢。

偶，也准备向测试经理的目标奋斗。看来也得多来“每周一问”练练笔才行，嘻嘻。
作者: 开心网    时间: 2008-10-31 15:14
标题: 我敬仰的测试前辈
原帖由 sun_0910 于 2008-10-29 13:14 发表
好久没上51Testing上答题目，谈谈自己的一点看法：


1. 让研发团队的领导重视缺陷：

很多研发团队的领导都是销售出生，懂技术的很少，他们和搞技术的想法明显不一样。我在的第一家公司，发布版本时很多时候， ...


我敬仰的测试前辈！！！
作者: 爱巢    时间: 2008-10-31 15:19
标题: 谢谢各位大侠！！！
对“测试如何更有效说服研发去修改bug？ ”这个题目讨论以后，个人感觉很明朗了，谢谢各位大侠！！！
作者: 爱巢    时间: 2008-10-31 15:21
希望版主，以后多讨论一些工作中经常用到的，好题目，而不是测试理论！！

Thanks！！！
作者: hsbc    时间: 2008-10-31 15:35
标题: 我们很想学东西，特别反感向高手扔鸡蛋的测试菜鸟
最近几个月发现个别“不法分子”老是向测试高手扔鸡蛋，行为可恶！！！弄得现在答题的高手几乎绝迹了，几乎成为“国宝级的珍稀动物”了。要是后面再有这样的捣乱分子，希望大家群起而攻之，让它永无天日！！！！

同时，希望大家对以往的事情既往不就，到此截止吧！！！！
作者: 奇怪的测试人    时间: 2008-10-31 15:40
标题: 赞同，我支持
[quote]原帖由 hsbc 于 2008-10-31 15:35 发表
最近几个月发现个别“不法分子”老是向测试高手扔鸡蛋，行为可恶！！！弄得现在答题的高手几乎绝迹了，几乎成为“国宝级的珍稀动物”了。要是后面再有这样的捣乱分子，希望大家群起而攻之，让它永无天日！！！！
作者: lucklytesting    时间: 2008-10-31 15:45
标题: “测试如何更有效说服研发去修改bug ？”
我们公司，都是测试经理去和开发人员沟通是否修改，我们小兵只负责递交缺陷，现在看来，太幸福了，也不用为这些事情烦劳了！！！
作者: 默默巫    时间: 2008-10-31 15:45
原帖由 爱巢 于 2008-10-31 15:21 发表
希望版主，以后多讨论一些工作中经常用到的，好题目，而不是测试理论！！

Thanks！！！

这些问题都是会员提出的，也是测试人员工作中不可避免会碰上的问题，我觉得是值得大家讨论的．
你有什么疑问也可以在问题征集贴中提出来．
作者: wtfc    时间: 2008-10-31 16:13
“默默巫版主”为我们新手说话，真好！！！
作者: 爱巢    时间: 2008-10-31 16:24
标题: 版主，我已经把题目写进每周一问啦，希望能够说话算数，哈哈！
http://bbs.51testing.com/thread-129915-9-1.html

版主，难得的好人呀！！！
作者: liaoyuan    时间: 2008-10-31 16:29
讲讲我们公司的处理办法，已经跟开发相处了两年时间了，平时关系也都很好的，从来就不存在抵触的情绪。
我们的项目管理使用的是JIRA，发现的bug我会全部提交到JIRA上，并且分配给对应的开发人员，JIRA状态显示为“未解决”，不管哪个领导上去都可以看到有多少bug未解决，有哪个开发人员的bug未解决，所以开发人员还是很积极配合的，总不希望自己的bug老是堆成一堆吧，开发人员不不断刷新JIRA，一般看到bug都会以最快的时间来解决，我还没跟这个不解决bug与他们发生过问题的
作者: chuming    时间: 2008-10-31 17:00
“每周一问”或“话题PK”是51Testing上办的最好的2个栏目，值得期待。
作者: testontest    时间: 2008-10-31 17:47
标题: sun_0910同学，收到那么多鲜花，答题确实很有水平
高手总归是高手呀！！经验丰富、思路清晰，很值得我们测试界的同行学习或研究。
作者: hansonhy    时间: 2008-10-31 22:18
根据我个人经历和工作经验来说

1，首先确认这的确是一个BUG，BUG分为两种，一种软件本身存在设计或编码缺陷。这个一般开发都会主动改，因为直接影响软件质量。
  第2种，测试人员认为会设计影响用户操作或功能不符合用户要求的功能。这种情况很可能被拒绝。

2，上报测试经理，在提交缺陷时，写清楚缺陷等级和真实环境什么情况下必定或可能引发这个缺陷，会造成什么样的后果，甚至多大的经济损失。让测试经理去和开发经理开会争论，实际后果大的BUG一般都能通过讨论决定要改。

3，依靠个人口才，跟开发人员讲道理。讲用户使用难处，可能引起产品损失，造成他的奖金蒸发。开发人员如果考虑到改动难度不太大，可能会克服懒惰思想改正。

4，强行争论，吵架，是没什么用的，毕竟以后还要合作。那样以后他不会给你帮助的。
作者: konglingchao062    时间: 2008-10-31 23:10
标题: 发表一下我的看法吧。
工作当中经常会遇到这种情况，测试人员发现bug，但是开发人员却并

不承认这是个bug而找理由不去修改。虽然上报经理让经理命令开发人

员修改bug是有效的方法，但是如果找经理的次数过多必然会引起经理

的反感，那么怎么班呢？我认为可采取如下几个步骤：
1.首先你要跟开发沟通，讲明需要修改的必要性。当然要注意沟通的

方式，切忌强行争论，要注意说话的语气等，如“您能告诉我不需要

的修改的原因吗？...”
2.如果开发坚决认为不用修改，那么你要再次分析此bug是不是真正的

bug，如果你觉得是要修改的，那么你写好一个bug备忘单，然后再找

开发沟通（同样是和平商讨），如果他不改，那么让他在bug单上签名

，让他来负责。一般情况下只要让他签字负责，他就会自愿去修改的

。
3.如果你觉得此bug需要上报经理，那么你同样要与开发沟通，商议一

起去找经理，让经理决定该bug是否要修改，或确定修改的优先级。（

你要确保开发人员知道你去找经理，切忌背着开发找经理，这样会影

响你们的合作。）
作者: zengyixun    时间: 2008-11-1 01:07
由于我做过两年的开发，5年的测试，在测试过程中，自己也做过些测试工具，也有测试人员对我的测试工具来进行测试的经历，所以我首先站在一个开发人员的角度来看，什么样的bug与测试人员能说服我呢？要说这个问题，我们首先要有有一个假定：假定开发人员不是一个神经病（多数其实都不是，如果是，那么应该由人力资源部负责），既然开发人员不是神经病，那么你一定要相信他对于自己所做的模块也是抱着认真负责的态度，希望把功能顺利实现，而不会出现什么意外状况的，所以当有人给我提出一个bug是我确实没有想到的，而又实在的影响到这个模块的功能，我做为一个开发人员会考虑修改这个问题，如果这个问题还有一点点深度，我会更加开心，抱着挑战的态度，也抱着赶快把此功能搞定的急迫心情去修改它，由此得到一个好的绩效与认同，所以像这样的bug，需要测试人员来说服我么？当然不需要。然后再看看什么样的问题我不喜欢，曾经我做过一个测试工具，新来的测试人员对我的工具进行了测试，在测试的同时，也使新人学习了各种业务知识，在这些测试者中，我就很明显的对那种能提出功能性错误，或者我考虑不周造成的错误（这一定要用专业的测试方法才能测出的）的新人，我会报着一种对他的欣赏的态度去修改他提出的问题，而对那些，没事找事，总是按自己的主观意愿提出一些使用上问题的人，给以鄙视，比如新来的测试负责人，在我修改完所有问题后，叫我把下拉框改成tab页，嘿嘿，你喜欢tab页，我就喜欢下拉框，测试部难到没有别的事情做了吗，做这么无聊的事，也就是说，有关操作习惯问题本就是你有你的习惯，我有我的习惯，凭什么就说你的习惯是代表了广大人民群众呢？是吧？
    看了上面一段，相信大家就知道了什么样的问题会得到认同，这样的问题，根本不用你去说服谁，但是，这个世界如果如此简单，就不会有战争了，是吧，所以，我刚才说的只是开发人员的立场，说这些只是让大家明白一个心理特性，并不意味着，开发人员的这种立场在任何场景都是正确的。
    所以，还有一个测试人员的立场问题，对测试而言，我们有各种测试方法去发现bug，有时有的测试方法做出来的测试结果确实发现了问题，但这个问题可能会引发开发人员的反感，这是因为开发人员对测试的工作不了解造成的，比如，我们用边界测试发现一个问题，但开发人员会说，谁会去输入这样的数值呢，在实际工作中，人家是不会这样操作的，所以拒绝修改这样的问题，怎么办呢？这个时候，其实如果一味的让每个测试人员去与每个开发人员讲道理做宣传，其实效率是低下的，而应该把这一类问题记录下来，由测试部门进行一个评估，然后与项目负责人进行沟通，在一个适合的时间点（致命问题、严重问题都改得差不多且还有时间的时候），对此类问题进行一个全面的修改，如果是一个好的公司与部门，还会就此类问题进行总结归类，并对此类问题定义出严重程度与修改的优先等级，如此就完成了一项过程改进，当下个项目出现类似的问题时，一个制度化的结果已经在这里了，开发人员再次见到类似问题，自己就会在已经把致命与严重问题修改完成的情况下，对此种等级的问题再进行修改，而不需要再次做没有必要的沟通了。再比如使用操作性问题，其实就是一种体验测试，如果这种问题由每一个测试人员零星提出，不但没有科学调查与说服力，也会得到开发人员的白眼，所以有关使用方便的问题，也应该单独的当成一个整体事件去做，而立下科学调查的标准化决议，当项目组与测试部与市场都搭成统一标准后，做这些事，还会有阻力吗？
    我看有的人的解决方法是人情世故，有的人的方法则是权利压人，还有的人的方法是每回都去以理服人（以德服人，怎么感觉测试总是低声下气的？难怪人家不改你的问题），还有总总方法，但不是有后遗症，就是回回都要如此，搞得效率低下，所以真正的方法应该是，把一项不太受到开发人员重视，但又确实是不可小视的那些问题，想办法通过外交努力，搭成统一的科学的标准化的制度化的行业规范，当一个制度在这里时，没有人会觉得你是和他过不去，只会觉得，这是制度的要求，我们本就都该这样做，就好像你迟到了，你不会认为是人事MM对你有偏见，也不会认为人事MM水平低，不懂得以人为本的道理吧？当然不会，因为几点上班是一项制度。有人见过搞人力资源的人在网上发贴问：请问人事如何更有效的说服员工们不要迟到呢？呵呵，一家之言哈！
    至于那些根本就不是问题的问题，求求你们千万不要用你和开发人员的好关系，把不是问题的问题给修改了（还好有问题审核与软件配置管理），我的主呀，阿米托佛！

[ 本帖最后由 zengyixun 于 2008-11-1 01:30 编辑 ]
作者: zdlzx    时间: 2008-11-1 18:37
标题: 回复 1# 的帖子
1、征询需求分析人员的意见
因为需求分析人员接触真实的用户操作信息更多，他们可以帮助鉴别部分在业务角度看来确实不可能发生的情况。这种情况下，测试人员即使觉得有从逻辑严密性而言有漏洞，但发生概率很小，而修改比较麻烦或者有风险，开发人员不改动代码更合适。

2、冷处理
如果不是影响很大的问题，不用一定这次要一决雌雄，让对方说服自己。有时简单地定一下，这次就不修，看看上了线之后的一段时间有没有问题。没有人永远都是对的，也许你觉得自己很有道理，但这次经过事实的检验，你的判断不尽准确，亡羊补牢再修bug好了。

3、让高一级的人来决定
如果对于这个bug是重要还是不重要的性质难以取得共识，而一个开发人员和一个平级的测试人员争论不休是很难得到结论的，此时可以让PM或者测试经理介入，看看他们决定怎么做。
作者: haomiaohaiyang    时间: 2008-11-2 15:34
吸取各方精华，顶一下
作者: beckhans    时间: 2008-11-3 00:13
呵呵 拿出你的理由让，开发人员低头！
这是我的做法！
作者: eyec    时间: 2008-11-3 09:30
标题: sun_0910答题太好，学习啦！
刚上51Testing就发现这样的好贴，不上51Testing真亏，哈哈！！
作者: starvip-testing    时间: 2008-11-3 20:30
新人看不太懂顶一下
作者: 01047418_lzz    时间: 2008-11-8 11:40
标题: 支持sun_0910
牛人啊，我太喜欢你的回答了
作者: qinglu000    时间: 2008-12-13 19:15
学习了



欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2