精彩专题 |
如何做好项目沟通计划
软件项目质量管理
国际工程索赔与反索赔
|
更多:
|
|
联系社区管理员 |
咨询电话 010-82273401/11
斑竹申请 admin@mypm.net
版权所有 © 2003-2004
京ICP证070584号
BBS业务许可2007第353号
最佳显示模式:1024*768像素
|
|
|
各位,测试人员的绩效考核都是如何做的 [发表于 2004/11/9] 状态 开放帖 浏览量 2993 |
|
按项目组划分或按部门划分,请大家都来谈谈测试人员的绩效考核管理.
|
>>> 由论坛统一发布的广告:
|
|
楼主
windy
职务 无
军衔 无军衔
来自 广东
发帖 5篇
注册 2004/8/11
PM币 111
经验
|
|
Re:各位,测试人员的绩效考核都是如何做的
[回复于 2004/11/9]
|
问题数是主要指标
|
|
|
1楼
steven_cn
职务 无
军衔 中士
来自 广东
发帖 217篇
注册 2003/3/1
PM币 421
经验
|
|
Re:各位,测试人员的绩效考核都是如何做的
[回复于 2004/11/9]
|
测试用例质量(覆盖、可行性)
|
|
|
2楼
steven_cn
职务 无
军衔 中士
来自 广东
发帖 217篇
注册 2003/3/1
PM币 421
经验
|
|
Re:各位,测试人员的绩效考核都是如何做的
[steven_cn 修改于 2004/11/26]
|
测试人员的绩效评定方法 老鹰 2002-11-1 12:9:3 测试绩效的评定不能以测试中发现的bug的条数为依据,况且如果按bug的错误发放奖金,也不太好, 实际上如一些然所说的应该以 1.测试完毕进行评审为界限,这是一个标准(阶段工作是:把缺陷降到最低限度) 2.软件实施的验收测试,用户的反馈信息是一个标准(毕竟测试还在进行,β测试),这里可以衡 量我们的α测试的质量问题,主要是功能点实现的问题 我认为这两个标准来衡量一个测试员的工作,是可以的 lpp56 2002-11-1 17:19:15 下面是我制定的测试人员的绩效评定的方法,请大家帮忙看一下多提意见 从项目中个人的角度来说包括工作效率的衡量指标、工作质量的衡量指标等] 可以考虑将整个测试工作分为三个阶段, 第一阶段:测试准备阶段 本阶段设计的测试产品为 1、 测试计划 2、 测试规范 3、 测试需求 4、 测试用例 第二阶段:测试执行阶段 1、 测试执行记录标 2、 周测试总结报告 3、 缺陷报告 第三阶段:测试总结阶段 1、 缺陷统计报告 2、 测试评估摘要 3、 测试总结报告 对于三个不同的阶段工作效率的结算方法也不同 第一阶段:测试准备阶段 在本阶段可以用来处理工作效率的指标为 1、 文档方面的 Ø 文档编写效率:此指标值为所制定的文档的页数除以有效时间获得的(这里的有效时间是 之从开始制定文档起,到文档发布的过程中以工作日*8所获得的小时数。页数试是指文档的总页数。 )(注:此计算指标适合于测试计划,测试规范。测试需求的计算) 2、 用例方面: Ø 用例创建效率:此指标计算的方法是按测试用例制定完成后用例的个数称以创建用例所 花费的时间除以以有效的工作时间称获得的(这里的有效时间是之从开始制定文档起,到文档发布 的过程中以工作日*8所获得的小时数。创建用例花费时间:包括用例的描述,与录制脚本的相应工 作的时间) 在本阶段可以用来处理工作质量的指标为: 1、 文档方面 Ø 文档编写质量:此指标为在文档评审时每页发现的bug数除以总的文档页数。 2、 用例方面: 用例创建质量:用于本部分用例的数量可能较多,可以采用定期抽查一定数量的用例,然后根据被 抽查用例的bug数除以被抽查的缺陷数,两衡量一段时间内的测试的工作质量。在该部分结束时可 以将几次的工作量指标求平均值,给出一个总体的指标。(主要针对的是用例文档) 第二阶段: 测试执行阶段 考虑到本阶段的测试执行记录,缺陷报告都预测试用例有关,所以在此除的队以执行记录与缺陷报 告的指标都通过用例的执行效率。而周测试总结报告,由于内容比固定所以可以规定一个统一的时 间。(比如4小时,或者0.5个工作日) 在本阶段可以用来处理工作效率的指标为: 1、 用例执行效率:由各用例的执行时间乘以用例个数加上薪创建的肩测试用例的个数称以创建用 例所用的时间除以用小工作时间计算而获得的(这里的有效时间是从开始制定文档起,到文档发布 的过程中以工作日*8所获得的小时数。执行用例花费时间:包括用例的执行时间,用例的执行情况 的记录时间,缺陷的记录时间决定。)(注:考虑到用例每次执行的很可能不同,所以可以选择把 由各“用例的执行时间乘以用例个数” 改为“每一个测试用例,各次执行所用的时间之和“) 本阶段可以用来处理工作质量的指标为: 用例执行质量:用例创建质量:用于本部分用例的数量可能较多,可以采用定期抽查一定数量的用 例,然后根据被抽查用例的bug数除以被抽查的缺陷数,来衡量一段时间内的测试的工作质量。在 该部分结束时可以将几次的工作量指标求平均值,给出一个总体的指标。(主要针对用例的执行过 程) 第三阶段:测试总结阶段 考虑到本阶段的所有工作产品都是文档所以采用文档编写效率作为作为工作效率指标 1、 文档编写效率:此指标值为所制定的文档的页数除以有效时间获得的(这里的有效时间是之从开 始制定文档起,到文档发布的过程中以工作日*8所获得的小时数。页数试是指文档的总页数。) 在本阶段可以用来处理工作质量的指标为: 3、 文档方面 Ø 文档编写质量:此指标为在文档评审时每页发现的bug数除以总的文档页数。 firingfox 2002-11-4 13:46:37 好复杂呀。我以前的经理也用文档页数作考评,我觉得不是特合适。我自己写文档,有时候还包含 一些方案,这些单单从页数上说不是很合适,还有有时候可以看到别人写的文档里面全是copy大段 无用的内容,其实如果文档里面都是自己的内容有时候很少的东西也都是精华。所以界定比较麻烦。 我在设计测试用例时曾经把用例执行时间做一个统计数字,但是现在好像还不能做考核,因为我们 现在的软件产品质量很差,拿过来,我预计30分钟完成的用例竟然需要一上午,因为bug太多,无 法走下去,或者定位bug很费时间,这个和开发软件的人有关,有时测试人员忙于去和开发人员一 起找bug,又忽视了继续测试其他可以测试的部分,还耽误测试时间,这又属于测试人员的问题, 等等,似乎统计不好。我问过微软的一个部门经理,他说我这么统计肯定不对,可是也没告诉我别 的办法,可气。 我觉的现在考核可能还是一种经理个人的判断吧 lpp56 2002-11-4 18:49:41 firingfox 谢谢你的回复 根据你的建议我做了下面的调整说明 1、在文档中加入对于参与评定绩效的文档的评审级别的限制,规定凡是参与评定绩效的文档都必 须至少进行项目内的评审。 2、对于所有的测试文档都建立模版,在模版中对于可能出现无用部分(如引言,范围等部分的内 容与字数作相应的限制) 3、在项目的评定指标中加入上级评定这一主观因素与为改近前的客观一素指标进行加权求和(上 绩评定的因素主要张整个评定因素的指标为20%) 4、加入在计算用例执行执行下率时,要求对于执行过程中对于特别费时用例的问题的报告机制( 在周工作报告中)
|
|
|
3楼
steven_cn
职务 无
军衔 中士
来自 广东
发帖 217篇
注册 2003/3/1
PM币 421
经验
|
|
|