在接到项目咨询时,经常会被问到的一个问题是,你用哪些指标衡量质量?或者你的QA团队设置哪些KPI?
首先,metrics和KPI并不相同,metric是对系统、模块或流程所具有的某个特定属性进行测量。Key Performance Indicator KPI顾名思义,关键绩效指标,它在度量的基础上叠加了数字反馈。KPI可以理解为“别人让我做到什么程度”。举个例子,汽车仪表盘上的时速表是一个典型的metric,代表了车辆行驶时的速度变化。每小时的公里数具有可比性、简单明了。仪表盘上的带指示灯的充电表是一个KPI,一旦电量低于阈值会亮黄灯,接近临界值会亮红灯。在电量这个指标的基础上增加量化的反馈,协助司机了解状况和进度,并进行必要的调整。
那么说到如何衡量项目或产品的质量,经过多年的验证和总结,我认为有3个metrics是最实用的。
1. Daily submitted defects vs. daily closed defects
在版本上线前的回归测试或系统测试期间,基本上大家都会去监控bug的数量。但bug数量的多少并不能完全代表该版本质量的高低。由于功能特性的不同,可能存在虽然bug不多,但很难修复的情况。更能给予版本上线信心的,是监控bug变化的趋势。我最推崇的是监控每日bug增加数与每日bug关闭数的对比,并且以蝴蝶图的展现形式最一目了然。
以上图为例,左边是bug的日增变化,右边是bug关闭的每日趋势。走势上能直观感受到问题修复的速度在有序增加,在回归测试中期时已超过新增问题的速度。再搭配遗留bug总数*严重程度,例如此例中总遗留bug数为11,逐个确认问题的严重程度后,就可以比较自信地得出是否达到上线标准的结论了。
2. Number of post-launch defects
版本上线后,回溯版本质量的指标主要由漏测bug数来表示。如何定义漏测bug视具体项目场景而定。以to B产品为例,版本间隔周期较长。如果监控整个周期,将增加许多管理成本。因此推荐监控上线后一周内,生产环境上的bug数量,包括测试人员回归发现或客户投诉后确认的问题。如果是to C项目,例如游戏版本在灰度后即全网发布,测人人员一般不做线上回归,则可以监控版本周期内客户投诉量,包括客服记录和社群记录等。
这里需要注意的是,有些团队会设置把漏测率为质量KPI。
漏测率 = 线上bug / 总bug数
除非版本之间的技术复杂度、功能规模恒定,否则请谨慎使用此比率。因为这个值会受到过多因素干扰而导致抖动过多,比如某个版本的功能点较少,上线后发现1个bug,就可能产生较大的漏侧比率。两个项目的漏测率也不能客观地比较。
3. Testing points per every 100 points of feature delivery
从效能角度考虑,服务单位规模的功能上线需要投入多少测试资源,是从另一个纬度评价质量的指标。项目管理标准化是使用这一指标的前提。以一个基于敏捷的研发团队为例,可以监控每发布100个points的功能点时所需要的测试points是多少。这个数值随版本周期而变化,数值越小代表测试的资源占用越低。这可能是测试策略的优化带来的,也可能是代码效率提升带来的,但总之直观展现了测试效能的趋势。
指标和KPI的作用需要匹配合适的项目场景。以上3个指标非常适用于相对宏观的质量衡量。在具体项目中,也可以搭配必要的KPI。比如在提高测试效能的特定项目中,降低testing pts / 100 pts of feature delivery是最终目的,期间可以加上AT coverage rate作为测试开发团队的KPI。
但总体上,我不提倡设置KPI。能理性看待和处理KPI的团队并不多见。常常key performance indicator变kill people individually..
灵活运用,及时分析才能让指标不浮于“汇报”,从而真正发挥出激励团队、持续优化的作用。