管理团队技巧+1：问题驱动的测试过程改进

过程改进

在开始正文之前我们首先来做一次思维推导。我们来尝试回答下面的问题：

反复称重能否帮你减肥？

这个答案显然是：否

测试工作本身并不能直接产出质量，就如使用体重计称重并不能让人减肥一样。

测试可以被看做信息收集和评估过程，但反复评估一件事物，并不能直接改善这件事物。

软件测试可以通过数据的收集，缺陷的汇报，用于促进产品质量的改进，质量风险的规避，然而质量最终的改进还要来自于研发过程本身。

实际上我们认为过程质量决定产品质量。那么改进项目的过程质量，才是推动产品质量提升的根本办法。

在软件行业内，过程改进是许多企业，特别是大型企业非常关注的，我们耳熟能详的CMMi软件成熟度模型，就旨在帮助企业提升自身的组织和过程成熟度。

测试过程改进

CMMI成熟度模型是关注质量的，实际上我们谈过程改进，希望达到的目标应该是成本，效率和质量的三方收益。

除了CMMi这种着眼于研发过程全局改进的模型，专注于测试过程的改进模型也有许多的应用场景。

常用的测试改进模型包括：

◆ TMMi

◆ TPI-Next

◆ CTP

◆ STEP

之所以在过程改进中，我们倾向于使用模型。

实际上是秉承着“借鉴”的思想，直接使用业界先驱们成功经验的总结，与自己的项目进行比对和匹配。

以上这些模型中，有一些模型可能是比较重量型的，类似CMMi，会和企业成熟度认证结合起来，需要外部助推力来帮助达成。

不过也有一些是以小团队甚至个人为出发点也是可以应用的，下面我们就介绍其中的一种：TPI-Next

TPI—Next

TPI模型将测试改进方向划分为三个区域：

◆ 人员

◆ 管理

◆ 技术

在此基础之上，继续将他们划分为16个域，并用“受控级”、“高效级”和“优化级”定义其成熟度。

通过将自身项目特性与TPI-Next16个域的三级成熟度标准进行对比，我们可以很容易得到自身项目测试的改进方向。

问题驱动过程改进

除了使用模型来帮助我们进行过程改进，其实针对特定问题而改进特定过程是更常用的做法。

使用这种方式的改进过程，可能会缺乏系统性和结构性，但是确实最贴近现实，能够最有效带来直观收益的。

当然这种问题驱动式的改进，也同样可以参照过程模型和改进模型，以便于找到改进方向。

我们来看几个例子：

1. 产品整体质量问题

在测试活动中，我们常常会遇上一些窘局，比如某系统的测试，爆出大量（远超预期）缺陷。

我们先来论断一下，测试报出大量缺陷究竟是不是一个问题？

有的人可能会说，这不是问题，测试报出缺陷，这不是天经地义的吗。

实际上我们简单来说，我们对项目缺陷的预期数量实际是存在边界的（CMMi3级标准，测试密度不应超过2.39%），测试的理想状态应该是在边界之内揭示问题。

缺陷数量超出边际值会带来显而易见的风险：

◆ 各方工作量增多

◆ 项目周期被拉长

◆ 缺陷揭示越多，隐藏缺陷也越多（冰山效应）

那么通过过程改进，我们如何解决这一问题呢？

我们可以从TPI模型中找出几个关键域，用于改进这个问题：

保证测试更早的介入，更早期的发现问题，而不是使问题堆积到执行阶段。

很多情况下，超量缺陷的现象所隐射的问题是研发方向的偏差，这些偏差很有可能来自与编码的前序阶段，比如需求和设计。测试更早的介入这些阶段可以缓解类似风险。

这个问题也应从测试组织方面思考。

比如项目的测试过程是否具备足够的层次性？

如果项目只具备系统测试层级，那么延申测试的层级，如单元测试、系统测试是应该被考虑引入以缓解项目缺陷压力。

另一方面，在组织测试的过程中，我们是否考虑到了前序阶段的支持，有无相应的方法和过程进行保证？测试准入标准和冒烟测试是否被用于衡量产品的可测性？

2. 测试时间压力

测试团队经常会面临时间压力，测试时间的争夺是测试团队夹在产品质量和市场压力之间的反复博弈过程。

如何改进这一现象呢？我们同样尝试找出几个改进的关键域：

测试时间的保证很大程度要取决于干系人对于测试的认知和重视，所以我们提取的第一个关键域就与之相关。

测试团队需要与干系人（比如项目经理）达成测试目标和范围的一致，并且基于这个范围投入相应的成本。成熟的测试团队有必要通过沟通、培训、宣讲、协商等方式取得这一成果。

通过更合理的测试组织，提升测试工作效率也是解决时间压力的重要思路。

另一个关键域是估计与计划。任务估计与计划不单单是后续工作实行的指导，也是对预期任务时间取得各方一致的有效手段。

以上是两个问题驱动的过程改进的例子，我们可以举一反三，通过对于相应问题的分析，对应标准的解决办法来逐步实现测试过程的改进。

过程改进流程

最后，过程改进其实是一个非常大的课题，从事过程改进的人员通常具备非常高的团队地位（想要改变一件事情通常都没有那么容易）。

过程改进也必须遵循IDEAL模型：

◆ Initiating 启动

◆ Diagnosing 诊断

◆ Establishing 制定计划

◆ Acting 实施

◆ Learning 学习（经验总结）

最重要的是，取得利益干系人的支持，是过程改进得以推动的必备条件。

---

资源分享

下方这份完整的软件测试视频学习教程已经上传CSDN官方认证的二维码，朋友们如果需要可以自行免费领取 【保证100%免费】