最新软件测试人员绩效考核详细知识讲解.docx

最新软件测试人员绩效考核详细知识讲解.docx

《最新软件测试人员绩效考核详细知识讲解.docx》由会员分享，可在线阅读，更多相关《最新软件测试人员绩效考核详细知识讲解.docx（12页珍藏版）》请在冰豆网上搜索。

最新软件测试人员绩效考核详细知识讲解

1、测试团队绩效考核

　　绩效评估的的客体：

是个体成员还是整个团队。

　　●Pascerellayer认为，团队绩效评价应以成员个人完成工作的状况为基本依据，理由是激励只能作用于个人而不是群体；技能的提高和行为的改进最终必须落实到个人。

若仅考核团队绩效，个体的努力得不到充分的肯定，就容易造成社会懒散现象，即个体由于参加团队工作，其工作效率比自己单独工作时的效率反而大大降低。

此现象一旦在组织中蔓延开来，不仅会影响组织绩效，还会毒害组织文化。

同时，由于绩效考核与薪酬及个人价值的实现相联系，因此，在团队中，能力高的成员倾向于对个人绩效的考核，从而得到更高的认可和报酬。

　　●Zingheim和Schuster则认为对个人的考评应考虑团队的整体绩效，因为团队的成功很大程度上依赖于团队成员间的团结合作，理解支持，若评估集中于个体层面，会导致个人主义盛行，忽视团队的协作精神，阻碍信息、技能的共享和绩效的提高，降低团队工作的优势。

　　●因此在实际操作中，企业往往采取一种折中的方法，即按一定比例兼顾团队和个人两个层面的绩效考核。

从目前的研究来看，还没有一种很好的办法可以科学地确定这个比例。

但是，如果从团队性质的差异、团队所处的阶段等方面来考虑，那么至少可以确定考核的天平是更向个体的一极偏还是更向团体的一极偏。

　　绩效考核的内容：

结果、行为还是能力。

对于绩效内涵存在着三种不同的观点，即“绩效是结果”、“绩效是行为”和“绩效是能力”。

Bernardin将绩效定义为“在特定的时间内，由特定的工作职能活动产生的产出记录，工作绩效的总和相当于关键和必要工作职能中等绩效的总和（或平均值）”，这是“绩效是结果”的典型观点。

Murphy等人将绩效定义为“一套与组织或个体所工作的组织单位的目标相关的行为”。

近年来，以能力作为绩效的观点得到了广泛的使用，这是以评估个体所拥有的完成某项工作所具备的知识和能力的方式。

伴随着这三种观点的诞生和发展，绩效考核大致经历了基于结果、基于行为以及基于能力的三个考核发展过程。

？

虽然这三种观点相互区别，且都是在否定前者的基础之上产生的，但是，如果不带入特定的环境，特定的组织，及组织发展的特定时期，那么三者之间并不存在绝对的优劣。

如果组织下达的目标非常清晰，基于结果的绩效考核是最容易实施，也最有效；相反，如果目标模糊，无法准确衡量其结果，这种考核方式就会失效。

基于能力的考核方式理论上是从战略管理的角度出发，最具有激励效果和长期效应，最有利于组织不断发展，但在实际操作中却很难达到效果。

因为能力是无形的，它依附于个体，既受主观因素的控制，也受各方面客观因素的影响，很难用标准化的方法衡量个体的能力，即使是方法对组织期望成员所具有的能力和特质作出了解释，但这些解释仍是描述性模糊语言，在实际操作中仍然难以做到真正的科学公正。

基于行为的绩效考核方法通过考核员工为实现既定的结果所必须做出的行为来实现对结果的控制，由于行为必然是建立在某种能力基础之上的，并且行为比能力更具有外显性和可测性，因此一定程度上，该方法兼顾了组织目标和个人能力。

但是，绩效考核中容易出现目标置换的现象，一味对行为测评会导致成员将行为作为目标，进而影响实际目标的实现。

因此，无论哪种考核方式，都有其适用的条件和要求，不存在一种绝对好的方法。

　　基于项目团队生命周期的绩效考核：

　　●孵化诞生期：

这是指团队形成前到团队正式形成的一个阶段，是选择合适的项目成员组成团队的时期。

　　→考核的客体是个人。

团队的首要任务是筛选项目组成员，根据项目目标的要求，选择最为合适的人选组成团队，所以考核的对象是个人。

　　→考核的重点是能力。

