软件测试工作量统计新方法-阿里云开发者社区

开发者社区> 数据库> 正文
登录阅读全文

软件测试工作量统计新方法

简介:

软件测试作为软件生命周期中不可或缺的重要环节,正在受到越来越多的重视。然而,在实际项目测试工作中却存在一个突出的问题,就是测试工作量的统计问题。如何统计更科学、更准确,本文作者在实际工作中进行了摸索和尝试。

  虽然,目前测试工作越来越受到企业的重视,已形成规模,参与测试工作的人越来越多,投入也越来越大。但与之不协调的是没有一个配套的、较为合理的工作量统计方法。原有的测试工作量计算方法,一般是把测试人员进入项目的时间与进入项目的人员数量相乘,得到项目测试的工作量。该计算方法由于计算方便,容易操作,深受众多项目的推崇。

  但是,随着测试在项目的重要性的加深,测试工作分工日益细化,测试资源强调有效重用,测试团队协作越来越强,使用这种方法已经不能满足测试工作量计算的需要了:上级领导不了解整个测试团队资源的使用情况;测试团队负责人难于对项目测试任务实际执行过程产生的工作量、成本进行跟踪;项目组在考核绩效时,遗漏了部分测试人员的工作量。

  所以,在项目测试领域急需一种新的工作量统计方法。笔者将这方面的一些实践进行了总结,供读者朋友参考。

  其基本思路如下:首先就任务类型的设置要达成一致;其次从每日的工作量收集开始,将测试任务按照一定的类别进行分类;然后将工作量数据按照不同的需求进行统计,得出不同的统计表;最后对这些统计表的数据进行分析,得出相应的结论。

  设置任务类型

  设置任务类型,是每日工作量数据录入的前提。任务类型需要在整个测试团队内达成一致,这样大家有了相同的标准,得出的数据才具有统计的意义。本文以某公司的项目测试为例进行介绍,其任务类型如表1所示。

  这里提到的测试任务类型,在实践中会根据项目实际需要进行调整。例如,新增“测试工具学习”任务类型等。

  另外,在表1所示的任务类型中,有一项比较灵活的任务类型——沟通。有的团队认为沟通都是有目的、有目标的,是一个为完成具体测试任务所进行的中间活动,所以他们把沟通作为具体测试任务的一部分。也就是说,对于这样的团队,他们没有“沟通”这个任务类型。有的团队则认为将沟通的内容很难划清界限,为避免测试人员填写工作量时发生混淆,所以,将“沟通”作为独立的任务类型。笔者认为这属于任务类型定义问题,测试团队可以根据已经存在的约定俗成进行设置,只要在整个团队内达成一致就可以的。

表1 测试任务类型分类

  记录工作量基础数据

  这项工作由团队成员根据当天的工作任务完成情况进行记录。它是后续工作量统计的基础,所以要保证这项基础数据收集的准确性,切不可应付了事,最好能在当天下班前填写好当天工作量分配情况。

  坚持记录时间需要很强的自我约束能力,所以每天填写工作量记录需要一定的坚持力。在填写工作量记录时,需要为每个任务选择相应的任务类型,填写工作任务持续时间。工作任务持续时间最好不超过4个小时,这是为了避免填写的任务过粗,不利于发现工作过程中的问题。

  及时记录、数据准确,是这个环节工作的原则。本例中某公司使用的工作量记录表格如表2所示。

统计人力占用情况

  这项工作主要统计测试团队所有成员在各个项目中的投入情况,或者说是项目对测试人员的人力占用情况,每周统计一次。通过对人力占用情况进行统计,测试团队负责人可以得到一份人力占用表。这份人力占用表的主要用途的有三个:

  ● 供测试团队负责人和上级领导使用,方便他们了解测试团队对项目的支持情况及项目占用测试资源的情况。

  ● 让上级领导间接了解测试团队的人员饱和度。如果测试团队负责人要申请新增测试资源时,将整个团队的历史人力占用表作为数据证据提供给上级领导,可以增强申请的说服力。

  ● 提供给项目经理参考。避免项目经理在进行项目人员绩效考核时,遗漏了部分测试人员的工作量。

  这项人力占用情况统计工作,笔者建议使用者在每周末进行。统计结束后,测试团队负责人将统计结果作为测试团队工作汇报的一部分提交上级领导。本例中,某公司在某一周测试团队人力占用情况如表2所示。

