logo标签列表

如何确定错误的优先级？

language-agnosticprocessbug-tracking
18

在我目前的公司中，测试团队和开发团队并没有清楚地理解一个bug应该有多严重。我们经常争论是将严重性降低还是提高。目前我们不知道是否有任何文件规定了相关规则。测试人员会根据他的直觉提出bug并为其分配优先级。开发人员可能基于其负载或其他因素请求更改。

如何对bug的严重性/优先级进行分类？是否有任何标准指导如何根据客户需求、时间表和其他因素确定软件缺陷的优先级呢？

1
我认为更好的问题标题应该是“如何优先处理错误？”。您可以根据将用于某些目的的尽可能多的标准来“分类”错误，例如错误源调查以进一步预防。 - Daniel Daranas
@Prabhu.S 我很想听听你最终使用了哪种方法？如果是这里提供的某个方法，你也应该接受那个答案。 :) - ZeroOne
15个回答
11

  • 使用优先级别，这些级别故意与严重程度或影响无关，仅描述错误在计划中的概念位置。该字段将确定哪些错误需要处理，因此它是谈判的目标。

  • 使用严重级别，这些级别故意具有具体的、可验证的定义，不容易被谈判改变，且与调度或优先级无关。我已经成功地使用Debian BTS使用的严重性定义，并推广应用于一般编程项目。

这样，严重性更多地成为可验证的事实问题，而不是优先级的陈述。优先级可以通过谈判或其他方式自由调整，而不影响严重性字段中的事实信息。

试图将“严重性”和“优先级”合并到一个字段中将导致耗费精力的争论和浪费时间。错误报告者需要一个坚定的事实指南来确定错误的“严重程度”，并且这需要易于独立方达成共识。另一方面，优先级是正确的谈判和调度游戏的目标。

8

我从事紧急控制中心系统的工作，所以这组错误级别有点...极端：

  • 有人死亡
  • 需要DR调用的总体系统故障
  • 需要工程师响应的服务器故障
  • 涉及呼叫连续性丢失的故障
  • 涉及数据丢失的故障
  • 记录不正确的数据
  • 应用程序故障-无法恢复
  • 应用程序故障-无法恢复，但会自动重新启动
  • 不符合要求规范，无解决方法
  • 不符合要求规范，但有解决方法
  • 美观方面的问题-布局等
  • 实际上是功能请求

这是我想到的。如果你想知道，它是按照最严重到最不严重的顺序排列的 :-)

这是一种情况，其中严重性几乎等于优先级，由于软件的目的。虽然不适用于所有目的，但在其上下文中非常信息丰富和实用，值得一试。 - Daniel Daranas
这确实让那些表面问题变得微不足道了，不是吗？ - John MacIntyre
4

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

严重性（提交缺陷时由提交者设置）

  • 最高（5）：数据丢失，硬件损坏可能或与安全相关的故障
  • 高（4）：功能丧失，没有合理的解决方法
  • 中等（3）：功能丧失，但有合理的解决方法
  • 低（2）：部分功能或特性集（特性仍符合设计要求）的丧失
  • 最低（1）：美观错误

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

  • 最高（5）：该缺陷使系统几乎无法使用。
  • 高（4）：该缺陷将严重影响公司销售和维护该系统的能力。
  • 中等（3）：如果该缺陷存在于系统中，公司将损失一些资金，但按计划完成可能更为重要。发布后修复。
  • 低（2）：不要延迟发布，但是确保在之后解决此问题。
  • 最低（1）：根据时间和资源允许进行修复。

两个数字一起创建了风险优先级数（RPN）。只需将严重性与优先级相乘即可。结果越高，风险越高。25定义了终极缺陷炸弹。1可以在空闲时间或某人感到无聊需要做些事情时完成。

第一个目标：任何类型的最高或高评级的缺陷都应在发布之前修复。 第二个目标：RPN > 8的缺陷应在发布产品之前修复。

当然，这有点人为，但有助于给所有方（支持、QA /测试、工程和产品经理）提供一个工具来设置优先级，而不会摧毁其他方的意见。

3

使用FogBugz替换您的缺陷跟踪系统，并完全摆脱严重性字段。

请参见优先级与严重性