从项目团队成立的目的来看，它一般是为了开发一种新产品或者提供一项新的服务，因此对成员的知识技能要求较高，需要成员具有较高的技术水平和知识储备以及不断学习和创新的能力。

同时，成立项目团队，意在发挥团队快速响应和凝聚集体智慧的优势，更加需要团队成员间的相互合作相互支持，所以需要较为系统地考核成员的协调合作能力，包括，对团队其它成员工作任务的认识、口头交流、个人成长、问题解决、责任承担、领导技能等等。

因此，在选择项目团队成员的时候，通过对被选者专业技能、基本素质当然也包括过去的工作经历和背景等各方面的考核，最终确定较为合适的人选。

　　●成长期：

这是团队正式形成之后，团队工作逐渐步入正轨，团队成员开始通过个人努力和彼此的合作共同在所研究的项目上获得初步的成就。

　　→考核的客体是团队。

团队成立之初，成员合作的意识还没有形成，工作的独立性较强，此时的工作重点应该是营造一种信任、关怀、相互支持的合作氛围。

同时，项目也刚刚起步，没有取得实质性的进展，个人的贡献还无法准确衡量，在这种情况下，如果过多地衡量个人绩效，特别是个人产出绩效，不仅不利于合作精神的培养，也会由于准确性不高而使成员产生不公平感，从而对团队工作形成抵触情绪。

注重团队整体绩效的考核，可以向整个团队成员传递这样一个信息，即必须注重团队的整体效率，共同开发团队能力。

同时，对团队绩效的考核还可以提高团队成员对自己团队的自豪感和所有感，并不断提高其认同感和归属感。

　　→考核的重点是行为。

刚刚进入一个新的团队，如果此前没有进行过合作，成员之间会由于陌生感而信任度较低，彼此在沟通和交流上存在困难，需要相当一段时间的磨合，工作进度也很缓慢。

如果不通过有意识的加强合作意识的培养，难么磨合期就会较长，从而影响目标的实现。

因此在项目团队进入成长期时，绩效考核的重点应该放在对团队成员行为的考核之上。

绩效考核不仅仅是一种过程的监督和事后的衡量，更是一种对员工行为进行引导的方式。

作为一种信息的传播途径，通过评估的本身，反馈以及与薪酬的联系，以直接或间接的方式告诉被考核者，组织鼓励什么样的行为、反对什么样的行为，从而引导和鼓励成员采用更加积极的态度和行为，主动参与团队工作，加强团队成员之间的合作和学习，使项目团队尽快度过磨合期，向着一个良性的方向发展。

　　●成熟期：

进入成熟期，团队工作进展顺利，项目取得关键性的突破，团队成员自由沟通，合作意识加强。

　　→考核的客体是个人。

此时应该加大对个人绩效考核的比重。

因为项目已经取得一定的突破，目标接近实现，团队成员的成果和贡献相对比较清晰，可以较为准确的衡量，需要对其加以肯定。

如果仍然只是停留于对团队绩效的整体考核，并以此为基础进行利益分配，个体会逐渐产生不公平感，因为随着项目工作的深入开展和目标的逐步实现，个人由于态度、能力、技术支持等诸多方面的差异，贡献度的差距会逐步扩大，客观上会有成员的贡献大于其它人，如果不及时加以肯定和认可，那么就会挫伤这一部分核心成员的积极性。

　　→考核的重点是结果。

成熟期的团队首要任务是推动工作进展，以保证最终成果的实现。

由于既有的工作方式已经基本形成，合作沟通的氛围已经建立，如果仍然强调对个体行为的考核，会使成员将大部分的注意力投入到日常的工作行为和方式之上。

事实上，鼓励行为的本身并不是目的，关键是行为带来的结果，合作和交流是团队的基本工作手段，但手段不能代替目的，项目及时高效地完成才是项目团队的存在目的。

如果不以任务为导向而长期进行行为考核，容易使个体忽视目标和结果，影响工作的效率，例如，过分的注重沟通和交流，造成决策时议而不决，贻误时机，或者意见趋中，成员过分尊重群体意见，不愿表达自己突破性的想法和思路。

　　●衰退期：

项目目标已经基本实现，团队即将解散，此时需要对整个项目团队作一个综合的评估。

　　→考核的客体兼顾个人和团队。

进入衰退期，绩效考核一方面需要通过对项目团队的整体绩效作出评估，以考核项目的完成情况；另一方面，也需要对团队成员绩效作出公正科学的总结，这不仅决定成员能否取得公平的报酬，也是其进入另一个团队的基础。

