51Testing软件测试论坛

标题: 如何有效的对测试人员进行业绩考核？(08-04-11)（获奖名单已公布） [打印本页]

作者: 51testing 时间: 2008-4-11 17:31
标题: 如何有效的对测试人员进行业绩考核？(08-04-11)（获奖名单已公布）
随着企业对软件测试的不断重视，测试团队的规模也越来越大，测试相关的岗位也在逐渐增多，测试工程师、测试leader、高级性能测试工程师等等。如何对不同岗位的测试人员实施科学、合理、公正的考核，已成为测试管理工作的一个重点和难点。如果你是测试经理，你是如何对你的团队进行业绩考核的？如果你是测试工程师，你现在被考核的标准是什么？而你期望的标准又是什么？欢迎大家讨论交流。

感谢会员huior 提供此精彩问题！如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

非常感谢各位会员积极参与，截止至4月18日17：30分，从该贴所有评论中选出部分作出精彩评论的会员予以奖励。礼品和积分将在下周内送出。

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	godn_1981	当当购物卡50元	14#
二等奖	忘记了	300论坛积分	6#
二等奖	duola1119	300论坛积分	18#
三等奖	yolander	100论坛积分	10#
	anhuibing		11#
	stillying		17#

作者: testingFighter 时间: 2008-4-11 21:05
在传统的IPD-CMM流程中，定了几个指标：比如，测试用例的设计效率，测试用例的执行效率，每一轮测试发现的问题数，问题级别数等；但是越来越多的项目表明，传统的CMM项目一旦转测试后，测试的轮次就变的不可控了，前期不断积累的质量问题会随着测试人员对所测试特性了解的深入而逐渐表现出来，很多情况下会表现为：第一轮测试时问题单很少，而到了第二轮以后，问题单就会出现“井喷”现象

这导致了软件的发布周期被延长了，但是达不到质量目标又无法发布，于是，测试人员需要提前介入，参与系统规格以及方案设计的评审、E2E测试用例的输出、ST以及SDV用例的输出以及执行；相应的，对测试人员的考评指标也有了变化，测试人员负责某特性的最终交付，转回归测试的轮次数等（越少越好）

作者: puchonghui 时间: 2008-4-11 21:23
仅仅通过数据统计来进行绩效考核纯属恶搞
当然数据确实可以起到一些参考作用
但是人和机器是有区别的
考60分的人和考59分的人在绩效上一定是有什么本质区别么？

有资格评定具体测试人员的应该是leader或者主管
只有他们才最了解自己手下测试工程师的工作情况
外部应该是对整个项目团队或者测试团队进行考核

至于具体的考核评定方式
小企业可以采取在一定基础上的相对评定
大企业的话可以有一个基本的定性考核
然后由各个级别的主管分别进行比较细致的定性评定
标准要根据实际情况来制订
总之一大堆数字是不可取的
别的不说
这种统计出来的数字可信度就很成问题

补充说明：
我还记得上次说过管理者要做的四件事情：
1 雇佣正确的人
2 分配合适的事情给他们做
3 保持他们的积极性
4 使你的团队拥有足够的凝聚力

在制定绩效考核规则时一定要记得这是为这四点服务的
（唔。。主要是3 保持他们的积极性。另外，可能会对4有一定影响……）

[ 本帖最后由 puchonghui 于 2008-4-11 21:28 编辑 ]

作者: testingFighter 时间: 2008-4-12 22:09
绩效当然是有一些量化指标的，因为项目本身就应该是可度量的
主观的考评以及周边同事的评价个人认为只能够作为评测的一个维度，而不是全部

作者: iori 时间: 2008-4-14 08:59
提交缺陷总数
提交非缺陷数量
提交有效缺陷数
提交缺陷分类数
回归缺陷数
争议缺陷数
非独立测试发现的缺陷占比
严重缺陷所占比例
设计执行用例数（日平均值）
用例有效性
工具掌握能力
缺陷描述
工作态度
沟通能力
学习能力
团队精神
业务知识
问题解决
执行力
沟通能力
工作热情
责任心
顾客意识
合作
品质

