问题驱动的测试过程改进

本贴最后更新于 1539 天前,其中的信息可能已经事过景迁

过程改进

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

反复称重能否帮你减肥?

这个答案显然是:

测试工作本身并不能直接产出质量,就如使用体重计称重并不能让人减肥一样。测试可以被看做信息收集和评估过程,但反复评估一件事物,并不能直接改善这件事物。

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

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

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

测试过程改进

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

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

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

之所以在过程改进中,我们倾向于使用模型。实际上是秉承着“借鉴”的思想,直接使用业界先驱们成功经验的总结,与自己的项目进行比对和匹配。

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

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

TPI-Next测试改进模型

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

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

image.png

image.png

image.png

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

问题驱动过程改进

除了使用模型来帮助我们进行过程改进,其实针对特定问题而改进特定过程是更常用的做法。使用这种方式的改进过程,可能会缺乏系统性和结构性,但是确实最贴近现实,能够最有效带来直观收益的。

当然这种问题驱动式的改进,也同样可以参照过程模型和改进模型,以便于找到改进方向。我们来看几个例子:

1. 产品整体质量问题

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

我们先来论断一下,测试报出大量缺陷究竟是不是一个问题?有的人可能会说,这不是问题,测试报出缺陷,这不是天经地义的吗。

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

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

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

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

image.png

image.png

2. 测试时间压力

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

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

image.png

image.png

image.png

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

过程改进流程

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

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

image.png

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

1 回帖
请输入回帖内容 ...