　　→考核的重点主要是个人的综合绩效以及团队的产出。

项目团队任务明确，业绩是团队成立的最终目的，因此在项目团队解散之际，需要对目标的实现情况作一个综合评估，以此判断项目的成功与否。

对个人也需要做一个总体的评价，尤其是产出和能力的评估，组织需要对此进行备案，成为以后的项目团队选择成员的重要根据。

2、测试人员绩效考核

　　考核基于测试过程进行，因此必须在过程结束之后才能进行。

由于工程是分布提交测试的，每月可以根据实际情况进行月考核，工程结束后或任务结束后再统一考核。

按照传统测试周期，测试过程分为：

测试计划、测试设计和测试执行三个方面进行。

测试计划属于测试经理的范畴。

测试人员主要是测试设计和测试执行。

　　测试人员的绩效考核包括多个方面：

　　●工作态度。

包括工作责任心和工作积极性。

　　●工作职责与期望达成度（注意：

在工作安排前需求明确对应测试工程师的工作职责和对测试工程师的期望值，这里的工作职责一般是和管理相关的工作职责内容）。

　　●工作内容考核。

　　→参与软件开发过程的工作内容考核，比如参与需求和设计的评审，就需要对需求的理解上，对需求提出问题的质量上等作出评价。

　　→参与测试文档的准备工作，如测试用例等，需要通过评审测试文档来考核测试人员的能力。

如评审测试用例的质量，对需求的覆盖程度，可理解和执行等方面来判段测试人员的能力。

　　→执行测试的工作，需要从测试人员所发现的问题对测试人员进行评价。

包括发现问题是复杂的还是简单的，是隐藏较深的，还是一些表面的问题。

包括问题的书写上进行评价，问题的书写是否详细清晰，开发人员可以再现，还是含糊其词，不明所以。

一个问题是否写多遍等。

　　→测试结果缺陷残留，对于已经发布的产品，从用户反馈问题考核测试人员的绩效，但是这个可能需要的时间比较长；对于不同版本的测试，可从版本的漏检进行统计。

　　→测试人员的沟通能力考核，包括缺陷在开发工程师中沟通的达成率和拒绝率。

　　●工作效率与工作质量考核。

　　→测试设计中工作效率相关指标：

　　△文档产出率：

这项指标值主要为测试用例文档页数除于编写文档的有效时间获得。

用于考察测试人员测试用例文档的生产率大小。

　　公式：

∑测试用例文档页数（页）/∑编写测试用例文档有效时间（小时）

　　参考指标：

根据项目汇总得出平均在1.14页/小时左右，高于此值为优，低于此值为差。

　　△用例产出率：

这项指标值主要为上述指标值的补充，用于考察测试人员测试用例产出率大小。

测试文档页数可能包含的冗余信息较多，因此要查看文档中测试用例的多少。

方法是测试用例文档中测试用例编号总和数除于编写文档的有效时间。

　　公式：

∑测试用例数（个）/∑编写测试用例文档有效时间（小时）

　　参考指标：

平均4.21个用例/小时

　　●测试设计中工作质量相关指标：

　　→需求覆盖率：

计算测试用例总数之和除于与之一一对应的功能点数之和，主要查看是否有功能点遗漏测试的情况。

　　公式：

∑测试用例数（个）/∑功能点（个）

　　参考指标：

100％。

如果连功能指标都不能满足100％覆盖，起码说明测试不充分。

这个指标收集起来相当困难，如果存在需求跟踪矩阵或者测试管理工具能把用例与需求一一对应就容易得多。

注意：

有的功能是难于测试的，那么未能覆盖到的需求要综合分析，明确是测试人员遗漏？

还是无法测试？

这需要放入问题跟踪表中进行后续跟踪；另外，有的功能点包含的信息较多或者有的用例包含几个功能点，这时只能把重复的功能点或重复用例按一个计，难于区分的要做说明。

　　→文档质量：

测试用例进行评审和同行评审发现的缺陷数，或者将此缺陷数除于文档页数算出比率。

此指标考察测试人员文档编写的质量如何。

　　公式：

∑缺陷数（评审和同行评审）（个）/∑测试用例文档页数（页）

　　参考指标：

由于评审是发现的缺陷数是不固定的，因此，这个指标没有可供参考的数值。

如果缺陷数大小不能直接用于比较就使用缺陷/页方式进行横向对比。

　　→文档有效率：

使用测试用例文档进行测试时发现的系统测试缺陷数除于