作者: 忘记了 时间: 2008-4-14 09:37
提交缺陷总数
提交非缺陷数量
提交有效缺陷数
提交缺陷分类数
回归缺陷数
争议缺陷数
非独立测试发现的缺陷占比
严重缺陷所占比例
设计执行用例数（日平均值）
用例有效性
---------------------------------
不赞同以Bug数量或执行case量作为考核标准。要不然测试就变以味。纯粹为了bug量也提交bug,为执行量而执行case。测试本身最主要的不是为了测试而测试，而是为了提高产品质量，保证软件开发周期的整个过程。
就算每天你提交了100个bug,那又有什么意义？这只能说明Dev的水平急需提高。一个好的测试人员是应该把问题发现在开发前期，尽可能的减少不必要的bug.预防重于事后的发现和修补。要不然测试人员永远无法从高bug量和高regression test的泥潭中解脱出来。特别是对于一些快速开发的项目。

以上是我本人的一些想法，就事论事而以。并没想要针对谁。如有说错的地方，还请iori见谅。

作者: zlyhello 时间: 2008-4-14 11:05
这也是我目前面临的问题，公司应该怎么样合理，科学考核测试人员的工作？测试人员被考核的标准是什么？比较难界定，看看大家有什么好办法

作者: 天天乐乐 时间: 2008-4-14 15:17
发现1个系统架构设计方面存在的缺陷和隐患，远比发现几个普通界面的显示问题要有价值的多。因此，在对测试人员进行评价时，必须区分不同问题的重要性和价值。

作者: lgh1999 时间: 2008-4-14 15:44
1、首先，是考核的环境是否适合，如果公司仍然存在一个动荡的环境，人员流失率很高的情况下，是不适合的。
2、如果外部环境具备，那么要分清考核的目标是什么？测试的效率？测试人员的自觉性？
3、不同的公司文化采取不同的考核方法是最好的。建议是将关键事件做为考核指标，其它的数据考核起来非常的麻烦，而且让
所有的人员对数字非常的厌恶。

作者: yolander 时间: 2008-4-14 16:17
我觉得五楼的同行列出的统计项中，对测试执行的工作已经涵盖的比较全面了，但是缺少对测试设计这块工作的关注，事实上，我认为测试人员的优劣，或者是否有发展和提升的空间，很大程度上也取决于他的测试设计能力
如：
评审testcase是否覆盖了系统需求中的全部功能；
评审testscenario是否覆盖了用户需求的全部业务流程；
测试设计是否有效规避了大多数的风险（除部分无法用测试这种手段进行风险控制的）；
此外，对测试缺陷提交数进行考核时，要结合问题的等级、再现频率、状态等予以计分，不能仅仅核计问题的数量，当测试人员提交的问题质量较高时，相应的分数也应该有所体现，对测试错误，提交无效问题等，需要考虑增加负分，提高测试人员提交问题的谨慎率。
对测试漏出率也应有所统计，也就是说当系统测试结束后，提交外部测试，或者用户验收测试时，统计返回问题，分析这些问题被测试人员遗漏的原因，同时也需考虑增加或更新测试设计，以覆盖这部分内容，这样做不仅仅是为了对测试人员有所评价，更主要的是可以借此提高测试能力，减少测试盲点，为下一步的工作做好准备。
最后，还需要考察测试人员的工作责任心，积极性，以及学习能力，好的测试人员要耐得住寂寞，细心，并有精益求精和较真的精神，还要有原则，能够坚持自我，在循环往复的工作中，仍能精神抖擞，不会对错误视若不见，学习能力强，因为好的测试人员要比开发人员更了解整个系统，对业务知识的掌握要比开发人员更丰富，这样，你才能以一个权威的面貌去面对开发人员，这时你提出的问题，开发人员也才更容易接受
以上是针对项目中测试人员的表现予以评价的几个观察点，如果是对测试人员的职级胜任能力进行评价，可能还要考虑的更多

[ 本帖最后由 yolander 于 2008-4-14 16:19 编辑 ]

作者: 泥泥虫 时间: 2008-4-14 20:21
个人认为这个还得取决于公司简历比较健全的考核机制
如设立：测试人员需要每天提交测试日报，测试记录，缺陷个数。通过对这些数据的考核，加上组员和leader的综合打分进行业绩考核~~

作者: 贱王之王 时间: 2008-4-15 09:02
不同项目负责不同的测试模块存在或发现的bug数目也是不同的
有些测试更需要技术，有些可能参考需求文档就能测
而把测试用例等文档也拿来考核更是不合理的

