在谈测试团队的考核

观点1： 单纯以bug数量来衡量KPI是不可取的

测试人员希望开发团队来一个水平差的。写出足够多的问题来让测试提升bug数量。哈哈

 

观点2：以结果愿景为导向，在定义过程数据，最后看结果数据。

如果我们单纯的拿人日，测试用例数量等等来衡量，那么很容让测试人员想方设法来糊弄。举个例子，你能用代码行数来评判开发人员的KPI吗。显然是可笑的。

评估测试团队KPI维度应该是一个简单直观的可度量且可以细分的东东。

质量维度： 重要bug出现的数量。线上bug数量。 bug遗漏比率（和现有bug比较），用例覆盖率

效率维度：自动化程度，测试成本，周期，测试提前度。

团队维度：管理，学习，成长

 

观点3：需要数据，但不迷信数据

我们需要在一定的数据指导下来评判当前测试的质量。比如覆盖率，bug修复比率，bug走势等等。 但是如果只是以数据作为唯一标准，就错了。要和团队的环境，行业匹配。

 

观点4： 培养好的团队氛围和团队成员认可度。

人人为了产品

 

观点5：考核方面

需求覆盖率，不错。 用例执行率，可以。 用例有效率。 线上bug数目。

 

需要数量，但要合理的设计数量标准。比如bug等级。优先级别和严重级别。 需求覆盖率，核心component的全覆盖。