Bug数能否作为评定绩效的依据

部门创建之初，曾经有一个阶段是用bug数来评定绩效，但很快就造成了部门混乱，于是不了了之。不久前，部门领导开会，讨论绩效如何评定的问题，又提出了bug的数量这个问题。当然大家一致反对，所以又搁浅了。

     所以我一直都认为bug数是不能作为评定依据的，原因如下：

1.                    每个人所测模块不同：不同的模块因为功能复杂度，开发人员的水平不同，质量肯定会不同。功能复杂度越高，开发人员的水平越差，当然存在的bug越多，或者说bug就越容易找。

2.                    相同的模块版本不同：为了防止长时间测试一个模块，产生惯性，也为了改变测试思路，所以工程师在几个版本过后都要轮换所测模块。但是即使是相同模块的两个工程师，也无法用一个模块的bug数来评定。因为所测版本不同，越往后bug肯定会越少。

3.                    造成测试秩序混乱，不利于良好的测试环境的建立：以bug数作为评定标准，很有可能会出现大家抢bug的现象。比如，版本初期还处于bug确认阶段时，就有人为了多找bug，不去验证问题，而是先于其他工程师开始测试；有人会将测试时间花在bug多的模块上,而忽略了自己的本职工作；或者发现了别人所测模块的bug，却不告之，最后耽误的是整个项目的进程。当然如果工程师的有足够高的素质，可能会避免这些问题，但是我认为以目前的情况来看，工程师还不具备这个的素质，更何况这个是与绩效挂钩，与钱挂钩。

但是就在几天前，我去了一个猎头公司面试，他们是给一个知名的外企做项目的。在教授一些面试常识，或者说注意事项的时候，他们提出了一个问题：在面试时，如果问你，你的bug数在单位是不是第一，或者是第几的时候，要怎么回答？要回答自己的bug比较靠前，并要能够证明…

于是我糊涂了，难道bug数量，真的能够证明一个测试工程师的能力吗？如果能够证明，为什么？如果不能，那又该用什么去评定测试工程师的能力和工作态度呢？还请各位大侠们指点。