从 TMMI 角度谈谈质量度量

我在前面的文章《聊聊我对质量度量的看法》中曾谈到线上缺陷逃逸率的话题。

前几天技术群有同学问我该如何理解线上缺陷逃逸率，群里有位同学是这么如何的：

“缺陷逃逸率，Defect Escape Percentage，简称 DEP，是指软件产品发布后发现的缺陷数量与该软件产品在整个生命周期发现的所有缺陷数量的比率”。

在 TMMi 体系中，缺陷逃逸率是用来评估交付质量的衡量指标，如果该值低于某个阈值，则可以判断交付质量的好坏。

我在之前的工作中曾经参与过一段时间的企业 TMMi 改进，这篇文章，我会结合关于 TMMi 的一些技术笔记，来谈谈质量度量和过程改进的一些话题。

什么是 TMMi？

1. 定义：TMMi 即 Test Maturity Model Integration(测试成熟度模型集成)。

2. 来源：由 TMMi 基金会开发的一个非商业化的、独立于组织的测试成熟度评估模型。

3. 目的：推动组织使测试过程从临时的和未管理的状态进化为已管理、已定义、已测量和优化的状态。

4. 标准：TMMi 是与国际标准相一致的、由业务/目标驱动的测试过程改进详细模型，是一个过程改进的阶段型架构。

5. 分级：TMMi 分为 5 个级别，规定了成熟度级别和测试过程改进路径。每个级别都有一组过程域，组织需要实施这些过程域来达到对应的成熟度级别。

6. TMMi1 级—初始

7. TMMi2 级—已管理

8. TMMi3 级—已定义

9. TMMi4 级—已测量

10. TMMi5 级—优化

什么阶段需要 TMMi？

TMMi 是一种测试成熟度评估模型，也是一个测试过程改进的参考阶段性架构。

因此评估是否需要 TMMi 来推动质量度量和过程改进，需要先对企业或团队当前的测试现状进行梳理评估。

结合我参与 TMMi 落地改进的经验和笔记，一般来说当具有如下几个特征的情况下，可以进行 TMMi 落地改进。

1. 软件产品风险无法识别或识别度不高（风险识别）；

2. 测试环境未形成统一规范，管理和维护成本高（环境稳定）；

3. 测试生命周期活动没有明确的定义和裁剪规则（准入准出规则）；

4. 现有测试体系过重或不适配团队，产品交付质量不高（测试体系效率）；

5. 质量度量不清晰，无法很好的评估需求/过程/交付质量（质量度量和改进）；

上述几条现状，是影响我们日常工作顺利开展的元凶，也是大家吐槽测试背锅的原因。

当然，在项目启动阶段，一定要注意如下几个事项：

1. 获得高层支持（确保足够的资源投入）；

2. 设定清晰、可度量、可实现的目标（质量度量和改进本身就是成本）；

3. 成立正式 &专门的改进小组（确保人的投入、权利到位和明确的责任）；

TMMi 如何落地实施？

确定要进行 TMMi 改进后，就可以项目立项进行实施了。一般来说 TMMi 落地可以分为如下几个阶段：

1. 项目立项启动；

2. 组建专门的 TMMi 过程改进团队；

3. 制定 TMMi 过程改进计划并评审通过；

4. 项目实施（参照 TMMi 的分级标准和当前所处阶段）；

5. 项目试点验证（挑选试点项目，小范围接入验证，评估效果）；

6. 根据试点验证结果不断改进评估（不断扩大验证范围，不断评估）；

7. TMMi 正式评估，得到认证（需要专门的外部机构或基金会认证，发放证书）；

在项目落地实施过程中，要注意如下几点：

1. 制定计划要明确不同阶段和里程碑；

2. 每个阶段目标清晰，目标一定要可度量可实现；

3. 需要有专门的人员和流程 &工具来协助监控 &控制改进过程；

4. 流程要清晰，术语要统一且做好宣讲，保证各团队达成共识；

5. 改进过程和进度需要展示出来，并且要收集各团队的有效反馈；

从哪些角度度量质量？

需求设计质量

我们谈软件质量，不可避免要从它的源头说起，而源头就是需求和设计阶段要做的事情。这个阶段包括原型图、PRD 文档、交互设计、技术方案、测试用例等几项重要产出物，当然他们有一定的前后依赖关系。

在需求设计阶段，我个人认为比较重要的有如下几点指标：

1. 需求评审通过率（是否有遗漏、描述不清、存在逻辑漏洞等）；

2. 设计评审通过率（设计是否满足需求要求、是否合理美观友好）；

3. 方案评审通过率（方案实现难易程度、可测性、是否需要更多资源）；

4. 用例评审通过率（场景是否尽可能覆盖、和技术方案实现是否吻合）；

为什么要做大量的评审工作呢？因为在这个阶段做风险评估和控制，是投入产出最高的。

评审的价值在于从用户使用场景角度出发，通过评审提问，把需求逐步澄清并形成验收条件，产、研、测三方共同确认，形成共识，以保证大家对需求的认知不发生偏差，为后续团队正确的做事提供有价值的指导。

研发过程质量

测试的本质是验证研发交付的产出物是否达到需求设计及预期的标准。并不能直接带来质量的提升，只能通过种种手段多维度的去验证是否达标，并通过流程规范、度量标准等去保障最终的交付物达标。

我们常说的各种测试技术手段，都是验证和保障交付质量的手段，而不是构建质量的手段。在研发过程阶段，我个人认为比较重要的有如下几点指标：

1. 提测准时率（便于评估进度、资源投入和风险）；

2. 构建成功率（构建成功率很大程度能反映出研发提测质量。如果经常编译构建失败或自动化测试通过率较低，因为这意味着最基本的需求实现出了问题）；

3. 缺陷收敛率（反映缺陷在研发过程阶段的变化趋势和缺陷修复的时效性问题。一般在测试阶段的中前期即单测 &集成测试阶段会暴露大量缺陷，到系统测试和回归阶段缺陷就应该有明显下降和收敛，降低产品验收和交付风险）；

4. 缺陷 reopen 率（问题修复可能会带来新的问题，reopen 指标可以从一定程度上评估缺陷修复的质量。如果 reopen 率比较高，那么很可能研发侧出现了问题，需要引起重视和寻找原因，尽快解决）；

当然，上述的度量角度有一些基础的前提，比如：开发 &测试环境的稳定性、测试流程和体系是否标准和高效，是否有较好的工具支撑度量过程。

用户使用质量

用户使用质量，指的是软件线上发布后，我们对用户使用过程进行追踪并采集数据进行评估度量的过程。

常见的度量指标有：

1. 线上缺陷逃逸率（线上发现的缺陷）；

2. 线上问题留存率（线上发现的缺陷留存时长，可以用来评估修复的时效和对线上质量的重视程度）；

3. 用户反馈建议量（这里仅针对的是用户针对功能的反馈或者客诉，不包含业务活动的范围）；

最后，所有的质量度量和改进措施，在实际应用实践中应该“量力而为”，因为质量本身就是有成本的。应该在有限的资源条件下提高质量，这也是质量保障和改进应该追求的目标。