又是绩效评估时，如何合理的评估测试同学的绩效

这是我最近思考比较多的一个问题，也是很重要的一个问题，因为这关系到大家一年来辛辛苦苦工作的结果。

在我看来，大部分测试同学都是很辛苦的，加班，给开发背锅这些事情都是常态，所以如果没有给大家一个非常客观的年终评定的话，不仅经济收益上会有影响，更有可能打击大家的积极性，从而对团队稳定性造成不好的影响。

绩效评估如果不合理，那么大家可能会有这样的疑惑

• 我明明工作很努力，为什么绩效这么差
• 我觉得我的能力很强，为什么不给我涨薪
• 某某某并不如我啊，为什么绩效比我好

其实测试的绩效比开发同学的绩效要难评估一些。毕竟开发大神大家很容易看得出来，贡献大的绩效好，相对比较容易做比较，但测试同学很多时候技能的区分程度不大，大家其实水平差不多，做的事情也差不多，也都差不多的努力和敬业，尽管很多时候是被动的，但功劳苦劳其实差不多。

如何能够比较好的进行测试同学输出的评价呢？我思考了几个维度，希望可以跟大家讨论一下。

个人能力维度

个人能力包括当前能力及成长。如果个人能力一直没有较大提升，那么可以认为该成员的成长速度可能一般，或者已经达到自己潜力的巅峰了，可以考虑让其承担一些更有挑战的工作之类。

我觉得年终评价的时候我们可能更需要关注成长。主动成长和被动成长从结果上看其实是差不多的，但主动成长的人可能在成长的持续性方面会更好一点。

关于测试同学的能力的评估我之前写过文章描述，这里再列一遍

• 业务能力，理解业务和快速熟悉业务的能力
• 文档能力，有时候写文档也很重要
• 沟通能力，不言而喻
• 和项目组其他成员打成一片的能力：这个是双刃剑，有时候这种能力强推动力强，有时候则会陷入过度的容忍
• 技术能力，这里可以很细，就不展开了

业务输出

从结果导向上看，测试同学的输入是质量控制和保障，只要不出问题，没人想起你，那么你就是成功的，否则，如果你成了团队里最让人惦记的人，那么你的质量可能就没有太高。

这里可以给出一些指标，我觉得最简单粗暴的指标就是线上问题的数量。这个指标比较片面，这是因为

• 可能你在测试过程中发现了太多的问题，但是代码质量实在太差，导致问题一直没有办法根除，从而遗留到了线上，这种情况下，可能测试同学就是线上问题的背锅侠了
• 如果代码质量好的话，那么测试同学在测试过程中可能不需要太费心，最后上线之后如果发现了问题，那就是运气不好，没有出事故的话，其实跟测试同学的努力关系也不是特别的大，这就是命了

既然这个指标问题那么多，那么我为什么还是推荐大家使用这个指标呢？这因为质量管理不一定是疯狂的点来点去，以自己的一己之力去避免缺陷的发生，而是要将项目组所有成员都拉到质量控制的大流程中去。

举个例子，开发的提交质量太烂，那么能不能提升准入门槛，让他们自己多测一会，多思考一些事情再提交呢？能不能让这个锅大家背，而不是测试独自去承担？线上问题追责的时候，能不能谁写的代码谁承担主要责任？没测出来的最多算个从犯，而不算主犯？有锅大家背，如果开发被背锅的恐惧感支配，那么代码质量多少还是有提升的。

所以这个结果我们是可以基本信赖的，哪怕这个指标有争议，但争议的过程引导我们去做的更好。

另外我喜欢让测试同学站在产品的角度去向整个项目团队去讲解需求，假如你是产品经理，那么你应该怎么向我们表述你的需求？每次讲解的时候当场就可以收集到反馈，这就可以看出另一个指标：业务熟悉程度。

让测试同学写系统或产品的使用说明书也能看到大家的业务熟悉程度，有时候写太麻烦了，所以我倾向让他们讲出来，这也能看出业务熟悉程度。

有了上面一些维度之后，我们可能就能大致的评判大家的工作输出了吧。指标其实还有很多，但核心思想大概都是：看测试质量，看人员成长。

最后，这只是我的个人浅见，仅供参考。