测试管理：问题驱动的测试过程改进

965 0 0

作者:Vincent

过程改进

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

反复称重能否帮你减肥？

这个答案显然是:否

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

这个问题也应从测试组织方面思考。比如项目的测试过程是否具备足够的层次性？如果项目只具备系统测试层级，那么延申测试的层级，如单元测试、系统测试是应该被考虑引入以缓解项目缺陷压力。
另一方面，在组织测试的过程中，我们是否考虑到了前序阶段的支持，有无相应的方法和过程进行保证？测试准入标准和冒烟测试是否被用于衡量产品的可测性？