缺陷跟踪看板|从受理到复现确认与修复发布

项目管理与开发

缺陷跟踪看板|从受理到复现确认与修复发布

这是供收到问题报告的开发团队使用的模板,从受理当天打开,一直用到修复发布为止。白板上以按影响度×发生频率决定处理顺序的矩阵为中心,列出分诊的前提、附填写示例的复现步骤模板、从受理到发布的6个环节,以及无法复现时的判断标准。任务看板分为报告受理、复现确认、修复中、验证中、已发布这5列,受理、复现、修复、发布、共享这5个父任务及其子任务全部处于未开始。

0 点赞 0 复制 作者: WeProcess
缺陷管理 质量保证 问题处理 复现步骤 发布验证
免费注册并使用此模板

免费注册后,即可从模板市场复制并使用此模板

白板预览

预览模式 缺陷跟踪看板|从受理到复现确认与修复发布

白板预览

① 缺陷处理的前提(团队最先定好) ② 影响度 × 发生频率(决定处理顺序) 重 × 偶尔发生 重 × 一直发生 轻 × 偶尔发生 轻 × 一直发生 ③ 复现步骤模板(直接贴进卡片说明栏) ④ 从受理到修复发布 ⑤ 无法复现时 ⑥ 修复前要确认的事 ⑦ 可以收尾的条件 缺陷跟踪看板 使用方法:① 把报告做成卡片 → ... 处理方针与收尾条件 运营规则与流程 暂停标准与卡点 填写示例与调查笔记 入口只有一个所有报告都要做成这个看板上的卡片。聊天里收到的,由发现的人先做成卡片再回复。 处理顺序按影响度决定不按报告到达的先后,而是先用下方矩阵决定位置,再指定负责人。 优先于其他工作的基准生产环境数据损坏/计费重复扣款。这两种情况优先于所有进行中的工作。 严重度填写示例Sev1:结算对所有用户失败Sev2:特定浏览器无法保存Sev3:显示错乱 縦軸: 影响度(轻 → 重) / ... 在本冲刺内修复。多数情况下复现条件还没缩小,先花时间找出条件。 最优先。暂停其他工作立即处理,即使还没查清原因也先给出止损的临时方案。 先积累起来,等触碰相关部分时一并修复。3个月没有动静就先关闭。 所有人每天都会遇到,体感影响很大。从工作量小的开始定期消化。 ① 环境系统 / 浏览器 / 应用版本 / 套餐。例:macOS 15、Chrome 130、付费套餐 ② 步骤用编号写,粒度要让别人也能照做。例:1. 打开项目 2. 把截止日期留空 3. 点击保存 ③ 预期与实际例:预期=保存后返回列表/实际=保存按钮一直是灰色没有反应 ④ 频率与证据例:5次中5次都发生。附上截图和控制台报错,并写明发生时间 ① 受理把报告做成卡片确认模板的4个项目是否都已填写,缺少时向报告者询问。 ② 分诊放进矩阵用影响度和频率决定象限,当场定出处理顺序和负责人。 ③ 复现确认亲手重现确认是否按相同步骤发生。若不能复现就更换条件再试3次。 ④ 定位原因缩小范围核对从何时开始发生与最近的改动,缩小到有问题的代码。 ⑤ 修复与验证与测试成对先加入能捕捉同一问题的测试再修复,并在接近生产的环境中确认。 ⑥ 发布回复报告者确认生产环境已修复,并告知结果和可以停用临时方案。 怀疑步骤有遗漏(请对方录屏) 怀疑环境差异(版本、网络、扩展程序) 尝试3次仍无法复现就先退回 退回时附上“已尝试过什么” 从何时开始发生(核对最近的改动) 是否还有同一原因的其他报告 能否先提供临时应对方案 已加入防再发测试 已确认生产环境修复 已告知报告者结果 原因倾向按月回顾
100%

拖动可平移,滚动可缩放

任务看板内容

报告受理 16 项

建立缺陷受理入口
确认能否复现
定位原因并修复
验证后发布
共享结果并收尾
发放报告模板
制定严重度标准
按步骤重现
排查发生环境
回复无法复现
缩小原因范围
编写防再发测试
用同等环境复验
确认发布步骤
告知报告者结果
回顾原因倾向

复现确认 0 项

修复中 0 项

验证中 0 项

已发布 0 项

← 返回模板一览