缺陷分级流程图（bug triage）
缺陷分级流程图：缺陷受理、复现、重复项检查、严重程度与优先级、升级、修复、代码审查、QA 验证与发布上线。
运作方式
把泳道改成你们真实的角色
把报告人、支持、分级负责人、研发与 QA 换成你们自己的职能。小团队常把支持与分级合并成一条泳道；没有专职 QA 的团队通常把验证交给另一位工程师。按决策者划分泳道，而不是按人划分——否则只要有人换岗，图就不再符合现实。
把你们的严重程度与优先级定义写在分级步骤上
严重程度是缺陷一旦发生所造成的影响；优先级是它什么时候会被处理。为每一个等级配一个具体例子，例如最高级是数据丢失或结账流程被阻断，最低级是一处外观错位。没有例子，所有报告都会以最高等级抵达，这个字段也就不再承载任何信息。
设定升级的阈值
把笼统的“是否严重或生产环境宕机？”换成你们真实的触发条件：受影响的客户数量、被阻断的收入路径、面临风险的数据。写明谁有权宣布一次事件，以及事件流程在哪里——分级在那一刻把缺陷交接出去，而缺陷记录仍然开着，等待永久修复。
决定信息回路要跑多久
“报告人是否在期限内回复？”这一决策需要一个写明的等待期，通常还需要一次催办。把这个数字写在步骤上。没有它，那些从来无法复现的报告会无限期地开着，待办队列也就不再反映真实的工作量。
就验证的含义以及重新打开的去向达成一致
写明 QA 是对照报告人最初的复现步骤验证、对照回归测试套件验证，还是两者都做。这份模板把验证失败退回到同一条记录上的开发环节，让历史留在一处。如果重新打开的缺陷应当重新排定优先级、而不是被直接接着处理，就把它改成退回分级。
把它发布出去，并只保留一个现行版本
把图放在缺陷报告表单旁边和值班运行手册里，取得支持、研发与 QA 的签署确认，并保留历史版本，以便看出流程是何时改动的。每当有一个缺陷的解决时间远超应有水平，就把它拿出来重看一遍，修掉它卡住的那一步。
常见问题
缺陷分级流程包含哪些阶段？
在多数团队里是五个。受理，报告在这里被登记，细节要足够支撑后续行动。复现，支持人员在这里确认缺陷确实存在，而不是配置问题或用户操作失误。分级，在这里关联重复项，并赋予严重程度、优先级和负责团队。修复，涵盖开发与代码审查。验证，QA 在这里对照最初的报告检查修复，然后发布并通知报告人。上面的图正是把这五个阶段作为阶段列，其中复现与分级承载了完成大部分工作的那些决策。
严重程度与优先级有什么区别？
严重程度描述缺陷造成的影响：数据丢失、工作流被阻断、外观问题。优先级描述它什么时候会被处理。两者回答的是不同的问题，应当保持为两个独立字段。一处已公开价格上的错字是低严重程度、高优先级；只有两个客户在用的功能崩溃，可能是高严重程度、低优先级。把它们合并成一个字段，是分级流程失去可信度最常见的原因——因为最后所有东西都堆在量表的顶端。
缺陷分级应该多久跑一次，谁需要在场？
对上一次之后新提出的所有内容做一次简短的例行梳理：面向消费者的在线产品每天一次，发布周期较慢的团队每周两次。通常三个角色就足以做出决定：一位能说清客户影响的支持人员，一位对严重程度与优先级负责的分级负责人，以及一位知道哪个团队拥有相关代码的研发负责人。任何严重问题或生产环境宕机都不应等到会上——这也是这张图把它立刻升级为事件、而不是排进队列的原因。
无法复现的缺陷应该怎么处理？
关闭它，但必须在走完一个明确的回路之后。就缺失的细节索取一次（构建版本、环境、准确步骤、一段屏幕录像），在写明的等待期内催办一次，然后关闭为“无法复现”，记录理由，并明确邀请对方在问题再次出现时重新打开。这份模板把这个回路画成报告人泳道中的一个决策，而不是留给个人判断，因为无法复现却永远开着的报告，正是把待办队列变成没人看的清单的东西。