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

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

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

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

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

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

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

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

自己想办法吧!

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

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

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

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

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

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

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

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

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

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

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

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

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

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