7、技术如何做好缺陷管理？

1. 向质量要效率

很多客户在软件项目管理过程中，经常会出现测试兜底质量的情况，同时测试也是质量保障的最重要一环。但是只靠测试人员把控交付的质量是不够的，质量是要嵌入到整个端到端的流程中的。

从精益敏捷的视角来讲，是要建立质量内建机制，既要确保需求的质量，也要确保代码的质量，具体表现为需要明确需求在各个不同状态或阶段间流动的质量。

本文主要介绍缺陷管理方案，通过缺统一收口、明确缺陷管理规范到通过缺陷数据分析，驱动质效提升。

2. 缺陷管理的目标

缺陷管理的首要目标是①零缺陷。

其次针对已发现的缺陷，需要②高质量快速地解决缺陷。

再是通过对缺陷数据的分析和反馈，在③提升交付过程的质量和效率基础上，同步提升产品交付的质量和效率，最终走向零缺陷的目标。

3. 缺陷管理的方案与路径

3.1. 缺陷统一收口，避免漏网之鱼

云效为每一个项目空间提供缺陷服务，关于该项目或该产品的相关人员，发现缺陷，都可以把缺陷录入到这个位置。确保缺陷都统一录入这里。

3.2. 明确缺陷管理规范，促进缺陷高效解决

3.2.1. 明确缺陷修复的工作流

缺陷的正常状态流转为：待确认 -> 处理中 -> 已修复 -> 已关闭

3.2.2. 明确缺陷内容的填写规范

各个企业需要填写的规则各不相同，这里选择几个主要的阐述

• 缺陷内容的描述：缺陷描述、重现步骤、期望结果、实际结果、原因定位和修复建议。

• 严重程度：产品不可用、主要功能错误、普通问题和轻微问题

• 所属模块：模块A、模块B等

• 缺陷深度：很容易发现、正常发现、很难发现等；

• 发现阶段：功能测试阶段、UAT阶段、预发阶段等；

• 引入阶段：需求阶段、编码阶段、测试阶段等；

• 引入原因：需求描述不清晰、需求变更、编码错误、代码编写不规范等

上面这些字段，团队或者项目可以根据自己的情况设定哈。

3.2.3. 明确缺陷响应的SOP

1. 缺陷及时响应率：缺陷发现后，需要及时处理，可是设定缺陷要在一个时间段做响应，譬如5分钟、半个小时或1小时等，可驱动团队及时对缺陷进行响应。

2. 缺陷日清率：缺陷发现后，如果能在24小时内修复缺陷并验证通过，缺陷被清除，到关闭状态。可驱动团队及时对缺陷进行修复。

3.3. 缺陷数据分析，驱动质效提升

缺陷数据相对于需求数据来说，是更容易获取的，而且产研团队对缺陷的发现和解决也是比较重视的。

缺陷数据分析至少包括：分析缺陷及时响应率、缺陷及时解决率，缺陷的平均修复时长，缺陷的库存趋势、缺陷的引入原因分布、缺陷引入阶段分布、缺陷的引入模块分布、对引入原因和引入模块进行二维正交分布分析。

这里分析一个用的比较多的缺陷趋势图。

如上图所示，比较了两种不同的交付模式，横坐标是日期，竖坐标是数量。

• 横坐标上方红色柱子代表这一天发现缺陷数量；

• 横坐标下方绿色柱子代表这一天解决的缺陷数量；

• 橙色曲线代表缺陷存量。

左半部分，团队属于小瀑布的开发模式。“迭代”前期，团队集中设计、编码，引入缺陷，但并未即时地集成和验证。在1号到20号期间，团队一直在引入缺陷（写缺陷），而未能及时的发现它们。缺陷一直掩藏在系统中，直到项目后期，团队才开始集成和测试，缺陷集中爆发，越到后期发现的缺陷，修复困难度大幅提升，修复成本大幅增加。

小瀑布模式下，过程质量差，带来大量的返工、延期和交付质量问题。该模式下，产品的交付时间依赖于何时缺陷能被充分移除，当然不能做到持续交付，也无法快速响应外部的需求和变化。并且，这一模式通常都导致后期的赶工，埋下交付质量隐患。

右半部分，团队开始向持续交付模式演进。在整个迭代过程中，团队以小粒度的需求为单位开发，持续地集成和测试它们，及时发现和解决问题。缺陷库存得到控制，系统始终处于接近可发布状态。这一模式更接近持续发布状态，团队对外的响应能力随之增强。

缺陷趋势图从一个侧面反映了团队的开发和交付模式。它引导团队持续且尽早发现缺陷并及时移除它们。控制缺陷库存，让系统始终处于接近可发布状态，保障了持续交付能力和对外响应能力。

下图是一个团队缺陷趋势图的实例，该图在云效效能洞察上可自动生成

欢迎使用云效效能洞察，做更多的缺陷分析和讨论。

4. 总结

缺陷发现的越早，修复成本就越低，发现的越晚，修复成本就越高，如果到了客户现场，发现了严重的缺陷，可能要付出巨大的成本，还有可能带来丢单或者给公司带来负面的影响。

而不管在哪个阶段，修复缺陷终究都是在返工。如果可以一次性把事情做好，那就没有了返工的成本。所以我们要建立内建质量的机制，把缺陷消灭在源头，做到防患于未然，走向零缺陷。