应该由测试组长和测试经理有工作态度和工作努力情况等来考核
新手很努力但发现问题少，老手很了解业务，技术又高发现的自然多
就不能定结论说新手业绩差

态度
上进心
责任心
团队合作心
学习能力
这些才更重要

作者: godn_1981 时间: 2008-4-15 17:42
标题: 回答软件测试考核的问题
鄙人从事软件测试好几年了，也一直为该问题困扰，每次项目作完了，感觉大家都表现还马马虎虎。但是项目却感觉总不是那么完美，既然存在问题，说明测试人员的考核做的不到位，所以最近痛定思痛，也咨询了一些在微软和IBM做测试的朋友，结合自己多年来的实践，得出如下核心考核指标，和大家共享。
测试人员主要是三个方面。
第一，整体工作效率。第二，工作结果。第三，过程控制。（针对测试主管或组长）

1.整体工作效率
1.1有效工作时间
主要check指标是每日实际工作时间，按照Ms的标准，一个测试工程师的每天的有效工作时间应该在70%以上。如果只有50%或以下的有效工作时间，那么不能成为好的测试工程师，因为他有能力做得更好。
1.2是否在制定时间内完成工作任务
主要check指标是进度偏离度。主要是和测试计划相比，有多少的延期。这个指标计算是：计划时间/实际需用时间。
当然，本指标未考虑其他因素，如开发人员窝工导致的delay。
2.工作结果
2.1测试用例的数量和质量
a，测试用例的数量
主要考核指标是用例编写速度，考核办法是测试用例的个数/写用例所用时间。
b，测试用例的质量
主要考核指标是用例编写质量，用于考察文档是由有效的指导了测试工作。考核办法是来自用例的bug数目/总bug数目，应该是70%以上才算是质量比较好的用例。
2.2bug的数量和质量
a，bug提交的数量
主要考核指标是提交bug的数量，这个指标根据项目不同而定，不好给出固定经验值。
b，bug的质量
主要考核指标是提交bug的质量，即提交的bug，严重程度和，发现路径的复杂程度
c，发现bug的阶段
主要考核指标是提交bug的时间段，具体执行是统计在测试的每个阶段，发现bug的比例，特别是严重的bug发现的早晚
2.3是否及时验证关闭bug
主要考核指标是验证关闭bug的及时度
2.4测试自动化程度及收效
主要考核指标是，测试中自动化运用的含量，也就是测试技术含量，成果如何？
2.5所负责模块的产品总体质量以及用户反馈
这个总体质量是产品发布之后一段时间才能得出结论，主要是市场，用户对产品的质量、稳定性、性能的反馈。
考核的主要指标是两个。
a，根据市场反馈（由经理定性考核）
b，根据测试人员提交的bug和用户反馈的bug之间的比例，比例越大，说明测试质量相对越高。当然前提是必须划清楚客户的新需求，或者对spec设计方面的抱怨。
3.过程改进
考核点，是纵向对比，相比上一个项目，在质量控制上和测试进度进程上有否进步。包括测试方法，提升质量的手段，测试数据记录，用例更新等等有没有改进。
该项具体考核方法也是经理来根据测试组在过程中具体表现，来定性打分。
还包括测试人员在测试过程中的学习能力。这个也是定性。
4.考核注意事项
4.1统计bug的注意事项
5.其它注意事项
作为考核者要注意以下比例，也许有些没有列入考核内容，但是如下这些点可以指导测试。
a，测试团队发现的bug和所有bug之间的比例
b，spec设计造成的bug
c，重复或者误提交的bug所占的比例
d，每周发现的bug的趋势图
e，Bug严重等级的构成比例
f，Bug从提交到解决的平均需要时间
g，Bug从解决到关闭的平均需要时间

作者: lucky_snow 时间: 2008-4-15 17:42
目前我们公司的考核指标：
1、技术
2、工作能力
3、工作态度
4、合作能力
5、上级的评价

[ 本帖最后由 lucky_snow 于 2008-4-15 17:44 编辑 ]

