PS：本文首发于公众号「软件测试艺术」，回复“软件测试教程”获取：麦子学院、传智播客、小强软件测试全套学习教程！
如果测试部门或小组以提Bug的多少来作为绩效考核，你会觉得合理吗？你是否思考过这个问题？今天我就来谈谈这种方式是否合理的原因以及思考。类似于还有以写用例数量的多少作为考核目标的，我们试想一下，用例写的再多Bug发现不了不仅浪费了测试人力，同时也增加了测试风险。
虽然Bug的数量也是衡量测试人员绩效方式的一种，但是这种单纯的以Bug数量作为测试人员的绩效考核方式在我看来不太合理。该方式可能会产生许多无效的Bug，增加测试和开发的沟通时间。如果作为测试领导或测试负责人我们应该避免使用该方式作为考核标准，以下是我认为不合理的几种原因：
1、测试模块安排不合理
如果安排测试稳定的模块不管是根据用例还是自由测试找到Bug的难度非常大，导致测试人员的Bug数量上不去，而测试新功能模块则存在的问题比较多，测试该模块的测试人员能找到Bug的难度就相对来说比较容易，Bug数量自然就上去了；
稳定的模块就是经过几轮测试之后修改合入较少的模块，如第一轮测试出来的Bug数量肯定多于第二轮测试，第二轮测试阶段的测试人员发现的Bug数量大概率比不上在第一轮测试过程中发现Bug的数量。类似于维护项目的回归测试基本很少有Bug了，任凭你投入的人力和时间再多，也很难发现Bug。因此模块的稳定性、模块的复杂度决定了测试人员找Bug的难度。
2、Bug的严重程度
找出测试对象的一般等级的Bug相对容易，而找出测试对象中严重等级的Bug可就困难多了，不仅需要测试人员对被测试对象功能和业务熟悉，还需要测试人员有丰富的测试经验。一个致命和严重的Bug的价值远远大于一般Bug的价值，如果仅凭Bug数量的多少而不考虑Bug的严重程度根本无法衡量测试人员的能力，因此单一的Bug数量作为考量有失偏颇。
3、测试人员能力
上一个原因也有讲到是经验丰富的测试人员远比新来的测试人员更容易找出系统的缺陷，毕竟功能业务的熟悉程度和测试经验在那里，如果所有的人都是同一种考核方式会降低新人员的积极性、主动性，也无法调起新员工的工作热情。
4、测试产品的受众程度
一个市场上非常流行的产品会得到高度重视，会经过充分的测试之后才能上线，而一个小众的产品则不会有这么高的待遇，不仅测试场景少，同时测试人力和资源也分配比较少，对一般的Bug容忍度更高，能保证基本功能使用就可以。如果测试人员分布在不同的产品线中，那找出的Bug绝对不是一个等级的，因此如果以Bug数量作为考核肯定是不合理的。
最后的思考：
1、给Bug分配系数，如发现致命Bug是10分、严重Bug是3分、一般Bug是1分、轻微Bug的0.1分，然后根据Bug的数量乘以相应的系数获取总分，这种更能体现发现Bug的价值和激发测试人员的积极性。
2、如果每次开发提测的版本太烂，我们不应该沾沾自喜提高了Bug的数量，而应该思考怎么管控版本发布，提高待测版本的质量。而不是拿到版本就直接开测，首先可以做一个冒烟测试，没有严重问题后在开始安排测试，否则版本打回等待新版本，此时可以考虑建立测试准入流程。虽然这样最后提交的Bug数量少了，但是优化了测试流程，提高了测试效率，是一个测试人员更应该关注的。
测试人员的能力主要体现在找出系统存在的潜在Bug，上线后无漏测；也可以是测试流程的优化和测试标准的建立，提高测试测试质量和测试效率；还可以是总结历史测试问题，避免在新项目中再次发生。这些都是测试人员能力的体现。
总之作为一个测试人员，我们的眼光不能仅仅停留在测试就是找Bug，测试有更多的事情等待我们探索和发掘。
网友评论