别混淆问题的优先级与严重性

发表于:2011-9-19 14:28

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

 作者:terryyoung(CSDNblog)    来源:51Testing软件测试网采编

  Bug 为什么需要分级?

  将一个 Bug 作等级分类,是对有关部门在协调方面的一个基本指标,是非常必要的,因为有了等级分类才能调整处理事务的排程。销售/客服/项目经理均需要知道缺憾发生时对交货期的影响;品管亦需要知道产品目前的品质状况。

  优先级(Priority)与严重性(Severity)的分别

  从根本上,优先级 (Priority) 是从项目管理和时间管理的观点来厘定高低,而 严重性 (Severity) 是从质量管理的观点来思考的。

  处理问题的严重性,以质量作为出发点,应针对所产生的问题是否会对产品造成严重的缺憾来决定等级的;其决定权,通常掌握在 QA 人员手中。

  处理问题的优先级,以整体项目的进度、质量、市场,以及需求所造成的影响作为出发点,决定应对的措施;其决定权,可以分散至负责交货或者售后服务的部门,而最终决定权通常掌握在项目经理手中。

  开发对于问题处理的争议

  有些软件公司或会以问题处理的优先级的分级法直接取代问题严重性的分级法。这就等于由项目经理或所授权的人士决定处理问题的优先级。这种局面并非没有可能的,其中一个可能就是团队本来是从很精简的人手开始慢慢壮大,而因为以前人手精简,当时的严重性和优先级的决定权很自然都会同时落在发现问题的人手上,也就是,没有区分的。所以,团队越大,越有必要分清楚两种分级方法。

  以优先级取代严重性这种单方面的游戏规则就是为什么测试人员和开发人员经常对于问题的处理方式上出现争议的原因。

  以现实中的例子再说明一下。举例,当测试人员找到一个程度中级严重的问题而导致部份功能运作不正常,以 QA 的角度看当然是希望这问题可以尽快解决。但是,如果产品要在下个星期甚至几天之内交货,一旦延误的话甚至可能导致缴纳赔偿,而目前有出现开发人手不足的话,由于无法及时抽出人力资源解决问题,此时项目经理考虑之后就有可能将这个问题的优先处理级降低至产品出货之后才解决并推出修正版本。试问,产品尚未出货,何来继续研发的经费呢?

  系统缺憾(Bug)和需求变更(Change Request)界定出现含糊所惹来的争议

  也有些软件公司在发现问题的过程中,发现一些设计上的问题,也列入系统缺憾来处理。例如介面本身虽然能运作正常,但是由于设计时对于某方面的应用没有考虑在内,因而导致在某应用需要上无法满足。

  这也是一个辨认系统缺憾的一个误区,而 QA 在这个盲点上进行决定高程度的严重性或者优先处理,几乎会必然地惹来争议。尤其对于开发来说,发现设计上的问题,从编程和开发的角度看,绝对不是一个 Bug。

  以上的例子的话,产品的当前状况是完全符合产品当前的设计的。其实,发现了这种所谓的问题,是当前产品的可改善的建议,理应界定为需求变更,适宜向负责产品设计的部门提出。当建议被接纳了继而开发后,就是套用 QA 的日常工作流程,对此新改良的设计再进行测试,再去评估问题的严重性,在问题追踪系统内跟进。

  所以,以上的情况,所发现的问题虽然同样可以有其严重性和优先处理等级,但是,所发现的,在类别上有根本上的分别:它不是 Bug,不是系统缺憾,而是需求变更。

  问题分级要有明确具体的指标,切忌问题分级制度形同虚设

  虽然有些团队会利用一些问题追踪系统,系统内或有高、中、低,或者 1 至 5 之类的分级,然而,没有明确指标和具体含意的分级是形同虚设的,甚至会影响整体进度,令团队发生处理问题上的不必要的争议。这些指标,是需要开会讨论,或者在团队内发布消息。打个比喻的话,问题追踪系统是游戏架构,而分级指标是游戏规则。

21/212>
《2023软件测试行业现状调查报告》独家发布~

精彩评论

  • foxzqn
    2011-9-24 09:50:43

    不错,很受用!

关注51Testing

联系我们

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

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

沪ICP备05003035号

沪公网安备 31010102002173号