测试小故事15:BUG被拒

  ”@#¥%...,提的BUG又被开发拒了,明明就是个问题么,开发为什么不改,也不给个原因,rejected就了事,不行,reopen给开发。“
  这也许是测试使用BUG管理工具后最常遇到的问题了,开发不承认是BUG,测试不接受这样的reject结果,双方各执一词,互不相让。
  也许会说,找需求说明么,找仲裁么。如果需求能写到万分的清楚,如果真有人能做出另双方都信服的仲裁,那么就不用这么费事的针对一个BUG开发与测试来来回回争论不休了。

  既然存在这样的问题,如何去提交一个BUG,让开发能够接受建议从而修改BUG,减少BUG被拒的可能性呢?先从测试提交BUG的角度认识下(开发解度留给开发自己说吧)
  1.BUG级别的定义(都是绩效惹的祸)
   功能性的BUG级别就高,UI的BUG级别就低或是不计,这样合适吗?
   有这样的系统,国内航空企业的IO系统,界面有代表航空的飞行设备,功能没有问题,但是界面设计时用了日本的一架飞机图版做为图标。。。不解释,这样的问题如果提交BUG级别是高还是低。

  2.BUG描述
   “不对,不清楚,不正确。。。。。。”
   这是测试人员在做BUG描述时爱用的词汇,特别是在summary的描述中常用“XX功能不正确”。从心理接受角度来讲,这样的描述会带来一定的逆反心理(当然,开发人员也要有一颗强大的心)。如果写成:“XX功能未实现”,“XX功能在做XX操作时,出现XXXXXX”,这样是否更清晰,更容易让开发接受呢。
   一言兴邦,一言丧邦,不同的语言、语序、语调可以造成不同的结果。
   从我个人的角度来讲,描述BUG应优先考虑对系统功能的影响,系统最重要的评价标准是功能性,首先要能用,然后才是可用,最后才能可能不断完善。
   一方面,要么错、要么对,不可以即对又错;另一方面,功能实现如果没有问题,也许只是功能的表现形式有待提高。
   同时BUG描述的简洁性、准确性、可再现性也会影响到BUG是否被拒。长篇大论,混乱的逻辑,把BUG读下去都是种考验,更不要说去修复了。
   一击必中问题要害,才是优选的问题描述(5W1H的描述法,可以有效提高BUG的描述质量)。
   
  3.面对BUG被拒
   气呼呼的拎着棒子,摆出吵架的态势找开发论理,怕是很难解决问题,到最后往往是各不相让。
   如果从解决问题出发,以理解、讨论的方式与开发沟通,想来会更和谐一些,问题完满解决的可能性也就更大,或许不同思想的碰撞会带来对系统更加深入的思考。
-----------------------------------------------------------------------------------------------
  开发与测试本该是合作的关系,双方有着明确的目标:保证系统按要求提交给用户使用。
  也许拒或是不拒会影响开发或是测试的绩效(绩效评价是否合理不讨论),但系统的使用者不是开发也不是测试。
  面对BUG,拒或是不拒都不是重点,重点的是用户在面对同样的问题是是否可以接受。
  不要开发和测试相互指责,与其计较是不是BUG,不如更加的接近用户实际,从用户角度想问题。

  多数时候,个人的主观性造成了我们对于BUG理解的偏差,需求的模糊性性造就了对于功能理解的二义性。
  不怕不清楚,就怕不沟通,更怕不能好好沟通。
  同理心,站在彼此的角度审视BUG,接纳不同的建议。



评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值