• 软件测试技术
  • 软件测试博客
  • 软件测试视频
  • 开源软件测试技术
  • 软件测试论坛
  • 软件测试沙龙
  • 软件测试资料下载
  • 软件测试杂志
  • 软件测试人才招聘
    暂时没有公告

字号: | 推荐给好友 上一篇 | 下一篇

软件测试如何更有效说服研发去修改bug?

发布: 2009-7-09 10:33 | 作者: 不详 | 来源: 领测软件测试网采编 | 查看: 179次 | 进入软件测试论坛讨论

领测软件测试网

软件测试如何更有效说服研发去修改bug

问题描述:测试过程中一些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:

  

延伸阅读

文章来源于领测软件测试网 https://www.ltesting.net/

TAG: bug BUG Bug 测试环境搭建 软件测试 研发

21/212>

关于领测软件测试网 | 领测软件测试网合作伙伴 | 广告服务 | 投稿指南 | 联系我们 | 网站地图 | 友情链接
版权所有(C) 2003-2010 TestAge(领测软件测试网)|领测国际科技(北京)有限公司|软件测试工程师培训网 All Rights Reserved
北京市海淀区中关村南大街9号北京理工科技大厦1402室 京ICP备10010545号-5
技术支持和业务联系:info@testage.com.cn 电话:010-51297073

软件测试 | 领测国际ISTQBISTQB官网TMMiTMMi认证国际软件测试工程师认证领测软件测试网