这个冰清的学习天地,以后我会把自己觉得重要的学习资料和大家一起分享。

测试如何更有效说服研发去修改bug?(转)

上一篇 / 下一篇  2009-05-21 16:04:46 / 个人分类:测试

题描述:测试过程中一些bug会被研发认为是无效bug,但从用户角度出发,测试认为该bug需要更改,此时测试如何更有效的说服研发去修改bug?

精彩回答:

  1. 扭转研发领导的思想,提高研发人员的响应速度:

  a). 让研发团队的领导重视缺陷:

  很多研发团队的领导都是销售出生,懂技术的很少,他们和搞技术的想法明显不一样。我在的第一家公司,发布版本时很多时候,都是没有测试结束,功能开发的差不多就把产品卖掉了,后面再对版本不断升级,结果这个公司没多久大概3年不到就散伙了。后面一家公司的领导是做质量管理出生的,明显对测试的质量要求就不一样,每次要求都特严,对以前测试结束标准都做了进一步的修改。如果领导对缺陷都视而不见,你说研发人员还愿意花大量的力气去修改Bug吗?所以说,团队的领导的想法或意识,对缺陷是否修改起到非常重要的作用。我记得以前测试高手zhuzx也在每周一问中提到过,大家也可以借鉴一下。

  b). 采用常用的缺陷管理工具(QC9.0),提高缺陷的透明度:

  我们公司使用缺陷管理工具(QC9.0),测试经理任管理员,给公司高层领导、项目经理、开发经理都分配了权限,自己可以登录系统查询相关信息。在测试后期,特别是要发布版本前后,领导们一有空,也随时上去浏览一把,无意识给开发人员施加了较大的压力。如果这个时候还有很多Open的缺陷,开发人员自然不敢怠慢。

  c). 把开发人员的修改缺陷的响应速度,记入绩效考核内容:

  由于公司总监特别关注产品质量,我们公司对缺陷修改这一点做得比较好,每次都是递交缺陷以后,开发人员响应特别快。如果有疑问,就马上和测试人员一对一交流,尽快修复或解决该缺陷。我们公司的口号是:“宁愿花出100倍的代价,也不让发现的缺陷留给客户”。还有一点就是开发人员绩效考核的时候,我们测试人员要给开发人员打分,很重要的一点就是:开发人员对测试缺陷的响应速度,如果这一项很低的话,老大要找你谈话的,问具体原因是什么?呵呵。所以,我们公司很少有测试人员追着开发修改缺陷的情况,把修改缺陷的响应速度纳入个人绩效考核,我个人觉的是一种比较好的方式,值得借鉴或推广。

  2. 组建一个合理的研发团队,规范测试规范:

  a). 关键是建立一个完善的研发机制:

  在大多数情况下,是不是软件缺陷或者需不需要修改,怎样修改不是测试人员和开发人员说了算的,应该是靠研发部门的相关制度或相关部门去约束。毕竟在国内软件的软件企业缺少这样的部门,所以说把修改缺陷相关的重任推到了测试人员的头上,其实对测试人员实在是太不公平了。要解决这个问题,最关键就是建立一个完善的研发机制,让QA等相关部门督促解决这类问题,比较好。

  b). 分清团队成员的具体责任:

  对于研发团队中的每个成员,必须责任明确,否则像督促缺陷修改这样的事情本来不是测试人员的责任,现在都推到测试人员头上了。很郁闷!!

  c). 完善测试规范,明确Bug管理制度:

  大部分的公司,都没有单独的部门来单独管理督促缺陷是否修改,都默认为是测试部门的事情。个人觉的最好是赋予项目组中相关人员一定的资质,让他们去处理这些琐事。经常碰到这样的情况,很多争议的缺陷都一直放到后面一个版本,一段时间下来,几个版本争议的缺陷就多于100个,弄得后面版本也不好发布。我们的做法是,发布前几天,对每个争议的缺陷用邮件先发给项目组成员先看,后面在召开缺陷评审会议,如果通过,毫无疑问修改,否则关闭或保留到下一个版本。

本文出自51Testing软件测试网,感谢会员sun_0910在每周一问(08-10-27)中的精彩回答。
http://bbs.51testing.com/forum-157-1.html

  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的缺陷或可改可不该的缺陷,可能作为客户使用不是很方便。我们可以和客户代表聊聊这样的缺陷,如果客户代表同意这样做,那没问题,可以不修改;如果客户不同意,他自然会直接找项目经理或高层人员协调解决这个问题,这就不用我们测试人员操心了。因为客户就是上帝,这招不错吧!!!

  我目前想到的就这么多,希望同行指正!!!



TAG:

 

评分:0

我来说两句

Open Toolbar