如何有效的考核测试人员(原创)

2010-03-03  陈晨 

如何有效的考核测试人员

    当前国内很多公司对测试存在普通的认识不足,经常听到许多公司拿Bug的数量来考核测试人员的唯一方法,测试人员的考核不是仅仅看Bug的.
    
    如何有效的考核测试人员?好的考核能激励测试人员,提高工作效率;相反“不公正”的考核,则会降低工作效率,引起测试人员的不满!

1 工作态度
  通常由“协作性”,“积分性”“责任心”

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

3 测试技术(手工+自动化)
  通常分类“手工测试”和“自动化测试”,其中两个大类又细分技术难度为:难,一般,容易

4 依据不同职位考核
  通常初级,中级,高级,测试组长等是依据职位的定义性质不同来考核. 
5 测试文档
  编写用例个数/修改用例个数,测试用例覆盖度,新增用例个数,用例的难度
  编写测试报告的质量,通常分为"优秀",“良好”,“合格”,“差”等

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

7 测试是否尊守流程
8 团队贡献
  通常这项做为激励大家,如XXX人兄给大家培训“httpwatch工具”,依据培训效果分为"优秀",“良好”,“合格”,分别对应相应的分值。
  如XXX给部门建议XXX项目需求评审Checklist.doc.

考核具体方法:

1.将各项指标进行汇总分析,得出总和表格,根据测试人员各项指标大小进行排行榜制作,如列出 1 、 2 、 3 、 4 名。

2 .确定阶段涉及的权重。例如将测试设计和测试执行权重各为 50 %。其中,工作效率占 40 %(即占所在阶段 20 %),工作质量占 60 %(即占所在阶段 30 %)。


3 .确定每类指标的分值,然后每类指标达到平均标准给 100 %,达不到或者超过根据 80 % ~120 %比率给分


4 .将比分统计出来后进行综合评定,必要的话增加一些调整系数。

5 .最好将定性分析纳入进来,采用问卷调查和项目经理评分制度给出定性指标分数,建议这部分权重不要超过 10 %~ 15 %以保证测试考核的可度量性。

当所有考核分数给出之后,提醒一点的是,既然做了考核,就必须公开这些结果,而且考核具有导向型,不要让考核误导了对质量工作的追求才是最重要的。
考核注意事项:
1.项目并不是一个月就能完成的,如每月进行,要考虑“可考核部分”为那些,挑选那些指标能够横向对比,然后分阶段、分任务评定。

2 .参与测试的时间长短也要给予重视,除了上述量化指标外,测试人员整体投入时间长短也是很重要的,加班也要作为特殊考虑因素,也许某个测试人员只参加了测试执行 3 小时,各项指标都是良好的,但是不可能给他比其他参与时间更长的人员更多的分数。这部分就是增加调整系数的原因。

3.测试经理的测试设计和执行部分和项目测试人员一起考核,但是测试管理工作要单独考核,作为另外的加分,或者如文章前面所述纳入项目组给予考核。因为测试经理在项目测试中起着管理者和质量保证负责人的角色,不要把他和其他测试工程师平等对待。

4 .考核前要考虑项目的实际情况,不要盲目的轻易承诺测试组人员考核会和薪金或者淘汰机制挂钩,否则考核会起到反效果。
项目组测试人员考核的主要目的是在于激励测试组测试人员工作,鼓励能者,鞭策落后;另外,还可以起到发现人才和查找不足的作用。考核中即要体现多劳多得的原则,也要体现公正性和合理性原则,奖罚分明才能有效促使质量管理工作的进步。要想考核得到满意的效果,上述方法的重要的前提条件是:必须要在项目中充分收集相关的数据,包括采集缺陷数,记录工时、提交详细工作日志和进行文档配置管理,没有这些数据,定量分析就无从谈起,测试人员考核也无从谈起。

考核的主要目的是:规范测试流程及具体操作,提高产品质量

