摘要:针对在实际项目
测试工作中的一个突出问题,即测试工作量的统计问题,笔者在实际工作中进行摸索和尝试。本文是对笔者测试工作量统计实践的总结。
关键词:测试 工作量 统计 计算
工作量的统计,从小方面来说,对于个人工作总结、工作方法改进、个人能力的提高很有帮助;从大方面来说,会影响一个组织的策略,如测试团队、项目组、公司组织。假设过了一个月后,你无法清楚的说出自己这个月的主要工作是什么,每项工作任务的投入是多少,那么你就很难发现自己的工作方法是否存在不足,并进行改进。对于一个组织来说,他需要知道目前的人力配置是否合理,是否有富余人力,现有分工是否最佳。所以,他也需要对组织的人力使用情况进行统计并进行分析,为后续决策提供参考。
一、问题的提出
1.目前测试工作越来越受到公司的重视,已形成规模,参与测试工作的人越来越多,投入也越来越大。与之不协调的是没有一个配套的、较为合理的工作量统计方法。
2.原有的测试工作量计算方法,一般是把测试人员进入项目的时间与进入项目的人员数量相乘,得到项目测试的工作量。该计算方法由于计算方便,容易操作,深受众多项目的推崇。但是,随着测试在项目的重要性的加深,测试工作分工日益细化,测试资源强调有效重用,测试团队协作越来越强,使用这种方法已经不能满足测试工作量计算的需要了。
3.上级领导不了解整个测试团队资源的使用情况。
4.测试团队负责人难于对项目测试任务实际执行过程产生的工作量、成本进行跟踪。
5.项目组在考核绩效时,遗漏了部分测试人员的工作量。
二、基本思路
首先就任务类型的设置达成一致;其次从每日的工作量收集开始,将测试任务按照一定的类别进行分类;然后将工作量数据按照不同的需求进行统计,得出不同的统计表;最后对这些统计表的数据进行分析,得出需要的结论。
三、工作量数据采集、统计及分析
1.设置任务类型
设置任务类型,是每日工作量数据录入的前提。任务类型需要在整个测试团队内达成一致,这样大家有了相同的标准,得出的数据才具有统计的意义。
某公司的项目测试任务类型如下:
任务类型 | 适用范围 |
测试计划 | • 编写项目总测试计划 • 编写里程碑测试计划 • 编写每一轮测试的测试计划 |
测试需求 | • 了解系统需求 • 编写/修改测试需求 |
测试设计 | • 了解系统设计 • 编写/修改测试用例 • 测试数据准备 |
测试执行 | • 编写/修改/录制测试脚本 • 测试执行 • 编写测试执行结果及缺陷登记 |
测试报告 | • 编写项目里程碑测试报告 • 测试执行情况分析 • 编写项目各轮测试的测试报告 |
测试管理 | • 测试组阶段工作安排 • 测试组内、外协调 • 测试组人员管理(如人员思想波动等) |
测试环境准备 | • 获取测试环境要求 • 测试环境搭建 |
缺陷处理 | • 缺陷修改、缺陷验证等与缺陷处理有关的工作(缺陷登记不包括在内) |
沟通 | • 所有项目组内部或项目组外部的沟通 |
会议 | • 项目组内/外会议 • 项目组内/外培训 |
其他 | • 所有无法归类的任务 |
表一 测试任务类型分类
上面提到的测试任务类型,在实践中会根据项目实际需要进行调整。例如,新增“测试工具学习”任务类型等。
另外,在上述的任务类型中,有一项比较灵活的任务类型——沟通。有的团队认为沟通都是有目的、有目标的,是一个为完成具体测试任务所进行的中间活动,所以他们把沟通作为具体测试任务的一部分。也就是说,对于这样的团队,他们没有“沟通”这个任务类型。有的团队则认为将沟通的内容很难划清界限,为避免测试人员填写工作量时发生混淆,所以,将“沟通”作为独立的任务类型。笔者认为这属于任务类型定义问题,测试团队可以根据将已经存在的约定俗成进行设置,只要在整个团队内达成一致就可以的。
2.记录工作量基础数据
这项工作由团队成员根据当天的工作任务完成情况进行记录。它是后续工作量统计的基础,所以要保证这项基础数据收集的准确性,切不可应付了事,最好能在当天下班前填写好当天工作量分配情况。
坚持记录时间需要很强的自我约束能力(Watts S.Humphrey 2001),所以每天填写工作量记录需要一定的坚持力。在填写工作量记录时,需要为每个任务选择相应的任务类型,填写工作任务持续时间。工作任务持续时间最好最长不超过4小时,这是为了避免填写的任务过粗,不利于发现工作过程中的问题。
及时记录、数据准确,是这个环节工作的原则。
某公司使用的工作量记录表格如下:
用户 | 工作日期 | 项目 | 过程类 | 任务类型 | 持续时间 | 任务说明 |
| | | 管理 | | | |
| | | 测试 | | | |
| | | 需求 | | | |
| | | 开发 | | | |
| | | …… | | | |
表二 工作量记录表格
3.统计本周团队的人力占用情况
这项工作主要统计测试团队所有成员在各个项目中的投入情况,或者说是项目对测试人员的人力占用情况,每周统计一次。通过对人力占用情况进行统计,测试团队负责人可以得到一份人力占用表。这份人力占用表的主要用途的有三个:
1)供测试团队负责人和上级领导使用,方便他们了解测试团队对项目的支持情况及项目占用测试资源的情况。
2)让上级领导间接了解测试团队的人员饱和度。如果测试团队负责人要申请新增测试资源时,将整个团队的历史人力占用表作为数据证据提供给上级领导,可以增强申请的说服力
3)提供给项目经理参考。避免项目经理在进行项目人员绩效考核时,遗漏了部分测试人员的工作量。
人力占用表,主要包括人员姓名、人员进入项目的名称、人员在项目的占用/投入情况、人员计划退出项目的时间、各项任务对应的部门目标等。
这项人力占用情况统计工作,笔者建议使用者在每周末进行。统计结束后,测试团队负责人将统计结果作为测试团队工作汇报的一部分提交上级领导。
某公司某一周测试团队人力占用情况如下:
姓名 | 项目 | 部门目标 | 备注 |
项目名称 | 占用情况 | 计划何时退出 |
A | 过程改进 | 50% | | 2005.1完成测试指南所有子文件的编写;性能测试过程初稿 | |
B | 项目1 | 100% | 未知 | | 因为项目1测试组不知道项目进度及下阶段工作安排,故不知道何时能退出 |
C | 项目1 | 100% | 未知 | |
D | 项目1 | 80% | 2005.2 | |
项目2 | 20% | 2005.2 | | |
E | 项目3 | 100% | 2005.2 | | 其中,有60%以上在做项目管理、需求跟踪等工作 |
F | 项目4 | 60% | 2005.3 | | 其中,30%在项目4需求负责上。 |
项目5 | 40% | 2005.1 | | F利用业余时间研究单元测试,暂无目标 |
表三 测试团队人力占用表
在上面的例子里,测试团队在项目1一共投入了B、C、D三个人,B、C成员是100%资源投入。因为项目后续工作安排未知,而B、C成员又属于项目1核心测试人员,因此这两名成员的退出时间未知。另外一个测试成员D因为不属于项目1的核心测试成员,所以他参与2个项目。同时因为项目2规模较小,所以成员D在项目2中投入20%的资源,在项目1中投入80%的资源。考虑到公司在2005年3月将要启动一个新项目,所以,笔者经过和项目1的项目经理协商后达成一致,计划成员D在2005年2月退出该项目,这样他在2005.3月将投入新启动的项目。
通过及时更新、跟踪这张表的数据,笔者对团队内测试人员的工作情况心中有数,并可根据公司业务发展、部门建设、人员发展需要,合理安排团队成员的工作。
4.统计项目测试工作量投入情况
这项统计工作是基于每日工作量统计的基础上整理得到的。每周测试团队成员提交工作汇报时,会将本周的工作量数据整理后一起提交。测试团队负责人定期(每周或半个月)对团队成员提交的数据进行汇总,并整理到项目工作量投入表中。这就解决了在实际测试执行过程中,测试人员无法对测试工作量进行跟踪的问题。
笔者曾经碰到一个项目,该项目的测试计划只安排了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) 把测试团队所承接测试的项目进行纵向对比,总结共性,发现问题。
例如,笔者可以对这些项目的测试数据进行分析,得出测试工作量估算公式。再如,笔者曾经通过数据的对比,发现测试文档编写工作量占整个测试工作量的比例较大。通过进一步分析,发现测试用例的维护占用了测试设计很大一部分的工作量,从而笔者考虑在团队内改进测试用例管理方法。
某公司两个项目的测试数据如下:
项目 | 项目1 | 项目2 |
软件部分金额(万元) | 108 | 102.5 |
项目规模(Use Case数量) | 114个237页 | 71个113页 |
项目总人力成本(千元) | 551.76601 | 215.21294 |
测试总人力成本(千元) | 94.15967 | 75.21224 |
总工作量(人月) | 49.06 | 27.57 |
开发总工作量(人月) | 18.42 | 19.52 |
测试总工作量(人月) | 8.644 | 3.1 |
测试占总工作量比例 | 17.62% | 11.24% |
测试占开发总工作量比例 | 46.93% | 15.88% |
测试占总人力成本比例 | 17.07% | 34.95% |
测试文档编写 | 工作量(人月) | 3.33 | 1.08 |
占测试总工作量比例 | 38.51% | 34.95% |
各项测试任务在整个测试过程中所占的比例 | 测试计划 | 3.87% | 3.51% |
测试需求 | 6.79% | 8.44% |
测试设计 | 14.06% | 16.31% |
测试执行 | 35.45% | 41.95% |
测试报告 | 2.59% | 6.69% |
测试管理 | 6.74% | 4.91% |
沟通、会议 | 4.74% | 1.18% |
测试环境搭建 | 1.61% | 0 |
性能测试 | 14.29% | 8.19% |
验收测试 | 5.21% | 0 |
表五 某测试团队测试项目资产库——测试数据
参考项目背景,笔者对几个项目的测试数据进行分析后,得到了项目测试总人力成本的估算公式:
测试总人力成本=20%×项目总人力成本
另外,通过把几个项目的各项测试类型所花费的工作量进行对比分析后,笔者得出各项测试任务的工作量相对于测试总工作量的分配比例。对于后续的项目,项目测试组长可以参考这个分配比例进行测试工作量的估算。
测试任务 | 比例 |
熟悉系统需求 | 5.0% |
测试计划 | 3.5% |
测试需求 | 7.5% |
测试用例 | 15.0% |
测试执行 | 39%-41% |
测试报告 | 4.0% |
测试管理 | 6.8% |
沟通、会议 | 4.0% |
测试环境搭建 | 2%-2.5% |
性能测试 | 9.0% |
验收测试 | 4.0% |
表六 某测试团队各项测试任务的工作量比例
当然了,上面的介绍的估算公式和工作量比例,只是适用于笔者所在的测试团队。不同测试团队、项目组、公司组织情况都不一样,这里介绍这个例子,目的只是说明测试工作量统计的一个用途。
四、小结
测试工作量的统计,是整个测试团队管理的基础。测试团队的管理、决策、策划等需要数据的支持,即用数据说话,所以,数据的收集、统计是很重要的。在本文中笔者主要介绍的是测试团队的工作量统计,但实际上这些方法不仅适用于测试团队,也适用于个人、项目团队或者整个公司组织。实施时只需要调整“任务类型”等与测试有关的属性,并做一定的扩展即可。
本文使用的表格,笔者都是在excel中建立和维护的。在团队规模不是很大时,或者处于试用初期时,使用很方便、实施成本也低。但是如果团队规模较大,团队成员比较多,数据量较大的话,这种手工方式就显得有些力不从心了。读者可以自行开发一个工作量管理系统,使用数据库的方式来记录、分析这些数据。在使用初期可先实现每日工作量数据的录入,以及针对个人、项目、任务类型等属性的统计分析功能即可。