质量内建——缺陷管理实践分享

既然无法完全阻止缺陷的出现，那如何确保已发生的缺陷得到有效的处理，如何利用已有缺陷来指导质量内建过程，是我们需要考虑的，也就是缺陷管理的内容。

敏捷测试原则中有一条是：预防缺陷，而不是关注缺陷的数量。在敏捷开发中，虽然我们采取了各种措施预防缺陷的发生，例如精准的自动化测试、代码检视、故事卡验收等等，但是并不能保证没有缺陷发生，一个零缺陷的产品也不现实。既然无法完全阻止缺陷的出现，那如何确保已发生的缺陷得到有效的处理，如何利用已有缺陷来指导质量内建过程，是我们需要考虑的，也就是缺陷管理的内容。本文以某实际项目的缺陷管理为例，结合自己的所思所想，讲述缺陷的记录、流转和分析。

1. 缺陷记录

1.1 哪些缺陷该被记录？

在记录缺陷前，我们要理清楚需要记录的缺陷有哪些，是不是每一个缺陷都应该被记录。一般来讲，缺陷分为两类： 一类是迭代内缺陷 ，即在迭代新功能开发时，故事验收或测试阶段发生的缺陷； 另一类则是生产缺陷 ，我们是允许生产缺陷的存在的，但前提是缺陷影响范围可控，或者可以在用户发现前发现缺陷（测试右移），并且要具备快速修复或者回滚的能力。

对于迭代内缺陷，一般发现阶段分为故事卡验收阶段，功能测试阶段，回归测试阶段。 对于故事卡验收阶段发现的缺陷，是否需要记录可视情况而定 ，一般而言不需要记录，因为此时故事卡仍在开发阶段，开发同学仍然工作在这张卡上，上下文充足，修复缺陷成本较低，可以直接备注在卡片上，等下一次故事卡验收的时候再验证是否修复。 对于测试阶段和回归测试阶段的缺陷，建议记录下来 ，因为此时开发这张卡片功能的开发同学已工作在其他卡片上，没有办法及时修复该缺陷，或者修复该缺陷的或许是其他开发人员，那么就需要将缺陷记录下来便于跟踪。

对于生产缺陷，每一个都应该被重视并且深入分析，故需要记录下来。

1.2 记录工具

在选择缺陷记录工具的时候，要考虑以下几点：

（1） 该工具是否支持协同工作？

缺陷和故事卡一样重要，是各个角色都需要关心的事情，即意味着各个角色都需要能够查看、操作缺陷记录工具，所以缺陷记录工具需要支持协同工作。

（2） 该工具是否容易学习？

基于第一点，团队成员均需要操作该工具，不管是否有技术背景，所以需要一个学习成本低的工具。

（3） 该工具是否易于跟踪缺陷状态？

缺陷和故事卡一样存在流转状态，也会有不同的人员工作在该缺陷上（开发人员、测试人员），所以记录工具最好具有状态流转标识，当然你也可以手动记录其状态，但能让工具帮你做的事情为什么不利用工具呢？

（4） 该工具是否能清晰记录缺陷？

下一小节会讲到缺陷记录的要素，选择的工具需要能清晰表达这些要素。

（5） 该工具是否便于统计分析？

缺陷管理中很重要的一部分是缺陷分析，缺陷分析当然是基于数据的，这些数据可以手动收集，如果工具能自动帮你做一些统计那是最好的。

所选择的工具不一定需要具备以上提到的所有特征，但是 支持协同工作、易于跟踪缺陷状态和清晰记录缺陷是必不可少的 ，其余特征可根据项目情况而定。我所在的项目选择的记录工具是看板，是项目基于 Jira 定制化开发的一个协同办公系统，在这里我们可以将其视为和 Jira 无异。我们在故事卡的泳道下面新建了一个跟踪缺陷卡的泳道，一个缺陷记录一张卡片，这样大家就可以像操作故事卡一样操作缺陷卡。它支持添加自定义标签的，标注卡片优先级，添加附件，充分满足缺陷关联的内容。也支持导出卡片数据，对之后的缺陷分析十分有帮助。

使用 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 天时，我们会在站会结束后团队所有成员一起回顾板子上仍未修复的缺陷卡，大致同步优先级以及上下文。

2.2 生产缺陷流转过程

在生产缺陷发生后，我们会先决定其优先级以及处理流程，然后快速修复，并对其深入分析，其流转过程如下图所示：

3. 缺陷分析

敏捷测试原则说我们应该预防缺陷而不是关注缺陷的数量，所以对于缺陷分析，我们的出发点是：对已发生的缺陷进行深入分析，从中找到问题所在，以达到预防缺陷的目的。

3.1 分析周期