以上仅仅是考核的几个大的方面,当然在实施具体考核过程中,结合公司具体要求!  

1038°/10287 人阅读/10 条评论 发表评论

王恩建  2010-03-03

一个很好的软件测试考核范本。不过我有些疑问,考核的项目里面大多是一些主观判断的项目,容易受外界因素干扰,对统一考核目标,“良好”,“合格”,“差”都是可能的。文章开头说有的公司只拿bug数目来考核,我的理解是bug数目量化,相对比较客观,争议性比较小,当其他考核项目做不到“公正”的时候,bug数目成为唯一的考核指标也不无道理。如果有条件,多维度考核肯定是最佳的。


金鑫  2010-03-03

LZ总结的的确很好


金鑫  2010-03-03

以往我们的测试人员也的确类似这样评定,正如1楼所说,这样评定方式的确部分量化了测试人员的工作成效,但是我们做的必定是质量工作,无论是主管评价还是量化评价,或者两者皆有的方式,都可能会有失公平性。
目前我们采用的是IBM的绩效考核体系是以一个称为“个人业务承诺”(PBC,Personal Business Commitments),以这套体系完成的承认表+你的绩效评估办法,似乎既不失公平且具有标准。LZ不妨了解了解


王恩建  2010-03-03

说道PBC,那就要提SMART原则了:Specific(明确性)、Measurable(可衡量性)、Attainable(可达成性)、Relevant(相关性)和Time-bound(时限性)。既承诺的目标要符合SMART,否则后续不能评估。在我看来PBC并非尽善尽美,承诺的目标总有一个交互时间吧,在这个交互时间什么事情都能发生,例如人员变动,计划改变,最后的结果可能是说一套做一套。说一套做一套怎么评估呢?有的人说承诺目标随时调整,是可以解决,但这成本也大了点吧。个人觉得PBC比较适合已经比较成熟稳定的大企业,小企业用这个就是瞎折腾。


孙建伟  2010-03-04

顶楼主,不过是不是增加一些对能力的考核,比如测试用例设计能力,脚本编写能力,模块整体掌控能力等,再用一些具体的数据来体现这些能力。


欧阳辰  2010-03-04

“以人为本”是绩效考核中非常重要的,任何一个绩效系统都不能保证其公平性和良好的操作性,关键是你的绩效考核过程和结果是不是让大家基本舒服。如果有矛盾,尽量将其影响化简成为最小。


何培昊  2010-03-05

首先必须制定严格的测试流程和考核标准
对于制定的标准要严格执行,这样在项目的不同阶段根据考核得出的结果进行讨论。用数据说话


陈春燕  2010-03-05

“也许某个测试人员只参加了测试执行 3 小时,各项指标都是良好的,但是不可能给他比其他参与时间更长的人员更多的分数。这部分就是增加调整系数的原因。”这个要根据人员的效率来考核,3个小时,完成了所有的测试任务,那其他人执行4个、5个小时完成的测试任务也是一样的,那我想前一个人的分数应该要更高吧,不能只单纯的看参与了多久时间,而且这个测试就只要我完成这个部分的任务。考核也要看按项目考核还是按时间考核。


陈春燕  2010-03-05

BUG考核, 我觉得数量只是一个参考,除非参加考核的人员测试的项目和模块是一样的,否则就不能用数量来衡量,因为项目和模块不同,本身存在的BUG数量就不一样了。BUG考核要考核漏测率,还有就是提交的BUG质量,数量我觉得只能是参考。纯属个人意见,不对之处多包涵。


周文  2010-03-08

陈春燕: BUG考核, 我觉得数量只是一个参考,除非参加考核的人员测试的项目和模块是一样的,否则就不能用数量来衡量,因为项目和模块不同,本身存在的BUG数量就不一样了。BUG考核要
那就根据项目发布后产生的pir以及提交的BUG来确定。即通常说的der


登录 后发表评论