概述
观点1： 单纯以bug数量来衡量KPI是不可取的
测试人员希望开发团队来一个水平差的。写出足够多的问题来让测试提升bug数量。哈哈
观点2：以结果愿景为导向，在定义过程数据，最后看结果数据。
如果我们单纯的拿人日，测试用例数量等等来衡量，那么很容让测试人员想方设法来糊弄。举个例子，你能用代码行数来评判开发人员的KPI吗。显然是可笑的。
评估测试团队KPI维度应该是一个简单直观的可度量且可以细分的东东。
质量维度： 重要bug出现的数量。线上bug数量。 bug遗漏比率（和现有bug比较），用例覆盖率
效率维度：自动化程度，测试成本，周期，测试提前度。
团队维度：管理，学习，成长
观点3：需要数据，但不迷信数据
我们需要在一定的数据指导下来评判当前测试的质量。比如覆盖率，bug修复比率，bug走势等等。 但是如果只是以数据作为唯一标准，就错了。要和团队的环境，行业匹配。
观点4： 培养好的团队氛围和团队成员认可度。
人人为了产品
观点5：考核方面
需求覆盖率，不错。 用例执行率，可以。 用例有效率。 线上bug数目。
需要数量，但要合理的设计数量标准。比如bug等级。优先级别和严重级别。 需求覆盖率，核心component的全覆盖。
最后
以上就是妩媚草丛为你收集整理的在谈测试团队的考核的全部内容，希望文章能够帮你解决在谈测试团队的考核所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。
本图文内容来源于网友提供，作为学习参考使用，或来自网络收集整理，版权属于原作者所有。
发表评论 取消回复