问题等级大致相当于严重性等级，可以将问题等级0与1合并，然后按下式取值：

　　严重性等级＝6－问题等级

　　严重性等级与优先级有交叉的情况，说明关注点不同。依据前面的说明：

　　风险优先级数＝严重性×优先级×可能性

　　一般用严重性等级（严重度）与优先级相乘确定实际应先修改哪个错误，忽略可能性（错误出现的几率）；如果明确知道功能执行频率的差异，日常操作与月统计功能的执行频率相差很大，可以为可能性分配适当的数值，使之影响修改的顺序。个别情况下错误有一定的相关性，这是应优先修改聚簇的错误。

　　5、设置错误跟踪，添加动态信息

　　需要明确：目前谁负责完成某错误的改正？解决问题进展是否顺利？什么时候能修复错误？

　　5.1 使用状态来管理错误生命周期

　　可供参考的生命周期：

　　1）评审：决定是否需要对某项错误报告进行公开。

　　2）驳回：份量不够，或需要进一步证实，或需要补充信息。

　　3）公开：完全描述并隔离了问题，把问题公布给开发团队，必要时给其他相关方，例如：共同的上级领导或者质量监督管理组织或部门、销售部门（如果临近发布日期）、维护服务部门（以便他们知道该错误的存在，向客户致歉并承诺适当时机将消除错误、更新程序）等。

　　4）分配：错误归类分级à开发经理à开发人员。这一过程至少需要两级确认，首先，测试经理或负责人需要确认错误报告没有纰漏，错误分类分级合理，提交给开发经理时没有异议，或者异议已得到合理的解释，测试团队不需要补充材料说明问题；其次，开发经理明确理解了问题本身，把修改任务下达给开发人员。一般来说，测试团队不需要关心由谁来修改错误，只要能改好就行，所以好像不用关心任务下达，但实际上这里有一个潜在地威胁，即开发团队忙于其他工作，可能暂时搁置这些错误，如果测试团队不了解这一重要信息，将会耽误许多时间等待未进行的问题修改。所以测试团队需要了解修改进程，以便及时与相关方进行协商，或者调整自己的工作安排。

　　5）测试：开发小组报告彻底修复，提交验收测试和回归测试。

　　6）重新公开：修复后的验收测试失败，重新公开错误报告；如果通过了验收测试未通过回归测试，公开新的错误报告。（引入了新错误）

　　7）关闭：如果修复通过验收测试，关闭错误报告。

　　8）延迟：延迟修复，带伤发布。可能下次发布时修复。

　　5.2 强调职责和业务关系

　　跟踪错误分配的人员和预期修复日期，利于估计安排测试工作。如果出现“踢皮球”，错误被多次重新分配，可能严重影响修复和测试。

　　对有关人员的工作进行跟踪：明确开发人员、测试人员的职责和业务关系，以及交流方式和制度，协调并控制好过程，以解决问题：软件错误问题、测试报告问题、交流问题、修改执行问题等等。

　　状态变化时记录日志，说明责任已完成情况。不能当作日记用，事务性记录可能会浪费别人的时间。中间状态可按协约记录。

　　好的错误跟踪系统应能适合两类工作流：正常工作流和特殊工作流。在工作流中各个角色互相配合，才可能尽早到达终止状态。

　　5.3 关键转移：隔离到调试

　　测试组织与开发人员在关键转移：隔离到调试的界限上应达成一致，但实际与期望结果或行为之间常有差异，必须回答以下问题：

　　1）什么是再现错误现象要求的准确性和最少步骤？这些步骤成功再现错误的几率是多少？

　　2）故障说明是测试错误还是被测系统的错误？测试错误：测试系统或测试人员的错误，被测系统的错误：应该报告的错误。

　　3）影响错误现象的外部因素是什么？即使同样的方法，用例可能不一样，描述更是因人而异。