如何确定错误的优先级？

在我目前的公司中,测试和开发团队之间对于bug的严重程度尚不清楚？有些论据来回减少或增加严重性.我们现在还不知道任何列出规则的文件.测试人员根据他的直觉提出错误并分配优先级.开发人员会根据他的负载或其他因素请求更改.

错误的严重性/优先级如何分类？是否有任何标准可以指导如何根据客户需求,时间线和其他因素确定软件缺陷优先级？

使用故意与严重性或影响无关的优先级,并仅描述计划中错误的概念位置.此字段将确定哪些错误可以处理,因此需要非常清楚错误的事实是否未公开进行协商.

使用故意具有与调度或优先级无关的具体,可验证定义的严重性级别.我已经成功地使用了Debian BTS使用的严重性定义,这些定义一般适用于编程项目.

这样,严重性更多地是一个可验证的事实,与优先权声明无关.该优先级是就可以自由地进行调整上下通过谈判也好,不影响的严重性领域的事实性信息.

试图将"严重性"和"优先级"混合在一个单独的领域中会导致灵魂消耗的争论和浪费时间.错误记者需要一个确实的事实指南来确定错误的"坏",这需要由独立的各方轻松达成一致.另一方面,优先级是谈判和安排游戏的正确目标.

我在紧急控制中心系统上工作,所以这组错误级别有点,很...... 极端:

有人死了

需要DR调用的总系统故障

服务器故障需要工程师响应

涉及失去呼叫连续性的失败

涉及数据丢失的失败

记录的数据不正确

应用程序失败 - 不可恢复

应用程序故障 - 不可恢复,但会自动重新启动

不符合要求规范,没有解决方法

不符合要求规范,但有解决方法

化妆品 - 布局等

实际上是功能请求

这是我的头脑.如果你想知道,它是从最极端到最少:-)