如何区分bug的优先级?

• 使用 优先级 与严重性或影响无关 ,并仅描述错误在计划中的概念位置。这个字段将决定哪些bug得到处理,因此需要非常清楚 事实

• 使用 严重程度 故意有具体的,可证实的定义 与日程安排或优先级无关 . 我成功地与 severity definitions used by the Debian BTS ,一般适用于编程项目。

严重程度 可证实的事实 ,独立于优先权声明。这个 优先

消耗灵魂的争论和浪费的时间 . 臭虫报告员需要一个可靠的工作指南 事实

我在紧急控制中心工作,所以这组错误级别有点。。。 :

• 需要DR调用的总系统故障
• 涉及呼叫连续性丧失的故障
• 涉及数据丢失的故障
• 应用程序故障-不可恢复
• 应用程序故障-不可恢复,但自动重新启动
• 不符合需求规范,但有解决方法
• 化妆品-布局等。
• 实际上是一个功能请求

我真是想不通。如果你想知道的话,从最极端到最不极端:-)

用fogbugz替换你的bug跟踪系统,彻底去掉severity字段。

Priority vs Severity

一些我们以前用过的东西。我们将缺陷评级分为优先级和严重性。

严重程度

• 最高(5):数据丢失、可能的硬件损坏或与安全相关的故障
• 中等(3):功能丧失,解决方法合理
• 低(2):功能或特性集的部分丢失(特性仍符合设计要求)

优先 (由开发、管理和QA在缺陷评估期间进行调整)

• 最高(5):此缺陷导致系统实际上无法使用。
• 高(4):缺陷将严重影响公司销售和维护本系统的能力。
• 中等(3):如果系统中存在此缺陷,公司将损失一些资金,但满足时间表可能更重要。释放后修复。
• 最低(1):在时间和资源允许的情况下修复。

这两个数字一起创建一个风险优先数(RPN)。只需将严重性与优先级相乘。更高的结果意味着更高的风险。25定义了终极缺陷炸弹。我可以在空闲时间做,或者如果有人感到无聊,需要做点什么。

第二个目标:RPN>8的缺陷应该在发布产品之前修复。

这当然有点做作,但有助于为各方(支持、QA/测试、工程和产品经理)提供一个工具来设置优先级,而不必吹散对方的意见。

不要将严重性与优先级结合起来

我们有过很多头脑风暴和会议,最后都是这样的话 ". 已经创建了多个指导性文件,并在不同的“各方”之间传播,但过了一段时间,我们发现它最终不起作用。不同的“当事人”对bug的看法不同:我们的帮助台对优先级的理解不同于开发团队或销售人员。

• 当使用数字(在1到5之间)时,人们将不知道每个数字的含义

• 对一个问题的“级别”只使用一种指标:不管你怎么称呼它。

• 使用数字(例如1-5,但可能或多或少取决于你的需要)来清楚地表明重要性,但 它带有一个关键字,这样就可以清楚地知道它的意思(例如“很高兴拥有”、“show stopper”)。对于某些人来说,prio 1表示最重要,而对于其他人来说,prio 5表示最重要,因此需要一个关键字来指示数字的含义。

• 区分“正常问题”或“红色警报”。在我们的情况下,“红色警报”必须立即解决,并立即投入生产。正常问题将遵循正常的开发测试部署流程。优先级/严重性/但是您如何调用它只应为正常问题设置,对于“红色警报”将被忽略。 *>实际上,“红色警报”可能会变成

  发现了一个主要错误并创建了一个 “红色警报”。但经过一段时间 已经在数据库中“损坏” 而不是通过应用程序*

• 选择一个好的工具,它允许您自定义流;但是大多数工具都可以。

IEEE软件异常分类指南 虽然我不知道这一点被广泛采用。 IEEE 1044.1-1995

一种选择是让产品所有者确定bug的优先级。虽然对bug的“坏”程度有一些普遍的直觉,但产品所有者有责任设定一个谨慎的顺序(即bug a应该在bug B之前修复,等等)。

1. 必须现在就做
2. 必须在装船前完成
3. 不能防止用户的烦恼

是我编的。。。我的观点是,对bug进行分类不应该是每周一小时的例行公事。。
依流程图优先排序是浪费时间。尽快修复1类和2类的漏洞。如果你发现自己被虫子淹没了,放慢脚步反思。如果计划不允许或更高优先级的项目被覆盖,则推迟类别3和类别4。

就我个人而言,我赞成两级严重性/优先级模型。我知道一个层次的论点,但我工作过的地方,一般来说,我只是看到一个两个层次的继承人更好地工作

严重性由支持团队设置(基于客户的输入)。优先级由客户设定(由支持团队输入)。

1-阻止程序/显示停止

3-主要功能不可用(或…),可能的解决方法
4-次要功能不可用(或有效不可用),无法解决
5-次要功能不可用(或…),可能的解决方法

我通常会先按优先级排序,然后再按严重性排序。重要的是客户有最重要的发言权。如果他们说他们的logo打印在报表上的方式是最高优先级的,那么这就是被查看的内容,但是它是在其他客户的高优先级(即阻止他们登录)之后被查看的。

• 测试仪会告诉你什么东西坏了
• 开发人员估计要修复的工作量
• 客户决定业务价值,即优先级。

设置项目的需求,这样您就可以根据受bug干扰的需求的优先级来确定修复的优先级。

我和我们的一个客户有同样的问题。最后,我们一起建立了一个文档,描述什么样的bug会匹配到某种严重性。除了偶尔讨论之外,使用本文档作为指导似乎是可行的。

但是请注意,测试团队和开发团队在什么是严重bug和什么不是严重bug上可能有非常不同的意见。从测试人员的角度来看,当开发人员只是说没有人会注意到的时候,一个小的布局错误可能是高优先级的。

对于特性和bug,我使用以下类别:

1. 但是,程序(或主要功能)将无法工作
3. 会有,一些顾客会被打扰

通常您计划修复1、2和3,但3通常由于时间限制而推迟到下一个版本。

1. 导致文件丢失或系统不稳定。
3. 功能不起作用。
4. 功能不起作用,但有解决方法。
5. 化妆品问题。
6. 请求增强。

有时这是滥用-如果一个功能是如此糟糕的设计,有人不知道如何使用它,这被归类为6,它从来没有得到修复。

http://fogbugz.stackexchange.com/questions/352/priority-vs-severity

我制定了这个计划,我觉得很容易记住:

• 附言:秒很重要,例如服务器着火了
• 警察:天很重要,正常的优先级
• pw:周很重要,即优先级较低

这与Debian的方案大致相似: http://www.debian.org/Bugs/Developer#severities

附言:你也可以选择中间的紧急情况,如“pMH”之间的“分钟的事”和“小时的事”。或者说“博士”介于“小时床垫”和“日子很重要”之间——大致上说,“不要为了这个而熬夜,但在完成之前不要做任何事情”。