迭代内缺陷的数量比较多，而且一般大多数都是开发逻辑错误造成的，一般而言分析价值不大。如果每个迭代平稳运行，缺陷数量平稳，建议不用特意分析，毕竟分析缺陷是耗时的。如果某个迭代明显感觉缺陷数量增长，可以针对性对本迭代缺陷进行分析。当然，如果你有充分的时间，可以将缺陷分析作为一项日常工作。而对于生产缺陷，每一个都值得被重视。2.2 节讲述的流转过程，其中我们就已经对其进行分析了，分析其问题出在哪儿，然后补充相应的测试。如果想要对生产缺陷进行归类、趋势分析，那么就需要有一定的数据才可以，而生产缺陷不常有。所以其分析周期建议是 1 个月，或者 3 个月，甚至 6 个月，视各个项目组的情况而定。

3.2 分析角度

我们组常用的分析角度有以下几个，不同的项目侧重点会有所不同。

（1） 缺陷根因

可以将缺陷一一分析后进行归类，根因可以分类为：需求缺失或者不清晰、技术方案设计问题、代码逻辑错误、测试未覆盖、环境相关（硬件、软件、第三方等）。分类后如果某一类问题较突出，则可以针对性产出改进事项。

（2） 缺陷发现阶段

针对迭代内缺陷，发现阶段可以归类为：故事验收阶段、功能测试阶段、回归测试阶段。我们知道，缺陷越早发现修复成本越低，如果分析后发现某一阶段出现的缺陷较多，应该去反思是哪个环节错了，我们是否可以更早的暴露缺陷。

（3） 缺陷所属功能模块

功能所属模块根据系统不同而不同，这一类分析帮助我们思考，某一块存在的缺陷多是因为存在技术债还是测试覆盖不够，可以帮助我们改进质量策略。

（4） 缺陷数量趋势

如果可以，对于迭代内缺陷可以维护一份数量趋势图，就不需要我们靠直觉去感受哪个迭代缺陷多，而是有真实的数据作为依据，更具说服力。对于生产缺陷，建议可以维护一份数量趋势图，因为生产缺陷数量走势也是反应我们产品质量的一个重要维度。

（5） 缺陷可识别阶段

这一分类主要针对生产缺陷，缺陷可识别阶段可以归类为：需求分析阶段、开发阶段、测试阶段、发布阶段，难以识别。这样分类的初衷不在于归过于某一角色，某一人，而是为了进一步分析是哪一阶段的实践有缺失，需要进一步改善。

（6） 缺陷类型

缺陷类型可以归类为：功能缺陷，性能缺陷，安全缺陷。敏捷项目中的 QA 需要关注产品各个方面的质量，包括性能、安全等，将缺陷类型划分清楚，可以指导补充我们薄弱的地方。

这些分析维度并不是一开始就是这样的，途中经历过多个版本，有增有减。比如一开始我们没有“缺陷类型”这个分析维度，将所有的缺陷都归为功能缺陷，后来逐渐关注平台的安全问题，以及随着平台用户增加，也出现过性能问题，所以加入了“缺陷类型”这个字段。又例如，我们一直保持着“缺陷所属功能模块”这个分析维度，而且比较重视该维度分析，因为通过对它的分析常常能发现一些问题。所以分析维度不是固定一层不变的，是可以根据项目实际情况择优选择的。

3.3 分析工具

数据有了，就需要将数据可视化出来，便于分析，便于展示给团队。我们项目组曾使用过的分析工具有：

（1） Jira

一开始我们使用的 Jira 记录缺陷，Jira 可以根据卡片自动生成图表，饼图、趋势图都可以，所以记录分析一体就很方便。

（2） ppt

到后期，使用看板，看板没有图表分析的功能。那么我们就将看板数据导出，然后导入 PPT 画图。只要记录的缺陷卡片规范，也不是很费时，但没办法展示趋势，只能展示导出阶段的数据。

（3） Tableau

是一款商业的数据分析工具，可以画各种图，对于展示趋势图也很方便。但是上手成本并不低，而且它主要的功能是进行数据分析，画图只是它的九牛一毛，用它做缺陷分析有点大材小用的意思了。当然也需要现将缺陷数据从看板导出然后导入 Tableau。

（4） 定制化开发看板插件

我们项目组缺陷分析的工作在团队内是得到认可的，分析缺陷比较耗时的问题在迭代回顾会时引起大家的关注。于是通过团队的努力，我们在迭代内排了一定工作量给开发同学基于看板开发了一款用于卡片分析的插件，该插件可以分析故事卡的工具量、投入比等，也可以统计缺陷数量，按缺陷标签分析自动生成图表。算是团队定制化的插件，也具有一定普适性，列入了看板系统官方推荐插件。如果使用 Jira/Trello 管理缺陷的团队，也可以尝试开发一些定制化的缺陷/故事卡分析插件。

以上就是本人基于项目实践总结的缺陷管理相关内容，主要在于缺陷管理流程和思路的分析，希望对大家有所帮助，也欢迎大家多多交流。

作者介绍：

蔡群尧，ThoughtWorks 质量分析师，有多个敏捷项目质量保障经验，熟悉多种 API、UI 自动化测试框架，善于结合项目实际情况落地敏捷实践。

本文转载自 ThoughtWorks 洞见。

原文链接：

质量内建——缺陷管理实践分享