如何考核软件测试人员？

考核，百度百科解释为“考定核查”，语出《颜氏家训·省事》“有一礼官，耻为此让，苦欲留连，强加考覈。”

我经历过的公司对软件测试人员的考核大概有 Bug 数（按严重级别换算个数）、三观中的价值观、文档质量、分享（比如培训）、合理化建议、标准流程的执行，任务按时完成、任务 repen 率等等，基本上是一家公司有一套基本不能重复利用的方法和体系。

先来看几个常见考核指标：
1、以 Bug 数来考核
这和以代码行数来考核开发是一样的，原本可以一个 Bug 单就可以搞定的，会被分成 N 个 Bug 单；原本不是问题的功能/逻辑也会成为 Bug；原本应该被识别为风险的新人会变得异常受欢迎（TA 会带来更多的 Bug）；原本 bug 应该趋于收敛的项目，却 Bug 数迟迟降不下来；微小/细微的页面问题占据了缺陷管理系统......
自古以来都是上有政策下有对策，玩数字游戏，人人都是高手。

2、Bug 数不行，那考核有效 Bug 率呢？
别以为是柳暗花明了，其实一样。为了不让 Bug 被认定为无效，测试人员可能会无休止的与开发、产品纠缠，大量时间花在“Bug 是否是有效”的问题上去，或者提每一个 Bug 前，都先和开发确定一遍，过多占用开发人员的时间。

3、过分强调企业文化
我曾经呆过一家公司，讲求老板文化，十分在意三观（价值观、人生观、世界观）（其实就是老板的个人意愿），用人不管能力高低，98% 以上程度看三观。结果就可想而知了。（所以啊，应聘前，做背调可不是公司才应有的权力的，候选者也要对公司做足背调）。

4、考核员工的综合能力
这是虚的，因为这是可以拆分的，比如沟通能力、技术水平、学习能力、分享度等等，每项可以单独做为一个指标来打分，当然是主观评判。而当“综合能力”作为一个指标时，往往是人情打分了，是用来拉平均的指标了。

产品的质量一般不是某一个测试人员的工作成果，往往是一个团队（产品、开发、测试），因为质量是构建的，不是测试测出来的。如果非得要考核，应该考核到测试团队，比如：
1、如果要考核 Bug，那就考核生产环境 Bug。生产环境 Bug 的考核也不能论数量，论影响时长，因为影响时长基本上看开发修复的时长，论数量的话同样，每个人看问题的方向都不一样，一个 UI 都可以被不同的人试为 bug。
那怎么考核？按严重等级，严重等级可以根据问题的影响程度，影响用户数，修复时长等综合评定，假设四个等级，最多也就到最高级别 Bloker，这样每个生产环境问题都有一个等级，为每个等级设置一个适当的权重。每个版本都能得出一个具体的分值。

在一个周期内（半年？一年？）这个产品所有发布的版本都会有一个这样的分值，做成趋势图，很容易看到团队的进步或者需要持续提升。

这样的考核又可以转换为一个目标，即降低生产环境 Bug 数，为了完成这个目标，测试团队会采取多个行动，比如分析生产环境问题，找出漏测的原因，增加用例或者增加测试风险点等等。

2、考核测试效率
我们常用轮次来进行测试，每个轮次的重点不一样，为了保证上一轮次不影响下一轮次的进度，我们可以引入计划偏离度，为了不使计划延期，那在执行测试时就会注意效率，在规定的时间内完成测试计划。

如何一定要考核到个人呢？

考核到个人，那基本上就意味着调薪和年终绩效了。在公司管理者的视角里也有这些问题：

• 如何决定给员工涨多少薪水？
• 如何决定谁应该升职？
• 如何决定谁应该被解雇？

抛开所有考核，做为员工的直接主管，是一定知道每个成员的工作做得如何，心里是有一杆称的。（这是称，不是天平，是用来称重量的，不是用来做公平的）。管理者应该到具体项目参与具体的测试工作，与员工建立基本的信任，同时也更好的观察员工的表现，及时的提出改进建议，同时建立一对一沟通机制，听取队员的真实想法，获取建议，也能够及时调整自己的想法和行为。

当这一切都很自然时，管理者打出来的分也就更加真实的反应员工的表现，也不至于解聘一名员工非得到 performance review 时。

给员工打分可以从这几方面：

• 学习能力，上个考核期能做什么事情，这个考核期又增加了哪些事情/能力？ 学习能力强的人，工作能力一定不会差
• 分享，是否愿意把自己的知识分享给团队甚至是公司以外的社会活动？团队里有喜欢分享的人，团队的学习氛围一定不会差
• 协助，一方有问题，八方来帮忙，协助即是施助方，也一定会是受益方。团队成员间相互帮助，项目风险一定越来越小

那对于员工本人呢？

坚持本心，别人打的分不会代表你整个人，也没有人能够完整的评价你本人。考核是一个短期的评价，而人生则是长时间的修炼。就算被考核否定了，也只能说自己与环境的匹配度还不够。
Google 有一个可以用来强大内心的名言：做正确的事情，等着被开除。

最后，
上面写了很多，其实都是错的。