3. 缺陷生命周期设计
缺陷生命周期设计的本质，是把“一个缺陷从被发现到被确认解决”的全过程，固化成一条可执行、可审计、可度量的状态机。在 Jira 中，这条状态机由三部分共同构成：状态（Status）定义“缺陷当前处于哪个阶段”，转换（Transition）定义“允许从哪个状态走到哪个状态”，工作流机制（条件、验证器、后处理功能）定义“这次转换是否被允许、需要填写什么、转换后自动发生什么”。三者缺一，工作流就只是画在纸上的箭头，无法真正约束团队行为。
一、先定义状态：五个核心阶段与两个可选分支
对于大多数研发团队，缺陷生命周期的核心状态可以收敛为五个：新建（Open/New）、已分配（Assigned/In Progress）、已修复（Fixed/Resolved）、验证中（In Verification）、已关闭（Closed）。此外通常还需要两个“非正常出口”：已拒绝（Rejected）用于判定不是缺陷或重复提交，重新打开（Reopened）用于验证不通过时回退。
状态命名建议遵循两条原则：一是语义唯一，例如“已修复”只表示开发自测通过并提交待验证，不表示问题已解决；二是状态数量克制，状态越多，流转路径越复杂，看板越难读。若团队已有“待复现”“待补充信息”等需求，可先用“新建”状态加字段标记实现，避免过早引入新状态。
二、设计转换路径：允许哪些箭头存在
状态确定后，需要明确每一条合法转换。典型路径如下：
- 新建 → 已分配：由测试或产品负责人指派给具体开发人员；
- 新建 → 已拒绝：判定为重复、非缺陷或无法复现；
- 已分配 → 已修复：开发完成修改并提交代码；
- 已修复 → 验证中：测试人员开始验证；
- 验证中 → 已关闭：验证通过；
- 验证中 → 重新打开：验证不通过，退回开发；
- 重新打开 → 已分配：重新指派处理人；
- 已拒绝 → 重新打开：原判定被推翻，缺陷重新激活。
需要特别注意的是，不应允许“新建 → 已关闭”或“已分配 → 已关闭”这类跳步转换。跳步会让验证环节形同虚设，也会让“缺陷平均修复时长”等指标失真。如果确实存在“开发直接确认无需修改”的场景，应通过“已拒绝”或“已修复”加说明字段来表达，而不是绕过验证。
三、配置工作流条件：谁有权推动状态
条件（Condition）决定“当前用户能否看到并执行这条转换”。在 Jira 工作流编辑器中，每条转换都可以挂载一个或多个条件，常见类型包括：
- Only Assignee Condition：仅当前经办人可以执行，适合“已分配 → 已修复”；
- Only Reporter Condition：仅报告人可以执行，适合“验证中 → 已关闭”或“验证中 → 重新打开”；
- User Is In Group / Project Role：限定测试组或质量角色，适合“已修复 → 验证中”；
- Permission Condition：基于“Resolve Issues”“Close Issues”等权限位控制。
条件配置过松，状态会被随意推动；配置过严，则会出现“没人能关闭缺陷”的僵局。一个实用做法是：把“验证通过/不通过”的判定权交给报告人或测试角色，把“修复完成”的判定权交给经办人，其余转换保持项目成员可执行。
四、配置验证器：转换前必须补齐的信息
验证器（Validator）在转换真正发生前运行，用于强制字段完整性。它是缺陷生命周期中“防漏填”的关键机制。典型配置示例：
| 转换 | 验证器 | 目的 |
|---|---|---|
| 已分配 → 已修复 | Field Required：修复版本、修复说明 | 确保修复可追溯 |
| 已修复 → 验证中 | Field Required：验证环境 | 明确验证条件 |
| 验证中 → 已关闭 | Field Required：验证结论；Field has value：验证人 | 关闭必须有依据 |
| 验证中 → 重新打开 | Field Required：失败原因 | 回退原因可分析 |
| 新建 → 已拒绝 | Field Required：拒绝理由 | 避免随意拒绝 |
验证器与条件不同：条件不满足时用户看不到转换按钮，验证器不满足时按钮可见但点击后报错并提示补填。因此，“必须填写”类约束应优先用验证器，而不是用条件隐藏按钮，否则用户会困惑“为什么我不能关闭”。
五、配置后处理功能：转换后自动发生什么
后处理功能（Post Function）在转换成功后按顺序执行，是自动化程度最高的部分。常见配置包括：
- Update Issue Field：转换到“已修复”时自动把“修复版本”设为当前未发布版本；
- Assign to Reporter：转换到“已修复”时自动把经办人改为报告人，进入验证环节；
- Set Resolution：转换到“已关闭”时设置解决结果为“已修复”；转换到“已拒绝”时设为“不予处理”；
- Fire Event / Send Notification：触发通知，提醒验证人及时处理；
- Update Issue Status：在特定场景下联动父任务或关联缺陷。
后处理的执行顺序很重要。例如“先设置解决结果，再发送通知”，通知内容才能带上正确的解决结果。Jira 允许拖拽调整顺序，建议把“字段更新”放在“通知/事件”之前。
配置示例：已修复 → 验证中 的完整转换设置
条件：User Is In Group "qa-team"
验证器：Field Required → 验证环境
后处理：
1. Update Issue Field → 经办人 = 报告人
2. Fire Event → Issue Resolved
3. Send Notification → 报告人、测试负责人六、验证工作流是否真正闭环
配置完成后，不要只看设计器里的箭头，而要用真实缺陷走一遍。建议至少覆盖四条路径：正常修复关闭、验证不通过回退、新建即拒绝、拒绝后重新激活。每条路径都检查三件事：按钮是否出现在正确的人面前、必填字段是否被拦截、转换后字段和通知是否符合预期。
一个常见的闭环缺口是：缺陷关闭后没有记录“解决结果”和“验证版本”，导致后续做质量分析时无法区分“真正修复”和“不予处理”。建议在“已关闭”转换上强制设置 Resolution，并在报表中按 Resolution 分组统计。
缺陷生命周期设计不是一次性的画图工作，而是把质量规则写进工具的过程。状态定义清楚“在哪”，转换定义“怎么走”，条件、验证器和后处理定义“谁能走、要带什么、走完自动做什么”。三者配合，缺陷跟踪才从“记录问题”升级为“驱动质量闭环”。