编写背景：
工作所在的部门启用了新的绩效考核制度，也开始了我参与对测试人员的工作进行绩效考核这一管理活动，第一次的考核结果让我有很多的感想，因此今天把它记录下来，也许突然有一天回头看这一感想，又会是另外一份心情。
思考：给测试人员进行绩效考核的目的是什么？
经过思考，我总结的答案是：
1、为了了解工作情况，如：工作进度、工作状态。
2、对每个人的工作进行评比，夸奖好的，批评差的。这个看起来有点像在学校上学时候的考试。
思考：有了这样的绩效考核目的，要用什么样的方式、方法去实现呢？
怎么样的绩效考核方式是最有效的呢？
对于现在的我，在现在这个小公司要想做好这个绩效考核，真是要好好思考。
1、不同的工种，不能用同一种考核方式。如：测试人员的考核方式就不能和开发人员的考核方式相同。
2、不同工种的考核结果是没有可比性的。如：测试人员的考核结果和开发人员的考核结果进行对比是没有意义的。
以上这两点不知道我的领导是否认同，还需要等到下一次考核的时候和他沟通沟通。
这是工作以来，第一次站在一个管理角色去思考、去做绩效考核这个工作。这第一次的考核工作让我不知道用什么语言来描述我的感受。
考核的结果是：测试组整体的分数都比开发的低，从排名和等级划分上可以说是包尾了。从分数上看，我的第一感觉是：难受。第二感觉是：生气。在和领导进行一系列沟通后，在回家的路上一直在思考、分析着这个结果，问题出在那里呢？问题出在那里呢？？？？？冷静的思考后，自己安慰自己，原因应该是这些吧：
1、这次开发人员和测试人员使用的工作考核方式是同一种考核方式。
2、这次把开发人员的考核分数拿来和测试人员的进行排名对比。
很显然，一直这样下去，测试人员的工作即使在怎么努力、分数超过开发人员的机率会很低很低，这样的对比规则，对测试人员来说，很不公平。这样的对比规则，很没有意义。更让我郁闷的是，面对这样的现象，我想不到很好的解决方法，目前只能鼓励测试人员加强自己的综合能力，自己给自己争气，对我来说，在测试人员的管理工作上，无形中出现了一个困难，只能是乐观面对了。
唉，工作种类不一样，放在一起作对比，永远说不清。
测试人员的工作，开发能作么？开发人员能写好测试需求、测试计划、测试用例、测试分析报告文档么，先不说写好，先说会写么？开发人员知道怎么样去执行测试么？知道发现 bug 应该怎么有效正确的去描述么？怎么快速有效的发现程序的问题么？能把握好整个软件测试的质量和进度么？测试，说的简单，真正做好没有这么简单。就拿黑盒测试举例，测试项有：业务流程测试、功能测试、安全性测试、性能测试、数据测试、用户友好性测试、配测试、兼容性测试。这些测试项所使用的测试方法、测试点，都能想全了、想到重点了么，想到了还只是第一步，真正要去执行测试的时候，测试环境的搭建、测试用例的编写与执行、 bug 的描述以及错误等级的正确划分、 bug 的回归、用测试工具进行测试，对测试工具正确有效使用的把握，这些对开发人员来说，会做么，能做好么？测试工作也有很大的工作压力，面对一个不熟悉的软件，面对一个什么说明文档都没有的大软件，要在最短的时间内，最有效的完成测试，要保证产品在发布后，不出现严重的问题，想尽一切办法的发现严重问题。这种对软件质量上的责任压力是很重的，还有其它我就不举例了。
开发人员的工作，测试能作么？测试能看懂开发人员的代码么？测试能写代码测试开发人员的程序么？测试能明白理解开发人员是怎么开发的么？测试能明白开发人员所说的工作术语么？测试能看明白开发人员的开发成果么？开发人员的工作也有很大的压力，要在最短的时间内编写出质量高的代码，实现功能，还要进行一遍又一遍的调试，需求一变，又要修改代码，自测时，发现问题，要进行调试找原因和解决方法，容易么？不容易。测试人员发现的问题，还要去找原因要想最好的解决方法。容易么？不容易。
我很同情那些把测试和开发放在一起作对比行为的人，因为他们对这两个工作中的其中之一理解有所欠缺从而导致这样的结果。说了那么多，好像扯远了。
最后，我得出这么个结论：这样的绩效考核方式，对测试人员来说，起不到激励作用。如果碰到不能正确心态去理解的测试人员，反而会起反作用，很打击工作积极性。因此领导在问我意见的时候，在不适合的说话时间、说话场合我只能说“无所谓”，心不甘情不愿的无所谓！！！！！！！！！！！！！！
====================================分割线================================
最新内容请见作者的GitHub页：http://qaseven.github.io/
