摘要:企业管理人员在做绩效考核时,如何对测试团队中成员的测试工作效率予以界定和考评,是个很值得讨论的问题。因为关系到员工的切身利益,所以要做到公平公正,还需要不断的进行探索。
前言:绩效考核和测试人员测试效率两个具体是否需要进行联系?这个是个可以探讨的问题,从员工角度来说,能力强,测试效率高的人是希望纳入绩效考核来证实自己的,但是普通的测试效率稍显低下的人却又不希望纳入考核体系。而且测试人员工作效率本身不是非常好定义和界限。但是从一个公司长远的发展来说,测试团队的能力是需要不断提升的,只有建立了好的绩效考核标准,才能激励员工向好的方向发展,而不至于造成鱼目混珠的现象。在网络上查询了一些资料,引用的同时,也做了一些优缺点分析。当然,评价测试效率只是作为考评的一部分,但是目的不是为了评价一个人的能力如何,而是为了在这种评价体系上不断提高测试人员的测试能力。让测试人员具有责任心的去进行产品的测试。
一、评价准则
网络上比较通用的观点主要从bug的数量、有效性出发,衍生出各种基于不同环境、阶段、条件下的评价准则。这里列举如下:
1. 发现缺陷的质量:
测试人员最终是为了发现bug,且需要是有效的bug,但是有效bug的质量根据bug的严重程度也会有不同等级的分类。所以发现组内大部分成员认可高质量的bug可以作为一种评价方式。
缺点:bug的质量的衡量该如何确定。如果A发现了一个崩溃级别的bug,B发现了一个可用性的bug。但是崩溃级别的bug遇到的概率非常小,而可用性的bug却无时无刻影响着用户。那么不同的人对这两种bug的重要性和质量的认可程度就不一样。
2. 测试的有效性:
如果由于测试人员疏忽错报了bug、自己负责的模块在同一版本中重复报了bug,那么此类bug就应该算作无效的bug。如果无效bug的比例占总bug数(无效+有效)越大,说明测试人员提交的bug有效性越低。当然这里说的疏忽是说明确的疏忽,如果是因为需求文案本身歧义引起的,我们不应该归责与测试人员,不过测试人员有义务在发现这种问题文案时向策划人员确认或者给相关策划人员报bug。
3. 测试组员交叉测试,发现漏测问题数量:
经常是这样,一个测试人员测试结束,修复了全部的缺陷。这个时候,测试的模块和测试人员交叉一下,再测试,很有可能又发现很多问题。这样我们可以对测试发现问题数量,进行统计。这样做,就迫使测试人员认真执行每一轮测试,每次测试都不敢懈怠。
缺点:这种方式对团队协作是否影响?因为指出他人的问题且会影响他人的利益的时候,大多数人会选择不指出问题,也就是所谓的人情。所以在制定这种评价标准的时候,如何能让团队成员大胆的进行测试而又不影响团队成员的关系,就是管理层和流程上需要讨论的问题了。
4. 线上bug数:
产品上线后,如果用户发现的且在测试机器上能重现的bug数越多。就说明产品测试的越不充分。所以某个人负责的某个模块自然而然成为评价这个人测试质量的标准。
缺点:如果在项目流程非常规范,产品发布等都是由QA来决定的话,那么最后遗漏到客户缺陷的比例数据会比较精确有效。但是如果项目时间紧、需求变更频繁、产品重构、变大较大、产品发布不受qa本身控制的话,遗漏到线上的bug自然而然就会增多。那么,在这种情况下,如何来评价这些缺陷。需要有评价体系。且在分模块时,各个模块之间难免有交叉、交互的过程,那么可能介于中间部分的这些功能多少会有遗漏,即使写用例,也不一定能 100%覆盖到。
5. 单位时间报的bug数:
如果在1的约束下,测试员能保证bug有效性且报的bug数越多的话,就表示此人在不断用心的发现bug。
缺点:bug数只能单纯的从一方面来评价一个人。但是实际过程中,每个人测试的前提是不同的,测试类型、分派测试模块的复杂度、新增功能和回归测试等区别,这些因素都在一定程度上限制了人们发现bug数的多少。