缺陷分类是一个简单的过程，可以帮助开发团队仅根据缺陷的严重性和优先级来解决和修复缺陷。这是根据缺陷的严重性，引起的风险和发生的频率对缺陷进行优先级排序的过程。
- 新的 ：
每当首次发现缺陷时，就会将此新缺陷添加到缺陷跟踪系统中。 - 在调查中 ：
然后，团队负责人确定或评估缺陷报告是否正确。评估缺陷报告时，请考虑以下准则：- 缺陷报告格式是否正确?
- 是否会事先报告此特定缺陷?
- 谁发现了缺陷?
- 造成缺陷的原因是什么或问题的严重性是什么?
(一世)。危急 ：-
严重问题意味着由于缺陷，系统的主要功能已停止工作。
(ii)。在两者之间–
属于此类的缺陷可以在缺陷分类会议中讨论。
(iii)。低的 ：
此类别下的缺陷不太严重，并且仅对内部用户可见。 - 拒绝了 ：
如果缺陷报告重复，或者分类小组无法复制问题，或者没有维护正确的缺陷报告格式，则特定的缺陷分类报告将被拒绝。 - 确认的 ：
如果一切正确，则确认缺陷报告，然后进一步等待解决问题或缺陷。 - 开发进行中：
在这种情况下，缺陷处于冲刺状态，即缺陷正在处理中，尤其是用于解决和修复缺陷的过程。简而言之，缺陷是无法解决的。 - 发行日期：
最终，缺陷得到了彻底解决和修复。
缺陷分类规则：
缺陷分类的几条规则如下：
- 报告的缺陷需要进行检查。
- 接受的缺陷需要进行优先排序，并且还应附加严重性。
- 对于测试团队，被拒绝的缺陷应具有合理的描述，即合理或可信的描述。
- 每个缺陷都需要分配给适当的团队或个人。
- 应该对被接受的每个缺陷的主要原因或根本原因进行分析。
缺陷分类期间发生的一些挑战：
- 有时，标准的缺陷跟踪系统不可用。
- 优先级和严重性未正确分配给特定缺陷。
- 测试团队，开发团队，业务利益相关者和产品所有者之间没有适当的沟通。
- 在缺陷分类会议期间没有适当的沟通。