日常工作中,我们总是需要对未来的任务,进行工作量的评估,这也是项目启动最重要的先决条件,目前这部分主要是基于WBS估算法来进行的,今天跟大家分享一下自己的相关思路以及具体的流程。
第一步:确定测试方案
评估工作量,首选需要确定做哪些工作,因此确定测试方案是评估工作量的前提条件。测试方案中常见的工作内容如下:新功能测试、老功能回归测试、适配测试(兼容性测试)、二轮测试、冒烟测试
第二步:根据测试方案分别评估工作量
在确定测试方案之后,再根据具体工作内容评估对应的工作量。
新功能测试
1、首先。对需求进行功能模块的拆分。
基本思路:
- 可依据产品或交互文档中的模块进行拆分(此时还为进入开发阶段,因此还无法参考开发实现)。
- 进行功能模块拆分时,粒度尽量拆的细一些,从模块到子功能,甚至可以拆到小的功能点。粒度越细,预估工作量的精度越高。
2、其次,根据拆分结果,逐一评估工作量。
基本思路:
- 根据以往的测试经历,类似的功能点,之前的工作量可以直接复用。
例如:以前测试过登录的功能,本次需求中的登录功能与之前测试过的大体相同,那么可以直接沿用之间测试时的实际工作量。
又如:测试过文本编辑的相关内容,本次需求中有类似的需求,那么可以直接沿用之前测试时的实际工作量。
- 根据细化后的功能,通过产品针对该功能的描述或交互中的内容,预估case的量级,然后根据case数量与工作量的对比经验值,预估工作量。比如1小时产出50条case。
- 根据产品或交互文档中描述的内容多少,评估工作量。理论上需求描述的内容越多,case量越多。
- 需要充分考虑隐性需求(即产品在需求文档中没有直接体现的内容),视情况增加预估的工作量。
比如:登录功能,产品需求中针对登录成功、账户名密码错误、网络失败的情况,均给出了相应的提示,但针对隐藏的各种登录错误类型的提示,并没有明确的需求描述。
3、然后,需要从用例设计和用例执行两个方面进行评估。一般情况下:
- 用例设计的时间与用例执行的时间,接近1:1。
- 偏界面功能的用例设计时间,可能略大于执行时间。因为偏界面的case执行操作比较快。
- 操作复杂的功能,用例设计时间会小于执行时间。
例如:执行case时涉及到:配置环境、操作数据库、设置前置条件等等
4、最后,预估可能影响工作量的风险,视实际情况调整工作量的预估。包含但不限于以下内容:
- 相关需求的测试,是否需要配置环境,比如搭建测试服务器。
- 相关需求的测试,是否涉及特定的测试工具或操作方法,是否存在学习的成本。
- 相关需求中,是否存在大量不确定的预期结果(需要视开发实现情况而定),这种情况较多的话,后期需要大量的沟通和确认的工作,因此需要增加相关的工作量。
- 需求的稳定性,如果需求的稳定性较差(后续存在需变的风险),可以提前评估风险,预留出相关的工作量。
老功能回归测试
1、首先,确定需要回归的老功能模块都有哪些。
2、然后,确定每个功能需要回归的粒度:
- 执行全部用例
- 执行checklist
- 执行冒烟case。
3、最后根据以往执行对应任务的工作量,对应预估本次的工作量。
注意:有的时候在开发介入前,很难给出相应的影响范围,那么也没办法准确评估老功能回归测试的范围,因此这种情况下,这部分的预估工作量,可以作为风险与产品沟通备忘。
适配(兼容性)测试
1、首先,确定需要关注适配(兼容性)的功能点有哪些。比如主流程、UI层面等。
2、然后,评估这部分内容的大致工作量,预估单个环境下执行的工作量。
- 具体的评估方法:可参考新功能测试时,通过预估测试用例数量来评估工作量的思路。
3、最后,再根据确定的适配(兼容性)范围列表中的数量,乘以单个环境下执行的工作量,计算出总的工作量。
- 如果适配(兼容性)范围列表的数量较多,考虑到实际操作中熟练程度的提升,可以一定程度的缩减工作量。
二轮测试
1、确定每个模块的回归粒度:checklist或冒烟case。
2、这部分一般都有固定的工作量,根据以往的经验值,来计算二轮测试的预估时间。
注意:有的时候在开发介入前,很难给出响应的影响范围,那么也没办法准确评估老功能回归测试的范围,因此这种情况下,这部分的预估工作量,可以作为风险与产品沟通备忘。
冒烟测试
思路同“二轮测试”
此外,关于工作量评估结果的审核
注意事项:
1、工作量评估结果的审核,需要由经验更为丰富的工作人员来进行,具体的审核方式,与评估工作量的过程类似。
2、工作量评估结果的审核,应当采用团队内部人员的平均值作为衡量标准。
3、工作量评估结果的审核,可以借鉴开发同学评估的工作量,测试的预估工作量不会大于开发的预估工作量,如果超过开发工作量,那肯定存在问题。