测试小故事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，接纳不同的建议。