表2 工作量记录表格

  在本文的例子里,测试团队在项目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月将投入新启动的项目。

  通过及时更新、跟踪这张表的数据,可以对团队内测试人员的工作情况心中有数,并可根据公司业务发展、部门建设、人员发展需要,合理安排团队成员的工作。

表3 测试团队人力占用表

  统计项目测试工作量投入情况

  这项统计工作是在每日工作量统计的基础上整理得到的。每周测试团队成员提交工作汇报时,会将本周的工作量数据整理后一起提交。测试团队负责人定期(每周或半个月)对团队成员提交的数据进行汇总,并整理到项目工作量投入表中。这就解决了在实际测试执行过程中,测试人员无法对测试工作量进行跟踪的问题。

 笔者曾经碰到一个项目,该项目的测试计划只安排了1.5人日的工作量,但是实际上该项目在测试计划上总共投入了9人日的工作量。经过分析,笔者发现是两个原因导致这个问题的发生:一是测试人员在填写每日工作量记录时,部分任务的“任务类型”选错了;二是该项目测试组长在估算测试工作量时,没有考虑到实际测试执行过程中也需要进行测试计划工作,如每次测试执行的计划、实际工作过程中的计划更新工作等。通过这次分析后,该项目的测试工作量没有再发生这么大的偏差了(偏差率=(计划值-实际值)/计划值×100%)。所以说,测试工作量的统计、分析可以帮助使用者发现一些问题,并改进使用者的工作。某公司某一项目的测试团队工作量投入情况如表4所示。

表4 某项目测试工作量统计表

  通过这张统计表格,可以很清楚地了解某个人的工作量投入情况,及具体测试任务使用的工作量情况。

  汇总项目测试数据

  在项目关闭时,测试团队负责人把整个项目测试过程中产生的数据以及项目基础数据进行汇总。测试过程中产生的数据包括:测试工作量、测试投入成本,它的数据来源于表四;项目基础数据包括:项目规模、项目总成本、项目总工作量,这些数据是向项目经理获取的。这里提到的测试成本,是把每个测试人员的人力成本系数和工作量数据相乘得到的。所有相关人可以通过这张统计表了解项目组中测试占开发总工作量的比例,以及项目组用在测试上的开销情况。这项工作是测试团队资产沉淀的很重要的一项工作。主要用途是:从项目角度对项目测试整体情况进行分析;把测试团队所承接测试的项目进行纵向对比,总结共性,发现问题。

  例如,可以对这些项目的测试数据进行分析,得出测试工作量估算公式。再如,笔者曾经通过数据的对比,发现测试文档编写工作量占整个测试工作量的比例较大。通过进一步分析,发现测试用例的维护占用了测试设计很大一部分的工作量,从而应考虑在团队内改进测试用例管理方法。某公司两个项目的测试数据如表5所示。

表5 某测试团队测试项目资产库——测试数据

 参考项目背景,笔者对几个项目的测试数据进行分析后,得到了项目测试总人力成本的估算公式:测试总人力成本=20%×项目总人力成本。

  另外,通过把几个项目的各项测试类型所花费的工作量进行对比分析后,笔者得出各项测试任务的工作量相对于测试总工作量的分配比例。对于后续的项目,项目测试组长可以参考这个分配比例进行测试工作量的估算。

  当然,上面介绍的估算公式和工作量比例,只是适用于笔者所在的测试团队。不同测试团队、项目组、公司组织情况都不一样,这里介绍这个例子,目的只是说明测试工作量统计的一个用途。

表6 某测试团队各项测试任务的工作量比例

  总结

  测试工作量的统计,是整个测试团队管理的基础。测试团队的管理、决策、策划等需要数据的支持,即用数据说话,所以,数据的收集、统计是很重要的。有了这些数据之后,我们就可以将它应用到绩效考核和项目成本核算上。

  在本文中,笔者主要介绍的是测试团队的工作量统计,但实际上这些方法不仅适用于测试团队,也适用于个人、项目团队或者整个公司组织。实施时只需要调整“任务类型”等与测试有关的属性,并做一定的扩展即可。

  本文使用的表格,都是在Excel中建立和维护的。在团队规模不是很大时,或者处于试用初期时,使用很方便、实施成本也低。但是如果团队规模较大,团队成员比较多,数据量较大的话,这种手工方式就显得有些力不从心了。读者可以自行开发一个工作量管理系统,使用数据库的方式来记录、分析这些数据。在使用初期可先实现每日工作量数据的录入,以及针对个人、项目、任务类型等属性的统计分析功能即可。









====================================分割线================================



最新内容请见作者的GitHub页:http://qaseven.github.io/

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享: