QA 缺陷管控
面向发布就绪 QA 的缺陷管理软件
为 QA 提供受控记录：测试了什么、在哪个环境测试、针对哪个构建版本，并在发布决策前清楚呈现验证失败或受阻情况。
登录后可查看已填充的视图，再安装带示例数据的应用，以测试关联记录、决策和仪表板。
避免错误关闭的 QA 管控
缺陷管理软件应保留观察到的故障、候选修复、测试执行和发布之间的关系。它必须像呈现已通过工作一样清楚呈现失败和受阻验证，帮助发布负责人区分真实就绪与乐观状态。
- 将验证与实施进度分开记录
- 失败和受阻结果始终可见
- 发布决策包含阻断项和已知风险
每次验证都是独立记录
即使测试失败，证据也应完整保留
失败的测试不是噪声；它说明缺陷为何重开，以及下一候选版本需要修正什么。
明确候选版本
测试具体的构建版本、发布版本和环境。
说明测试范围
记录回归覆盖范围、设备或配置以及预期结果。
选择真实结果
通过、失败和受阻是三种不同的决策。
保留证据
附上观察结果，以及重开或关闭的原因。
发布决策
将缺陷状态转化为可供发布判断的风险视图
发布负责人需要看到阻断项数量和证据，而不是一整面互不关联的工单。
| 信号 | Question | 决策用途 |
|---|---|---|
| 未解决的严重缺陷 | 影响生产的问题是否仍未解决？ | 除非明确接受风险，否则暂缓发布。 |
| 待验证 | 有多少声称完成的工作尚未测试？ | 这表示不确定性，而不是完成。 |
| 失败或受阻的测试 | 哪些修复缺少可用证据？ | 退回、延期，或接受并记录风险。 |
| 重新打开的缺陷 | 哪些修复未能奏效？ | 反映回归情况和诊断质量。 |
软件缺陷与质量记录
区分发布缺陷与 CAPA、不合格项
两者用词可能重叠，但受管控的流程和证据不同。
本页适用于
与构建版本、候选修复、验证执行和发布决策相关的软件行为。
质量管理适用于
供应商不合格、审计发现、CAPA、受控质量事件和监管证据。
问题与适用边界
QA 与发布团队常问的缺陷管理问题
说明验证、重新打开和发布风险应如何运作。
Bug 与 defect 有什么区别？
团队通常会混用这两个词。本页所说的 defect 更强调 QA 证据和发布风险，而缺陷跟踪页更强调可复现性与修复生命周期。
受阻的测试可以算作通过吗？
不可以。测试受阻意味着无法取得预期证据。应保持其可见，并决定是解除阻碍、延期变更，还是接受并记录风险。
谁应该关闭缺陷？
应在约定候选版本验证通过后关闭。修复实施人员可以将其标记为待验证，但测试结果应由 QA 或指定验证人记录。
Jodoo 如何帮助判断发布就绪度？
示例应用将缺陷和验证记录关联到发布就绪记录，显示未解决的严重缺陷、待检查事项、失败或受阻测试以及最终决策。
查看“已修复”背后的证据
查看失败、受阻和重新打开的示例
了解 Jodoo 如何将确切构建版本和 QA 结果关联到发布决策。