如何处理与开发有争议的Bug?

发表于:2018-2-14 10:47

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:Fighter.Lu    来源:博客园

  工作中,测试人员有时会遇到类似的问题:提交了一份软件缺陷报告,可由于某种原因,无论是开发人员还是开发经理就是不愿修改程序。应如何处理这类问题呢?我认为,当对报告出现分歧意见后,测试工程师应首先做如下第一、二步分析:
  一、问题确认与评估
  再次论证该问题确实是程序缺陷,并评估该缺陷的重要程度并对其分类。比如可存在以下分类:
  1、设计文档范围内的功能性缺陷
  2、影响到程序的安全性和稳定性缺陷
  3、界面缺陷
  4、一般性错误(如未考虑边界检查等)
  5、边缘死角,规律不明显,不太容易重现的错误
  6、兼容性错误(例如旧机型、CPU\MEM,旧标准等等)
  7、安全性或易用性等的修改建议
  ……(可扩展)
  二、明确Dev不修改该缺陷的确切原因
  比如可存在以下原因:
  1、规律不明显,不好重现
  2、dev认为是不影响主要功能的一般性bug,因时间处于版本的稳定期,担心牵一发动全身引起更多错误
  3、调用了第三方组件或库函,是第三方程序存在的缺陷
  4、存在技术难点
  5、设计本身存在问题,程序逻辑是正确的,但实现结果并非用户所需(换言之,dev说这是设计问题,不是程序问题)
  6、Dev的个人主观意见:
  该瑕疵可以容忍,没必要修改
  修改该瑕疵会引起更大的问题
  7、Tester和dev对错误的理解有分歧:
  tester理解错误,该问题并不是bug
  tester没有说服dev这是个bug
  ……(可扩展)
  三、具体问题具体分析
  分析完第一、二步之后,也就基本上明确了问题的争议焦点,然后具体问题具体分析。
  1、如果dev认为不好重现,则tester有责任和义务找到更简洁有效的重现规律。
  2、如果tester没有说服dev认识到这是个缺陷,则需要拿出强有力的证据(测试用例、设计文档、错误现象等)来证明。
  3、对于第三方库函bug,或技术难点导致的bug,则坚持原则--宁缺勿滥,必要时宁可封掉该功能。
  4、针对错误的设计、不能说服的dev主观理解、改动隐患,以及稳定期等特殊情况,则可通过TM进行多方沟通。
  四、发挥TM与PM的沟通职责
  强调沟通
  TM和PM有团队沟通的职责。在bug分类、指派和反馈过程中出现有争议的问题时,TM和PM有责任和义务进行干预。根据问题的重要程度和轻重缓急,采取不同的方式进行沟通。如出现“三”中3、4类较大争议的问题,可通过会议研讨等形式召集多方进行论证,并达成一致的解决意见,解决方法形成备忘录。
  对因各种原因继续保留在发布版本中的bug,尤其可能影响功能的,应予以说明,提醒用户绕过。

上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理。
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号