这项统计工作是基于每日工作量统计的基础上整理得到的。每周测试团队成员提交工作汇报时,会将本周的工作量数据整理后一起提交。测试团队负责人定期(每周或半个月)对团队成员提交的数据进行汇总,并整理到项目工作量投入表中。这就解决了在实际测试执行过程中,测试人员无法对测试工作量进行跟踪的问题。
笔者曾经碰到一个项目,该项目的测试计划只安排了1.5人日的工作量,但是实际上该项目在测试计划上总共投入了9人日的工作量。这么悬殊的差距,是由于什么原因导致的?经过分析,笔者发现是两个原因导致这个问题的发生:一是测试人员在填写每日工作量记录时,部分任务的 “任务类型”选错了;二是该项目测试组长在估算测试工作量时,没有考虑到实际测试执行过程中也需要进行测试计划工作,如每次测试执行的计划、实际工作过程中的计划更新工作等。通过这次分析后,该项目的测试工作量没有再发生偏差率类似-500%这么大的偏差了(偏差率=(计划值-实际值)/计划值*100%)。所以说,测试工作量的统计、分析可以帮助使用者发现一些问题,并改进使用者的工作。
某公司某一项目的测试团队工作量投入情况如下:
任务类型 | 工作量(单位:人时) | ||||
A | B | C | D | 小计 | |
了解系统需求 | 24.1 | 34 | 33.5 | 23 | 114.6 |
测试计划 | 70 | 8.5 | 138.5 |
| 217 |
测试需求 | 36 | 225.7 | 14.5 | 26.1 | 302.3 |
测试设计 | 30 | 124.5 | 16 | 23.1 | 193.6 |
测试脚本 |
| 193.7 |
| 118.7 | 193.7 |
测试执行 | 78.8 | 644.5 | 284.5 | 160.8 | 1168.6 |
测试报告 |
| 3.5 | 20 |
| 23.5 |
沟通 | 5 | 11.1 | 96 | 7.8 | 116.7 |
会议 | 4 |
| 35 |
| 39 |
| 11.1 | 14.5 |
| 25.6 | |
测试环境搭建 |
| 3.5 |
|
| 3.5 |
缺陷处理 |
| 4.5 |
|
| 4.5 |
性能测试准备 |
|
| 19 |
| 19 |
测试工具学习 |
| 32.5 | 37 | 9.9 | 69.5 |
性能测试计划 | 4.4 |
| 13 |
| 17.4 |
性能测试用例 |
|
| 1 |
| 1 |
性能测试脚本 |
| 1 | 19 | 11.1 | 20 |
性能测试执行 |
|
| 0.8 | 2 | 0.8 |
性能测试总结 |
|
|
|
| 0 |
| 19.5 | 6 | 2.5 | 21.5 | |
合计 | 252.3 | 1317.6 | 748.3 | 385 | 2551.2 |
表四 某项目测试工作量统计表
通过这张统计表格,读者可以很清楚的了解某个人的工作量投入情况,及具体测试任务使用的工作量情况。
5. 汇总项目测试数据,升级测试资产库
在项目关闭时,测试团队负责人把整个项目测试过程中产生的数据以及项目基础数据进行汇总。测试过程中产生的数据包括:测试工作量、测试投入成本,它的数据来源于表四;项目基础数据包括:项目规模、项目总成本、项目总工作量,这些数据是向项目经理获取的。这里提到的测试成本,是把每个测试人员的人力成本系数和工作量数据相乘得到的。所有相关人可以通过这张统计表了解项目组中测试占开发总工作量的比例,以及项目组用在测试上的开销情况。
这项工作是测试团队资产沉淀的很重要的一项工作。主要用途是:
1) 从项目角度对项目测试整体情况进行分析;
2) 把测试团队所承接测试的项目进行纵向对比,总结共性,发现问题。
例如,笔者可以对这些项目的测试数据进行分析,得出测试工作量估算公式。再如,笔者曾经通过数据的对比,发现测试文档编写工作量占整个测试工作量的比例较大。通过进一步分析,发现测试用例的维护占用了测试设计很大一部分的工作量,从而笔者考虑在团队内改进测试用例管理方法。