1
我一直在我的团队中同时使用这两种方法，但我同意只使用优先级。打字错误与崩溃的例子很清楚，但可用性更为重要：Opera和Firefox偶尔会崩溃，但我仍然认为它们是好的软件；Lotus Notes很少崩溃，但它在各个方面都很糟糕。 - Daniel Daranas
2
-1：我看不出来在关键的开发工作流程中推荐使用非自由工具是一个好建议。 - bignose
2
"曾经历过".
我在不同的项目中已经多次进行了这种讨论。我们试图将优先级与严重性结合起来，但我学到的教训是：不要将严重性与优先级结合起来！我们进行了许多头脑风暴和会议，最终以“这就是它”的话结束。已经创建了多个指南文档并在不同的“团队”之间传播，但是过了一段时间后，我们发现它最终并没有起作用。不同的“团队”对错误有不同的理解：我们的帮助台对优先级的理解与开发团队或销售团队不同。
同时设置严重性和优先级将很快变得非常混乱，因为：
- 使用数字（1至5之间）时，人们无法知道每个数字的含义。 - 如果一个问题具有最高优先级，但严重性最低怎么办？我相信这种情况肯定会发生！ - 如果有人降低了严重性，他是否需要降低优先级？
"那么你应该怎么做呢？"
- 只使用一种指示器来表示问题的“级别”：无论你如何称呼它。 - 使用数字（例如1-5，但根据您的需求可能更多或更少）来清楚地表示重要性，但结合一个关键词，以便清楚地了解其含义（例如“不错”，“停机”）。对于某些人，优先级1表示最重要的，而对于其他人，则为5->因此，必须使用关键字来指示数字的含义。 - 区分“正常问题”或“红色警报”。在我们的情况下，“红色警报”必须立即解决并立即投入生产。优先级/严重性/无论如何称呼它，只应针对正常问题进行设置，并将忽略“红色警报”。 - 选择一个允许您自定义流程的好工具，但大多数工具都可以。
1

关于标准，IEEE软件异常分类指南是一个标准，但我不确定它被广泛采用。 IEEE 1044.1-1995

似乎您需要订阅IEEE材料。 - Prabhu. S
1

一种选择是让产品负责人确定错误的优先级。虽然对于一个错误有一些普遍的直觉，但制定优先顺序（例如，在修复错误B之前应该先修复错误A等）可以成为产品所有者的责任。

提供给产品所有者的信息越多（清晰简明），就能帮助该个人做出这些决定（例如，有多少用户遇到了错误，由于错误导致哪些功能不可用等）

1
  1. 必须现在完成
  2. 必须在我们发货之前完成
  3. 轻微烦恼（不会阻止用户使用功能）
  4. 边缘情况/远程/来自魔多的测试人员场景

我只是编了一个例子...我的意思是将错误分类不应该成为每周一次长达一小时的仪式。
在我看来，根据流程图进行优先排序是浪费时间。尽快修复Cat#1和#2中出现的错误。如果你发现自己被错误淹没了，就要放慢脚步反思。如果时间表不允许或者有更高优先级的事项，就推迟Cat#3和Cat#4。
关键是，你们所有人都要对这种严重性和期望质量有共同的理解。不要让遵守X的神圣标准拖慢你们交付客户想要的...可用软件的速度。

2
仅仅拥有“优先级”会带来麻烦，因为缺陷报告者没有具体的方式来说明缺陷对他们的影响程度，最终还是会发生关于这个问题的冗长争论。我主张设立一个客观的“严重程度”和一个可协商的“优先级”，以避免导致无休止争论的混淆现象。 - bignose
如果你对将BugX归类到这些槽中有异议...那么使用明确的石碑标准会更加耗费时间。无论如何，坚持使用能完成工作的方法。 - Gishu
1

个人而言，我更喜欢使用两级严重性/优先级模型。我知道单一级别的论点，但在我工作过的地方，通常我只看到两级层次结构效果更好。

支持团队根据客户的意见设置严重性。客户根据支持团队的意见设置优先级。

对于严重性，我使用：

1-阻止/显示停止
2-主要功能不可用（或实际上不可用），没有实际的解决方法
3-主要功能不可用（或...），有解决方法
4-次要功能不可用（或实际上不可用），没有解决方法
5-次要功能不可用（或...），有解决方法
6-美观或其他琐碎问题

然后对于优先级，我只使用高、中、低，但是3-5个级别的任何内容都可以（超过这个范围就太过头了）。

通常我会首先按优先级排序，然后再按严重性排序。这个模型的重要之处在于客户拥有最重要的发言权。如果他们说报告上他们的标志打印方式是最高优先级，那么就会被关注，但是它会在其他客户的高优先级之后被关注，这些问题正在阻止他们登录。

一般来说，我不会发布任何高优先级问题或任何严重程度为1-4的中等优先级问题。显然，在理想的情况下，您会修复所有问题，但我从未有过这样的选择。
1
  • 测试人员指出了有问题的地方
  • 开发人员评估修复所需的工作量
  • 客户决定业务价值，即优先级。
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接