测试团队的绩效考核

       目前很多软件公司，即使有绩效考核机制，由于内容比较粗（例如，开发与测试用一个绩效考核机制），不同岗位很难评价到位。
        其实，做好员工的绩效考核，不仅是对员工的客观评价，而且还能起很好的总结作用：让员工清晰自己哪方面做得好，哪方面需要改进，更好地进行接下来的工作。  
        在公司没有提供有效的绩效考核机制，或则根本没有绩效考核机制的情况下，制定符合测试人员的绩效考核机制，是比较必要的。由于测试人员与开发人员的工作内容不一致，测试人员必须按照测试人员的特性进行设置。  
        参考了网上的一些经验，初定以下绩效考核机制：  
1 ．   测试计划

不合格	合格	优秀
1，        没有按时完成；  2，        没有按照测试计划规范标准编写；  3，        描述不清晰；  4，        描述有误	1，        按时完成；  2，        按照测试计划规范标准编写；  3，        描述基本清晰；  4，        描述基本无误；  5，        测试过程中，能及时更新测试计划	1，        基于‘合格’之上； 2，        描述清晰，内容正确；  3，        测试能完全按照测试计划，顺利进行

2 ．测试用例设计

不合格	合格	优秀
1，        没有按时完成；  2，        没有按照用例规范标准编写；  3，        没有按照 SRS 设计用例；  4，        有遗漏；  5，        用例评审，用例描述不够清晰 / 有误，需要修改的用例率 >5%	1，        按时完成；  2，        按照用例规范标准编写； 3，        基本按照 SRS 设计用例；  4，        没有遗漏；  5，        用例评审，用例描述比较清晰，需要修改的用例率 <5%	1，        基于‘合格’之上；  2，        用例评审，没有需要修改的用例；  3，        对一些比较特殊的测试用例总结，及时进行分享，有效提高测试人员的测试用例设计能力

3 ．测试用例评审

不合格	合格	优秀
1，        没有按时完成；  2，        没找到没有按照用例规范标准编写；  3，        没找到没有按照 SRS 设计用例；  4，        没找到测试用例有遗漏；  5，        用例描述不够清晰 / 有误，没发现的占 >5%	1，        按时完成；  2，        全部找到没有按照用例规范标准编写的地方；  3，        全部找到没有按照 SRS 思路设计用例；  4，        全部找到测试用例的遗漏；  5，        用例描述不够清晰 / 有误，没发现的占 <5%	1，        基于‘合格’之上；  2，        用例描述不够清晰 / 有误，全部找到；  3，        总结测试用例写得好与不好的地方，及时分享，有效提高测试人员的测试用例设计能力

4 ．测试过程

不合格	合格	优秀
1，        没有按时完成测试；  2，        没有按照测试用例一步一步进行测试；  3，        严重的缺陷没有找到；  4，        没有及时提交发现的缺陷；  5，        缺陷描述不清晰 / 不正确；  6，        没有配合开发进行缺陷修复；  7，        无效的缺陷率 >5% ；  8，        重复的缺陷率 >5%	1，        按时完成测试；  2，        按照测试用例一步一步进行测试；  3，        及时提交发现的缺陷；  4，        缺陷描述基本清晰 / 基本正确，开发人员经过少量询问后能基本定位缺陷；  5，        基本配合开发进行缺陷修复；  6，        无效的缺陷率 <5% ；  7，        重复的缺陷率 <5%	1，        基于‘合格’之上；  2，        描述清晰 / 正确，开发人员无须经过询问定位缺陷；  3，        主动配合开发进行缺陷修复；  4，        没有无效的缺陷；  5，        没有重复的缺陷；  6，        测试结束后，能总结及时进行分享，有效提高测试人员的测试能力

5 ．测试报告

不合格	合格	优秀
1，        没有按时完成；  2，        没有按照实际情况编写；  3，        内容描述不清晰 / 准确	1，        按时完成；  2，        基本按照实际情况编写；  3，        内容描述基本清晰 / 准确	1，        基于‘合格’之上；  2，        内容描述清晰 / 准确，有效协助开发分析所发现的问题