三个方面协助您评估测试进度计划
作者:管理员 发布时间:[ 2010/2/21 13:22:35 ] 推荐标签:
测试进度计划的评估一直很让我们团队头疼。在项目开始前,我们经常无法预估项目,或者说测试的截止日期与资源投入情况,作为团队负责人,我头疼的是不知道我的资源什么时候能释放。
为了具体的说明这个问题,我先简单介绍一下我们团队,或者研发团队的项目组织架构与测试准出标志。
我们的测试团队是职能型团队,经常是多个项目并行,并共享资源,而每个项目的要求都不一样。
我们测试的准出标志是测试阶段评审,即产品经理与项目经理的人为首肯。
我相信,这种现状也是大部门测试团队的现状。
原先的模式是,我们以轮为单位进行评估,并计划投入的资源。这种评估相对简单,但是极不准确,假如一个项目计划评估5轮,当测试4轮之后,谁敢说后1轮能一定过?
测试又是下游,当项目遇上发布日期时,一堆的领导给我打电话,问软件什么时候发布?唉,说实话,我也不知道,而且很没底,我们能决定软件的发布么?
上网下了一堆的测试计划模版,但是体现的更多的却是对测试的分析,对于进度计划,却没有好的模版。
自己想办法吧!
首先考虑的是测试准出标志,或者说测试停止标志。
究竟什么是测试停止的标志?微软定义的是原则,例如3天回归测试未发现严重问题等,而我们公司却是由人(产品经理/项目经理)定义。
这只是表象,真正决定测试停止的是什么?是软件自身的质量!只有当软件达到一定的质量要求时才可能被发布!
软件做的烂,测试人员再尽心,却无法对项目停止产品直接推动力,也无法释放资源。
明确了这一点,准备评估测试进度计划有了基础。
首先定义测试停止的软件质量目标,再将其分阶段分解,测试进度会有一个更合理的计划。
我们团队目前是这么进行测试进度评估的。
首先针对项目做测试分析,明确测试范围以及项目各模块的风险。
其次先测试对项目质量目标的影响(或风险)较大的模块。
当测试主管认为该模块的风险已经降低,对项目质量目标不构成影响的情况下,进行回归测试。
这种方案的优点在于,将项目的质量目标进行了分解,简单而言,可定义为“两阶段测试法”:
第1阶段,尽可能多的发现BUG。包括对项目各模块进行分析,将风险大的模块优先测试。我们在定义此阶段时,不以软件版本为单位,而以时间为单位,希望通过这个阶段尽快推动软件质量提升。
第2阶段,系统回归测试。此阶段的目的在于对软件质量进行度量。
通过此方案的实行,我们团队目前基本上可比较准确的预估软件发布的日期。
相关推荐
更新发布
功能测试和接口测试的区别
2023/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11