作者: jhxhlj 时间: 2008-4-15 23:01
作为测试工程师可以有：
测试设计能力，测试脚本编写能力，沟通能力；
具体比如，发现BUG能力(数量，质量）、漏测问题（数量，严重程度），对团队的技术贡献等等。

严重反对目前的以工作时间来度量

作者: stillying 时间: 2008-4-15 23:35
上述的所有项我们的绩效考核表里都包括,呵呵,但主要以BUG总数,有效BUG数,无效BUG数,BUG的级别高低,以及漏测率,执行用例效率,工作时长,编写用例的发现BUG数为主.
个人认为存在以下蔽端:
1.测试工程师为了提BUG而提BUG,有些开发已在下个版本改过了,再提上来,只是浪费大家的时间
2.BUG级别越高对测试的考核越有利,虽然有BUG级别定义,但仍存在提高级别,造成不公平因素.
3.由于项目不同,BUG数量肯定也不同.
4.开发和测试的绩效考核是对立的,造成一定程度的不和.
5.工作时长只能助长加班,但不一定有效率.
6.有时为了跟踪一个BUG浪费好长时间,是不是就放弃,找些容易的BUG提.

解决方案暂未想到~~~~苦恼中~~~

作者: duola1119 时间: 2008-4-16 10:58
这个问题不好回答，但是看了14楼给予的答复，非常的佩服
14楼的兄弟所回答的应该都已经包括了，如果在重述就没有意义了，在此我想补充几点。
LZ的问题中提到“业绩”这个词，没有创造出价值的人不会有业绩，通俗的讲没有给老板挣钱的人你就没有业绩，我要说的就是：得到公司高管的认可或得到过嘉奖应该是一个重要的指标
看到大家似乎都将测试人员定位在测试执行人的角色，但却都忽略了测试经理这个角色，那么换个角度，测试经理在高管的眼中也应该算是一个测试人员，或者测试经理本人应该对自己也应该有一个特殊的业绩考核标准。
1。工作计划制定的是否到位，是否分配到每个人、每天、每时。
2。工作计划的可执行程度
3。项目估计总BUG数
4。项目实际总BUG数
5。估计误差（实际总BUG数/估计总BUG数×100%）
6。领导能力和服从领导的态度
7。领悟能力
8。计划能力
9。指挥能力
10。控制能力
11。协调能力
12。授权能力
13。判断能力
14。创新能力

作者: chainylove 时间: 2008-4-16 17:02
刚刚做完软件测试人员的考核。如果这个贴能早点出就好了。
对测试人员的考核，我个人觉得主要从以下几方面考虑：
1、测试的质量
2、测试的效率
3、测试的进度偏差
4、测试流程执行情况

我们现在暂时的考核指标有以下几个：
1、上线后系统的故障时间
2、测试项目的验收通过率
3、软件缺陷的发现率
4、软件流程的执行
除了这几个测试指标外，还有一些如工作态度、学习能力、主动性等方面的考核
请大家指正。谢谢！

作者: liumeixian030 时间: 2008-4-16 17:26
仅从提交的bug单数量、执行测试用例数量来判断这种做法显然缺乏全面性，bug单的数量只是评估测试质量的一个方面，我们更需要看总实际的测试质量，所以考核测试人员工作绩效应该考察：
1、bug单的质量
2、测试的难度
3、bug单的级别
4、测试文档的质量
5、测试人员的综合素质

作者: liulinzhu 时间: 2008-4-16 18:49
#14说得非常好

作者: 谢谢你的绝情 时间: 2008-4-17 11:26
#14``看不太懂啊...

作者: saxifrage 时间: 2008-4-17 15:20
14楼的回答很全面。
我补充一下：
1. 1.2项目延期率：我们公司目前的考核制度里，这是一个很重要的因素，项目出现延期整个项目组每个成员的绩效都会受到影响；
2. 2.2 bug的数量和质量：这个我更看重的是提交bug的质量，不同严重程度的bug比重不同。

引用14楼的回答：
回答软件测试考核的问题
鄙人从事软件测试好几年了，也一直为该问题困扰，每次项目作完了，感觉大家都表现还马马虎虎。但是项目却感觉总不是那么完美，既然存在问题，说明测试人员的考核做的不到位，所以最近痛定思痛，也咨询了一些在微软和IBM做测试的朋友，结合自己多年来的实践，得出如下核心考核指标，和大家共享。
测试人员主要是三个方面。
第一，整体工作效率。第二，工作结果。第三，过程控制。（针对测试主管或组长）

1.整体工作效率
1.1有效工作时间
主要check指标是每日实际工作时间，按照Ms的标准，一个测试工程师的每天的有效工作时间应该在70%以上。如果只有50%或以下的有效工作时间，那么不能成为好的测试工程师，因为他有能力做得更好。
1.2是否在制定时间内完成工作任务
主要check指标是进度偏离度。主要是和测试计划相比，有多少的延期。这个指标计算是：计划时间/实际需用时间。
当然，本指标未考虑其他因素，如开发人员窝工导致的delay。
2.工作结果
2.1测试用例的数量和质量
a，测试用例的数量
主要考核指标是用例编写速度，考核办法是测试用例的个数/写用例所用时间。
b，测试用例的质量
主要考核指标是用例编写质量，用于考察文档是由有效的指导了测试工作。考核办法是来自用例的bug数目/总bug数目，应该是70%以上才算是质量比较好的用例。
2.2bug的数量和质量
a，bug提交的数量
主要考核指标是提交bug的数量，这个指标根据项目不同而定，不好给出固定经验值。
b，bug的质量
主要考核指标是提交bug的质量，即提交的bug，严重程度和，发现路径的复杂程度
c，发现bug的阶段
主要考核指标是提交bug的时间段，具体执行是统计在测试的每个阶段，发现bug的比例，特别是严重的bug发现的早晚
2.3是否及时验证关闭bug
主要考核指标是验证关闭bug的及时度
2.4测试自动化程度及收效
主要考核指标是，测试中自动化运用的含量，也就是测试技术含量，成果如何？
2.5所负责模块的产品总体质量以及用户反馈
这个总体质量是产品发布之后一段时间才能得出结论，主要是市场，用户对产品的质量、稳定性、性能的反馈。
考核的主要指标是两个。
a，根据市场反馈（由经理定性考核）
b，根据测试人员提交的bug和用户反馈的bug之间的比例，比例越大，说明测试质量相对越高。当然前提是必须划清楚客户的新需求，或者对spec设计方面的抱怨。
3.过程改进
考核点，是纵向对比，相比上一个项目，在质量控制上和测试进度进程上有否进步。包括测试方法，提升质量的手段，测试数据记录，用例更新等等有没有改进。
该项具体考核方法也是经理来根据测试组在过程中具体表现，来定性打分。
还包括测试人员在测试过程中的学习能力。这个也是定性。
4.考核注意事项
4.1统计bug的注意事项
5.其它注意事项
作为考核者要注意以下比例，也许有些没有列入考核内容，但是如下这些点可以指导测试。
a，测试团队发现的bug和所有bug之间的比例
b，spec设计造成的bug
c，重复或者误提交的bug所占的比例
d，每周发现的bug的趋势图
e，Bug严重等级的构成比例
f，Bug从提交到解决的平均需要时间
g，Bug从解决到关闭的平均需要时间

[ 本帖最后由 saxifrage 于 2008-4-17 15:24 编辑 ]

作者: 天下清流 时间: 2008-4-17 22:22
如果我是测试经理，我会看我的团队在一定时间内的成绩从而进行业绩考核
我现在被考核的标准就是所取得的成绩，毕竟在这个商业化的世界里，所有人的目标都是如何赚钱，这也符合发展的方向，多劳多得，少劳少得，我同意拿成绩来考核！

作者: huior 时间: 2008-4-18 09:57
看来偶的这个问题不太受“欢迎”哦，快颁奖了，候选人才这么多

作者: bht2000 时间: 2008-4-18 15:43
我只想说,这个问题很歹毒!~~~目前我还没听说国内有哪个企业能把测试工程师的考评做的很好的~~~~~

会员huior 不愧是高手,问出了众多测试管理人员心中共同的疑惑,呵呵~~~
期待好的回答~~~~

作者: huior 时间: 2008-4-18 17:29
标题: 回复 26# 的帖子
本周的评奖已经结束，但回答仍在继续，期待更好的回答

作者: puchonghui 时间: 2008-4-20 10:10
我不懂为什么需要这样的绝对量化标准来对个人进行考核
作为公司来讲，提高效益是通过团队来实现的
非要对个人分个三六九等还怎么凝聚一个团队呢
作为老板，永远都不知道一个测试团队里的一个测试工程师每天到底干了哪些事情。那又如何对他考评呢？
作为测试主管，记录数据当然是必要的。但是这些数据是作为一种度量以及为今后的项目前期工作提供一个参照，绝对不能作为什么死板的考核标准。一个团队中每个人所起的作用是不同的。有些人看似没有产生多少业绩，但是他在团队中可以起到一种无法衡量的推动作用。你如何通过数据来考核这种人？

14#这种回答就是典型的拿人当机器来管的
而且很多是有问题的

1 测试用例的质量
这个是现在很大的一个误区：认为一定要发现bug的用例才是个好的用例
这句话本身确实有道理。但是拿这个当考核标准的话，很可能使得设计用例的人一心想要设计出能够发现那些“难于发现的缺陷”的用例，陷入到了一种片面当中去。忽略了对测试需求必要的覆盖。

2 bug的质量
个人看法这纯粹是在纸上谈兵。不知道14#能否解释下什么才是高质量的bug？或者回答我一个问题：一个bug发现界面上的一个按钮位置错了，另外一个bug发现表单全为空值时提交会crash，这两个bug哪个质量高？

3 是否及时验证关闭bug
这个在项目中会和很多客观因素相关，怎么能作为考核标准-_-

4有效工作时间
有效工作时间要参照ms的标准，为啥不在工作环境和员工薪水方面也参照下ms的标准呢？我可以非常肯定的说：90%以上的公司没有给员工提供一个合适的工作环境。
另外根据我多年工作经验可以告诉你：一个人是不可能连续8小时集中精神保持相同的高效率进行开发或者测试工作的。你所谓的有效工作时间增加可以让员工工作得更多更快，但是会让他们效率更低质量更差。

作者: huior 时间: 2008-4-21 10:15
标题: 回复 28# 的帖子
说的有道理。不过有时候拿数据说话，也是不得已而为之。试想一下，如果采用PERT的方法来考核，如果下属有人有异议，岂不是更没有办法服众？

继续期待更好的答案！

作者: godn_1981 时间: 2008-4-21 13:28
标题: 28#太幼稚了
每一种行业都有考核办法，每一个行业的从业人员都有高下之分，当然很多东西是要定性的，也就是说不是所有的东西都可以量化的，但是如果不能挑出一些可以量化的关键指标，就是KPI，那么测试人员根本没有办法考核？如果你手下5个测试人员，都在做同一个项目，如果没有一些量化的指标，请问你如何进行升降奖惩？吃大锅饭显然不是办法。
另外，我要说的是，任何一个考核的前提都是说，找准核心指标，就是说哪些指标确实能反映问题，哪些指标确实能体现你的工作效率，工作质量。
我在14#所发的帖子就是我个人根据多年的实践，参考一些大公司的做法，所提炼出来的一些指标。
当然在具体考核的时候总归是有很多的客观因素，不是硬性照搬，但是总归得有些核心指标。我一向认为测试人员的考核很难进行，但是不能因为难就不做，并且确实有一些指标可以使不同的测试人员有高下之分的。

作者: smileoleo 时间: 2008-4-21 17:25
考核是很全面,可是由谁来评估呢?

作者: qayang 时间: 2008-4-22 19:36
测试人员的作用，是为了保证产品的质量，那么，在测试中发现的bug的数量及质量，当然就是考核的首要指标。
发现产品的bug，如果bug得不到开发人员的认可或不能及时的解决，那么，发现的这个bug就没有价值，因为没有因此提高产品的质量
，所以，我认为考核的第二指标，就是bug的解决率。
测试人员和研发人员，在某种程度来说，就是对立的两个工作角色，而为了测试的顺利进行，测试人员及开发人员的友好和睦关系，直接
影响到了测试的执行效果，因此，有效的沟通及测试人员工作的态度也非常重要，这是考核的第三指标。
事实上，能否有效的进行测试，和一个人的工作态度及其相关，只有有耐心，有责任心，才能把这份工作做好，呵呵，写到这里，我感觉责任心和耐心的
好像比发现的bug重要性还高些：）
剩下的，还有测试人员的学习能力等等等等，其实都很重要

作者: zlyhello 时间: 2008-4-23 11:20
我们的测试工作考核这方面也存在困扰

作者: jm38706415 时间: 2008-5-9 17:07

原帖由 puchonghui 于 2008-4-20 10:10 发表
2 bug的质量
个人看法这纯粹是在纸上谈兵。不知道14#能否解释下什么才是高质量的bug？或者回答我一个问题：一个bug发现界面上的一个按钮位置错了，另外一个bug发现表单全为空值时提交会crash，这两个bug哪个质量高？

写得清楚就都是好bug，写得一点逻辑都没有，就都是不好的bug

作者: caoqd 时间: 2008-5-16 17:04

作者: cjchm 时间: 2008-5-21 11:01
能说到测试人员的绩效考核问题，看来你们的测试工作已经比较正规划了，羡慕中....
在一个速制的软件项目中进行测试真是件永无天日的工作，像这种较正规的测试团队提交的bug是否及时的被开发人员kill掉了呢？
既然说到对测试人员的绩效考核，是否开发这边也有相应的考核制度？
只有开发人员修改了bug，自己才可进行验证测试、回归测试，似乎测试人员总是被开发人员牵着鼻子走，如果他们不合作或不及时，我们的工作简直就是白瞎，这样的工作岂不是很郁闷

[ 本帖最后由 cjchm 于 2008-5-21 11:02 编辑 ]

作者: 赵晨雨露 时间: 2008-5-26 17:37
标题: 共同学习，只为了软件测试人员和这个岗位能被更多的人视为重点。
说的很好哦，说的还是蛮全面的，相信你也是一名不错的测试人员噢，我是刚刚做测试，希望以后能多多指教。一起努力！

作者: vxiaoqiangs 时间: 2008-6-4 14:35
对待工作的态度，BUG数量+质量，自己工作能力的提升，自己对测试团队的贡献（知识、心得、经验的共享）

作者: testman 时间: 2008-6-25 19:46
标题: 回复 28# 的帖子
puchonghui说的问题，都是很实际的问题。

有些方案看其来很让人兴奋，实际上可实施性并不高；
有些数据看起来很漂亮，实际上并不能反应客观事实。

不管什么样的方案，要想发挥预期的作用，关键有几点：
1，可以得到大家的一致认可和支持。
2，得到严格的执行。
3，执行中可以不断的完善。
实际工作中，恐怕没有几个考核方案能够达到预期的目标。

我们为什么要考核？？

考核只是一种手段，但是，绝不是唯一的手段。千万不要为了考核而考核。

实际的工作，不仅仅是测试，都不是像考核标准那样死板，有很多工作，或者问题，都是考核标准以外的，无法用数据来衡量的。而这些无法衡量的东西，有时可能很重要。

作者: testman 时间: 2008-6-25 19:51
一个为了数据而工作的人，很可能不是好员工

作者: 卖烧烤的鱼 时间: 2008-6-26 16:29
标题: [原创]如何有效的考核测试人员
[原创]如何有效的考核测试人员
当前国内很多公司对测试存在普通的认识不足，经常听到许多公司拿Bug的数量来考核测试人员的唯一方法，哪么我要说“测试人员的考核不是仅仅看Bug的！"

如何有效的考核测试人员？好的考核能激励测试人员，提高工作效率；相反“不公正”的考核，则会降低工作效率,引起测试人员的不满！本文作者以实际的测试管理工作经验结合当前公司的特点制定了以下措施，相信肯定有很多测试人员会产生共鸣！


1 工作态度
  通常由“协作性”，“积分性”“责任心”三部分组成，每部分为4档：优秀，良好，合格，差

2 对公司产品业务流程了解程度
  通常分为4档：精通，熟悉，了解，不清晰

3 测试技术(手工+自动化)
  通常分类“手工测试”和“自动化测试”,其中两个大类又细分技术难度为：难，一般，容易
  通常初级，中级，高级，测试组长等是依据职位的定义性质不同来考核，每个职位等级分为"优秀"，“良好”，"合格","差"：
  如初级测试工程师重点考查“Bug”的数量和严重性，用例的编写覆盖，Bug Report的规范性等

5 测试文档
  编写用例个数/修改用例个数，测试用例覆盖度，新增用例个数，用例的难度
  编写测试报告的质量,通常分为"优秀"，“良好”，“合格”，“差”几等

6 Bug数据
  通常用发现Bug的(数量，有效和无效，发现/解决比率，运营/测试环境数据评比)

7 测试是否尊守流程
  通常分为(优，良，合格，差)

8 团队贡献
  通常这项做为激励大家，如XXX人兄给大家培训“httpwatch工具”，依据培训效果分为"优秀"，“良好”，“合格”，分别对应相应的分值。
  如小马哥给部门建议XXX项目需求评审Checklist.doc，这些均可
以上仅仅是考核的几个大的方面，当然在实施具体考核过程中，还需结合公司具体的要求！

原文贴子：http://www.cnblogs.com/mayingbao ... 2954.html?updated=1

[ 本帖最后由卖烧烤的鱼于 2008-6-26 16:31 编辑 ]

作者: Lighthouse 时间: 2008-11-7 10:57
我也来说一点吧。
首先要弄清楚考核的目标是什么？考核的目标主要是下面几点
＋从员工的角度看：
第一：是对员工一年或者一段时间以来工作的总结。好还是坏。
第二：考核一般决定了员工的奖金幅度以及工资增长幅度。
第三：员工也希望通过考核的过程，知道自己有那些不足，以及公司对自己有那些期望。
第四：也有部分员工希望从考核过程中知道下一年的计划，以及自己在下一年的工作安排。
第五：在考核过程中，员工对与自己在团队中的相对位置也很敏感。就是相对比较优势。

＋从公司的角度看：
第一：同样是对一段或者一年以来工作的总结。
第二：决定年终奖金和工资的分配。
第三：通过这样一个考核的过程激励或者鼓励员工努力工作。
第四：通过考核增加团队凝聚力。
第五：自然也可以用这个机会，对表现不好的员工进行警告，对表现好的员工进行表扬。
第六：用考核的机会把那些有可能辞职的人然而公司又很需要的人，以及工资明显偏低的人的薪水进行调整。
第七：把那些公司不怎么需要的人，或者你想让他走人的人进行处理。

综合上面的目标，采用14＃提出来的一些数据。对每个人进行考核。

作者: msnshow 时间: 2008-11-9 22:27
一大难题,考核内容大概就是上面各楼说的那些了,但各部分所占的比例如何分比较合理

作者: v_v 时间: 2009-4-1 22:44
请问：
1、如果一个人分配的项目比较多，交叉项目测试，像我们公司有时小的需求变更，（如：图片修改、版面调整、文字修改等等小问题）走测试流程也要分配人去测，可能这个修改没有产生BUG，但是测试人员也去花时间去测试了，那怎么考核这人的业绩？
2、如果我手下有2个人，我本来自己也是测试人员，有项目要测的时候，我分配他们去测BUG比较少的项目（开发人员很资深），我自己去测新来的开发人员做的项目，那我的产出BUG肯定是较多的，、。还有一种情况，我是第二轮测试才加入一个项目测试中来的，大家知道，测试到后期很难发现比较多的BUG，因为都被人找的差不多了，隐藏的很好的BUG可能一小时或一天才发现一个，那这个又怎么来划分到我的考核目标中来。

作者: xilan 时间: 2010-2-1 14:54

需要好好研究该问题！

作者: ilove51 时间: 2010-5-17 14:29
大家总结得不错，学习思考中。。。。。。

作者: syq8050 时间: 2010-5-22 17:14
标题: 回复 14# 的帖子
考核用例的质量对数目的要求应该是不对的，不同的人写不同的功能，产生case的数量是不同的，有的功能会需要相似的case很多条，有些功能case都是单独存在的没有类似，用数量的评定对写后者功能的测试员来说岂不是不公平啊

作者: syq8050 时间: 2010-5-22 17:17
标题: 回复 6# 的帖子
说的在理，光评交bug数量来评定确实有伤工作的性质，希望领导层能了解到

作者: msnshow 时间: 2010-5-25 08:50
其实对于同一个项目来说，考评到还比较好做，对于不同的项目，感觉太难去做考评了

作者: linda22 时间: 2011-2-10 14:37
我想问下，我们公司的需求不稳定，设计很粗糙，只是界面设计，里面的逻辑是需要设计员或是程序员完成程序后告知的，但是对测试和QA也需要考核，不知道怎么考核，参考了很多，想的也很累，但是总觉得都不合适，例如，BUG的追踪，一般级别非常高的BUG，也要看程序员是否有空修改，一些级别低的，根本就不改，备注里写明延期就基本不改动了，只要客户不提出，就过去了，客户提出后是会改的，这个写在测试的考核里也不合适，至于测试用例，只是界面设计的测试用例质量本身就有限，很多都是后期补的。有效工作时间倒是可以参考的，但是具体怎么去统计呢？每天写工作报告么？

作者: mvaalbt 时间: 2011-8-27 13:42
支持楼主哈哈

祛痘印产品排行榜

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)