江苏龙网

  1. 首页 > 人文 > >

缺陷管理，一门关于质量内建的学问( 二 )


使用Jira记录缺陷 ， 主要是便于查看缺陷状态 ， 但随着迭代的完成 ， 缺陷卡片会被归档 ， 每张卡片也是独立的 ， 不利于集中查看和查询 。 这样的流转方式对迭代内缺陷是没有问题的 ， 因为迭代内缺陷一旦修复 ， 后续基本不会有人再去查看关注 。 但对生产缺陷却不一样 ， 每一个生产缺陷都应该被认真对待分析 ， 我们可以将其统一记录在某个地方 ， 用于之后回顾 。 我们项目组的做法是将生产缺陷统一记录在Confluence ， 便于集中查看 ， 只要满足协同办公的软件都可以 ， 在线WPS的Excel ， Google Sheets也是不错的选择 。
使用Jira/Trello这类集需求跟踪为一体的工具来记录缺陷的一大好处是 ， 缺陷记录和故事卡记录在统一系统/面板中 ， 方便团队成员共同查看、维护缺陷 ， 不至于只有QA在关注、维护缺陷 。 查了下网上有许多专门用于缺陷管理的工具 ， 比如Bugout ， 集缺陷记录、跟踪、统计分析于一体 ， 还可以自定义缺陷记录模版、统计字段类型等 ， 还是比较灵活 。 当然还有很多其他很多缺陷管理工具 ， 就不在此赘述了 。
1.3 缺陷记录要素
记录缺陷有两个原则：
（1）描述完整 ， 清晰易读懂
记录的缺陷卡和故事卡一样 ， 需要给团队成员看 ， 所以缺陷卡需要描述完整清晰 。
（2）规范化 ， 便于缺陷分析
分析统计总是基于规范的数据结构 ， 所以在记录缺陷的时候就需要考虑之后缺陷分析需要什么 ， 以此去规范化记录缺陷 。
看板是可以自定义卡片内容模版的 ， 所以定义好模版后 ， 团队任何人都可以根据模版记录缺陷 。 如果使用的工具没办法自定义模版 ， 建议和团队同步记录规则 ， 或者由QA统一记录 。 我们项目组记录的缺陷主要有以下要素：
a.标题
简述缺陷内容 ， 清晰明了 。
b.描述
缺陷发生环境（DEV/ST/预生产/PRD） ， 相关测试数据（ID/用户名等） ， 复现步骤 ， 期望结果 ， 实际结果 ， 备注（截图、日志等） 。
c.优先级
在卡片上备注缺陷的优先级 ， 一般是高、中、低 。
d.缺陷提交人
【缺陷管理，一门关于质量内建的学问】在卡片操作记录里有记录 ， 如果没有操作记录 ， 可以以评论或者参与人的形式添加 ， 以便后续开发人员或QA可以快速找到熟悉上下问的人 。
e.缺陷修复人
分配卡片经办人/参与人员即可 。
f.标签
便于之后的缺陷分析 ， 可以给缺陷打上标签 。 针对生产缺陷 ， 我们会标注以下标签：所属功能模块（根据系统自定义）、可识别阶段（需求阶段/开发阶段/测试阶段/发布阶段/难以识别）、缺陷类型（功能/性能/安全）、影响范围（大/中/小） 。
2. 缺陷流转
每个缺陷也应该像故事卡一样 ， 有它完整的生命周期 ， 下面以我们项目组为例讲述迭代内缺陷和生产缺陷的流转过程 ， 当然每个组情况不一样 ， 可视自身项目组情况而定 。
2.1 迭代内缺陷流转过程
上文讲到 ， 迭代内缺陷和故事卡记录在看板的同一面板的不同泳道 ， 那么缺陷卡的生命周期和故事卡基本是一样的 ， 如下图所示：
缺陷管理，一门关于质量内建的学问
本文插图
针对迭代内的缺陷应该在什么时候修复 ， 我们的处理原则有以下几点：
（1）如果是阻碍开发/测试进度的缺陷 ， 应该被立即修复；
（2）如果是本迭代必须交付的功能相关缺陷 ， 且修复成本高或影响范围大的缺陷 ， 应该被尽早修复；
（3）如果是本迭代必须交付的功能相关缺陷 ， 但修复成本或影响范围较小的缺陷 ， 留到迭代后期修复 ， 在上线前2/3天时 ， 我们会在站会结束后团队所有成员一起回顾板子上仍未修复的缺陷卡 ， 大致同步优先级以及上下文 。


推荐阅读


上一篇：嘉人|行走江湖，怎么能缺少一件超飒皮西服

下一篇：燚燚育儿|“冻龄老妈”穿女儿校服走红，40岁状态依旧青春，网友：女神来了40岁的宝妈成了“校花”在本案例中：40岁的宝妈却活成了20岁的校花宝妈知识小time：产后要怎么恢复保养呢？