闲谈中的绩效考评，About Tester

今天中午，未膳，和一个Service闲聊，东拉西扯谈到测试人员的绩效考评上来了。

通过对方之口，侧窥了她们原公司中测试人员的绩效考评：Tester发现Bug的数量就是绩效的量化指标。

Hum......这和Boss的想法完全一样，FT，偶却难以苟同。 以Bug作为Tester工作的评估导向，就是片面的、不合理的，越是Simple的做法越有可能是错误的做法，same as 地心说vs日心说。

说说我对Tester绩效评估的想法：

 

1. 跟着质量走
   作为测试，无论设计多么完美的测试方案，无论补充多么容易复用的Test Case，无论抓住多少的Bug，产品的质量不好，这一切都是空谈，至少缺乏说服力。一个模块自然会有相关的Tester与其对应，模块的质量好，自然是与其的努力是不可分割的。
2. 整体优于局部
   一个模块的良好运行，也不能代表整个产品的稳定。从大局出发，着眼整个产品的质量保证，而非一城一池的得失。有点儿像那种红色的标语：厂兴我荣，厂衰我耻。
3. 测试过程的度量
   从Test Plan -- Test Scheme -- Test Case -- Bug -- Test Report 的数量、质量来汇总统计整个过程的开展绩效，单独评估其中一项，都是不全面的。

 

这样下来权重大致如此：

• 负责模块的质量(40%)
• 整个产品的质量(30%)
• 测试过程的质量(30%)

 

呵呵，末了提一句，绩效考评必须和完善的激励制度挂钩，否则就是浪费时间。