如何评估测试进度计划？

woodcraft

测试进度计划的评估一直很让我们团队头疼。在项目开始前，我们经常无法预估项目，或者说测试的截止日期与资源投入情况，作为团队负责人，我最头疼的是不知道我的资源什么时候能释放。

为了具体的说明这个问题，我先简单介绍一下我们团队，或者研发团队的项目组织架构与测试准出标志。

我们的测试团队是职能型团队，经常是多个项目并行，并共享资源，而每个项目的要求都不一样。

我们测试的准出标志是测试阶段评审，即产品经理与项目经理的人为首肯。

我相信，这种现状也是大部门测试团队的现状。

原先的模式是，我们以轮为单位进行评估，并计划投入的资源。这种评估相对简单，但是极不准确，假如一个项目计划评估5轮，当测试4轮之后，谁敢说最后1轮就能一定过？

测试又是下游，当项目遇上发布日期时，一堆的领导给我打电话，问软件什么时候发布？唉，说实话，我也不知道，而且很没底，我们能决定软件的发布么？

上网下了一堆的测试计划模版，但是体现的更多的却是对测试的分析，对于进度计划，却没有好的模版。

自己想办法吧！

首先考虑的是测试准出标志，或者说测试停止标志。

究竟什么是测试停止的标志？微软定义的是原则，例如3天回归测试未发现严重问题等，而我们公司却是由人（产品经理/项目经理）定义。

这只是表象，真正决定测试停止的是什么？是软件自身的质量！只有当软件达到一定的质量要求时才可能被发布！

软件做的烂，测试人员再尽心，却无法对项目停止产品直接推动力，也无法释放资源。

明确了这一点，准备评估测试进度计划就有了基础。

首先定义测试停止的软件质量目标，再将其分阶段分解，测试进度就会有一个更合理的计划。

我们团队目前是这么进行测试进度评估的。

首先针对项目做测试分析，明确测试范围以及项目各模块的风险。

其次先测试对项目质量目标的影响（或风险）较大的模块。

当测试主管认为该模块的风险已经降低，对项目质量目标不构成影响的情况下，进行回归测试。

这种方案的优点在于，将项目的质量目标进行了分解，简单而言，可定义为“两阶段测试法”：

第1阶段，尽可能多的发现BUG。包括对项目各模块进行分析，将风险最大的模块优先测试。我们在定义此阶段时，不以软件版本为单位，而以时间为单位，希望通过这个阶段尽快推动软件质量提升。

第2阶段，系统回归测试。此阶段的目的在于对软件质量进行度量。

通过此方案的实行，我们团队目前基本上可比较准确的预估软件发布的日期。

woza

在敏捷实践中，几乎完全没有这类困扰。

做计划的时候，不需要考虑什么时候能够发布。而是考虑在需要的发布的时候，能够完成多少功能。由于发布周期很短。每个发布周期中，可以选择少做功能，但是必须保证足够的测试。因此每个发布的质量都有保障。对于客户来说，无非是今天拿一个功能少的软件，还是下周拿一个功能多的软件。由于最重要的功能总是最先完成。因此软件可以帮助客户在最短的时间内，实现最多的商业价值。