软件测试中的错误/缺陷分类
托马斯·汉密尔顿
什么是“缺陷分类”？
缺陷分级是一个根据缺陷的严重性、发生频率、风险等因素对每个缺陷进行优先级排序的过程。分级一词用于…… 软件测试 / 质量保证部门负责确定新缺陷的严重性和优先级。
这个名称借鉴自急诊医学，在医疗资源有限的情况下，分诊会根据病情的紧急程度对病人进行分类。质量保证团队也面临着同样的困境：缺陷列表总是比发布日期前的可用时间更长，因此必须有人决定哪些问题需要立即修复，哪些问题可以稍后修复，哪些问题可以延后处理。分诊会议就是用来做出并记录这些决定的。
为什么我们需要‘缺陷分类’？
Bug Triage 的目标是评估、确定优先级并分配缺陷的解决方案。团队需要验证缺陷的严重程度，根据需要进行更改，最终确定缺陷的解决方案并分配资源。主要用于敏捷项目管理。
如果没有分类处理，缺陷就会一直滞留在系统中。 trac测试人员会根据报告测试结果选择合适的严重程度来决定任务的优先级，而开发人员则根据个人喜好而非业务影响来选择任务。下面的横幅总结了团队将会议保留在日程表上的原因。
在发布中需要多久进行一次“缺陷分类”？
缺陷分类会议的频率并不固定。这取决于项目情况。
以下是决定缺陷分类会议频率的一些重要因素：
这些重要因素是：
- 根据项目进度
- 系统中的缺陷数量
- 对团队成员可用时间安排的影响
- 项目总体健康状况
通常，缺陷分类会议每周举行两到三次。
随着版本发布临近，节奏也越来越快。团队在短时间内开展工作。 争球 迭代开发通常会在最后一个迭代周期的日常工作中加入简短的紧急响应环节，而周期较长的计划驱动型项目可能会每周进行一次紧急响应，直到…… 回归测试 阶段开始。
“缺陷分类”的强制参与者和其他参与者是谁？
强制参加者
以下项目成员始终参加缺陷分类会议。
- 项目经理
- 测试团队负责人
- 技术主管
- 开发团队负责人
可选参与者
- 开发商介绍
- 测试仪
- 商业分析师
当某个特定缺陷需要他们的意见时，例如业务分析师需要确认所报告的行为是否真的与要求相矛盾，或者是否是伪装的变更请求时，就会邀请可选的与会者参加。
“缺陷分类”期间参与者的角色和职责。
每个强制参会人员都承担着不同的职责，只有当这三位参会人员都提前做好准备时，会议才能按时进行。
测试团队负责人
- 安排错误分类会议并向与会者发送会议通知。
- 创建缺陷报告并在会议前将其发送给所有与会者。
- 确定优先级和 严重 缺陷。
- 进行演示，以便其他成员了解缺陷的根本原因。
- 每个会议记录都会被记录并发送给会议参加者。
开发主管
- 帮助确定缺陷的优先次序。
- 讨论缺陷的难度并解释该缺陷所涉及的风险。
- 将修复缺陷的工作分配给相关开发人员。
- 更新缺陷解决方案并包含开发说明，以防缺少任何信息或开发人员需要任何其他信息。
项目经理
- 帮助确定缺陷的优先次序。
- 讨论 QA 的下一次迭代发布日期。
- 需要确保相关的用户代表也被邀请参加错误分类会议。
项目经理掌握着发布日期，因此，对于任何有争议的缺陷，最终的决定权通常都掌握在该角色手中，如下所示。
“缺陷分类”会议期间会发生什么？
- 测试团队负责人发送包含新缺陷的错误报告。在缺陷分类会议期间，将分析每个缺陷，以查看是否为其分配了正确的优先级和严重性。
- 如果需要的话，可以重新安排优先级。
- 根据缺陷的严重程度进行分析和评估。
- 这包括有关缺陷的复杂性、风险、拒绝、错误的重新分配的讨论。
- 更新已记录在错误报告中 trac君主制。
- QA 工程师将对每个缺陷进行更改并与每个与会者讨论。
- 通过记录会议的要点，“评论”字段会得到正确更新。
大部分讨论时间都花在了最容易混淆的两个方面：严重性和优先级。这两个指标是独立设定的，一个缺陷可能在一个指标上得分很高，而在另一个指标上得分很低。
| 方面 | 严谨求真 | 优先 |
|---|---|---|
| 它测量什么 | 缺陷对产品或其功能造成的损害程度。 | 相对于其他工作，缺陷必须尽快修复的时间有多长 |
| 通常由 | 报告缺陷的测试人员 | 经初步评估，由项目经理和产品方牵头。 |
| 通过驱动 | 技术影响及受影响的功能 | 业务影响、客户可见性和发布日期 |
| 不匹配示例 | 高危性，低优先级：一个直到下个季度才会使用的功能出现崩溃 | 低严重性，高优先级：首页上的公司名称拼写错误 |
提示： 对单个缺陷的讨论应尽量简短。如果某个问题无法在几分钟内解决，请先将其搁置，指派负责人进行调查，并在下次会议上再讨论，而不是让一个缺陷耗费整个会议时间。
“缺陷分类”的结果是什么？
每次会议结束时，都会准备缺陷分类指标并提供给所有与会者。此报告将作为会议记录，对未来的会议有帮助。
这份报告是分诊与更广泛的层面联系起来的关键点。 缺陷管理流程团队通常会在其中记录以下内容：
- 会议中审查了缺陷，并就每个缺陷的严重程度和优先级达成了一致意见。
- 新分配的缺陷，以及现在拥有这些缺陷的开发人员。
- 缺陷项被推迟处理、拒绝处理或标记为重复项，并记录原因。
- 按严重程度统计未解决缺陷数量，以便观察各个会话的趋势。
- 各项议程将延至下次会议。
因为每一次更改都会被写回原处 tracker，每个项目的状态与其在 ker 中的位置保持一致。 缺陷生命周期这样，下一届会议就可以从一份准确的名单开始，而不是一份过时的名单。
