优先级是表示处理和修正软件缺陷的先后顺序的指标，即哪些缺陷需要优先修正，哪些缺陷可以稍后修正。
确定软件缺陷优先级，更多的是站在软件研发人员的角度，该级别建议由研发人员自己定义。因为缺陷的修正顺序是个复杂的过程，有些不是纯粹技术问题，而且开发人员更熟悉软件代码，能够比测试工程师更清楚修正缺陷的难度和风险。
优先级别划分指缺陷必须被修复的紧急程度，由研发负责人在分配新建缺陷时指定，产品（项目）负责人或经理可参与定夺。由于软件行业不同，还需根据每个行业的特点来定义缺陷优先级。通常优先级的定义参考该缺陷的严重程度，如：
l 紧急级别缺陷应阻止相关研发人员的进一步开发活动，立即进行本缺陷的修复工作。例如，软件的主要功能错误或者造成软件崩溃，数据丢失的缺陷。
l 高级别缺陷应在本次迭代周期内修改完成。例如，影响软件功能和性能的一般缺陷；
l 中级别缺陷需要在本次迭代周期内修改完成，但不排除放到下一周期内解决，但需要项目组讨论决定。例如，本地化软件的某些字符没有翻译或者翻译不准确的缺陷。
l 低级别缺陷是项目完成前修改完成，或根据实际项目情况，择时修改。例如，对软件的质量影响非常轻微或出现几率很低的缺陷。
缺陷生命历程中，操作人员职责确定之后，还要制定缺陷库的相关配置规范，具体规范如下：
1）根据现有项目，配置管理员创建缺陷库，并设置项目用户和权限。
2）设置缺陷库的相关属性。根据现有缺陷库工具，设定出合理的缺陷属性。
3）规定测试人员提交缺陷的书写格式。Bug的详细描述要达到让研发人员清晰这是一个什么问题，看了能够自己复现的程度，所以要详细但要避免冗余。缺陷的编写规范要包含以下几点：
l 测试配置：主要是产品或相关测试要件的配置。
l 测试环境：测试所搭建的软件、硬件、数据环境。
l 测试步骤：这是比较关键的，目的是帮助研发重现缺陷，需要组号列出1、2、3等步骤项。或者指明对应的测试用例。
l 预期结果和实际结果：写到描述中，不但能够做对比，而且能够有效的证明这确实是一个bug。
除了上述描述外还应注意如下：
l 一个缺陷记录只能描述一个bug。
l Bug的唯一性：在提交bug之前，要确认这个bug是否已经被其他人发现并报告（搜索功能）
l 重现：有些bug很容易就重现，有些就很难。如果你能重现一个bug，应该准确的解释必须的条件。应该列出所有的步骤，包括精确的组合，文件名以及你碰到或重现这个问题的操作顺序。如果你能够确认这个问题在任何文件，任何的操作顺序等条件下都会发生，那也做好能够给出一个明确的示例来帮助开发重现。如果发现一个不能重新的bug，就尽可能多的提供有效的信息给开发人员。截图、日志，抓包等对捕获这个bug有帮助的信息可以包含在你的bug报告中
l 定位：对于一个测试人员来说，应该做一些有效的事情来帮助定位问题。要多想会不会是外部的什么特殊原因引起的这个问题？会不会是因为网络的问题导致的问题？或者是应用软件配置错误导致的问题？如果实在不能定位问题原因，是否可以想办法缩小出错的范围？尽量避免是由于测试人员的问题导致误报了bug。测试人员定位bug的能力，一定程度上是测试人员附加值的体现，能够节省项目组相关人员的时间，缩短了回归bug的时间
l 报告bug时要使用中性语言，不要带有感情色彩。不要带有幽默也不要带有任何不满情绪。
4）为了防止缺陷库遭到未经授权的访问和操作，可以将缺陷库成员分配到指定的用户组，用户组权限设置如表2-1所示。