管理学大师德鲁克曾说过“如果你无法衡量它,就无法管理它(If you can’t measure it, you can’t manage it)”。可见,要想有效管理某事务,就需要将它全面且有效地度量起来,而要想针对某个方面进行改进,就需要有针对性地运营。
质量度量体系
大家都知道作为测试的主要任务是质量保障,保障线上环境没有故障和缺陷,最终交付给真实用户的质量,即交付质量。那么,质量度量是不是只关注交付质量指标就足够了呢?答案显然是否定的。因为如果只关注交付质量,往往达不到提升交付质量的目的。比如,你每天关注线上交付质量,忙着一个又一个的项目,一段时间过后,发现线上环境的故障数和缺陷数未见减少,这时候你甚至不知道根因出在哪里,应该如何改进,现有的工作哪些要继续保持哪些要放弃,等等。
这是因为交付质量是滞后性指标,当你知道它时,它已经发生了。要想避免此类情况,还需要多关注并改善引领性指标。我们还要关注一个(引领性指标)。
滞后性指标:顾名思义,就是事情已经发生之后产生的数据。
引领性指标:与滞后性指标相反,是一个前置指标。
滞后性指标,线上的交付质量
引领性指标,交付过程中的过程质量
一、对于线上的交付质量,可以通过以下维度进行度量
从上述指标不难看出,保障交付质量是要努力减少线上故障和线上缺陷,降低故障级别。但是线上故障又是不可避免,那么就需要最大限度地降低线上故障的影响,比如降低线上故障的恢复时长,减少对生产环境真实用户的影响。
二、交付过程中的质量度量
1、首先在需求阶段,可以通过以下维度进行度量
一般来说,需求质量 Bug 数应该占总 Bug 数的 5% 左右。需求评审打回的标准可以是发现 5 个逻辑类的问题。需求评审打回、需求变更、需求插入等情况,对软件过程的健康度和质量有较大危害,建议制定相对严苛的流程规范,并结合质量运营手段来应对此类情况,以减少此类情况发生。比如需求评审不通过时,需求文档的作者需要向相关人员发送重新评审的申请邮件,并针对当次打回情况做改进分析。
2、其次在开发阶段,可以通过以下维度进行度量
一般情况下,提测质量等于 1 才符合预期,即 15/15、12/12 等,因为只要有 1 条冒烟用例执行不通过,则可以进行提测打回。
3、在测试阶段,可以通过以下维度进行度量
4、在发布阶段,可以通过以下维度进行度量
通常情况下,构建失败率和发布回滚率应该控制在 1% 以内,所以每一次发布失败和发布回滚都值得深入分析。非发布时间发布,很容易造成线上故障,且由于处于业务高峰时段,出现故障时容易出现“雪崩效应”,造成的业务影响难以估量,因而应予以杜绝非发布时间发布线上服务。
三、质量度量的认知
质量度量是质量现状的镜子,要想改变现状,首先要接受现状。
追求单一或局部指标的提升比较容易,但很容易产生扭曲行为,构建指标体系并整体提升才是正确的路。比如,要想降低千行代码 Bug 率,可以在不增加 Bug 数量的前提下,有意稀释代码,这样该指标肯定能降低,但没有任何意义,自欺欺人罢了。
度量指标的确定,要与相关方达成共识,自上而下认可它们。质量不是测试团队自己的事情,需要产品研发相关方共同的努力。如果制定了一个度量指标,需要相关方提升它,但相关方并不认可它,就容易产生太多无效沟通和扯皮。
下一个重点,质量运营
质量运营的目的是质量改进,质量度量是其着陆点,因为形成了多维度的质量度量体系,所以当出现质量痛点或质量隐患时,可以比较容易在度量指标上得以体现。质量运营是基于质量痛点进行分析,找到可能的解决方案,制定规划并推进,对其进行阶段性地复盘和改进。
通过 PDCA 四个方面对质量运营展开说明。
1、P(Plan):制定改进计划
质量改进计划的制定是质量改进过程的第一步,也是最为关键的一步,可以从如下改进思路制定计划。
通常来说,初创业务或成长期业务下,业务变化快,质量保障建设薄弱,质量痛点问题多,质量目标难以确定,这时候以质量痛点驱动为主。随着业务逐渐成熟和稳定,质量在业务中的重要性更为凸显,对质量目标的要求越来越高,这时候以质量目标驱动为主,质量痛点驱动为辅。
2、D(Do):实施落地计划
无论采取怎样的质量改进思路,质量运营都是一个持续运转和迭代的过程,运营周期不同,目的和关注点也有较多不同,具体如下:
数据收集和聚合
有了质量度量体系,还需要针对这些指标所对应的数据进行收集和聚合,这就需要在产品研发过程的关键环节进行”埋点“,对关键过程数据和结果数据进行存储。因此,建议利用成熟的项目过程管理工具,如 Jira、TAPD 等。随着度量指标的丰富,可能还需要进行二次开发或者自建平台。
3、C(Check):复盘和反馈
复盘是质量运营中非常关键的环节,它起到了承前启后的作用。它的最佳场所,常常体现在各种书面总结报告或复盘总结会议上,能够起到最大程度的效果触达,同时提升相关团队的质量意识和认知。
4、A(Action):改进和推广
基于前面的步骤,可以知道质量运营计划和改善策略是否有效,如果有效,则进行推广,反哺到日常研发过程中,尽量形成平台能力或可落地的规范。
比如,经过一段时间的质量度量与运营后,当各团队的 Bug 工时比都小于 0.6,那么可以和相关方团队达成共识,将标准提高到 0.4。而如果改善未达预期或完全无效,则可进一步分析原因,从而优化或改进落地计划。
5、 质量运营实践认知
很多测试团队所做的质量运营都止步于通晒数据,但是质量运营最重要的是要基于数据进行分析,帮助相关方做改进,同时跟进反馈改进的效果。做改进是主要。
质量运营需要推动多个团队配合,应“先礼后兵”,不可轻易用向上管理的激进方式。首先,采用向上管理的方式容易使团队间产生对立情绪,影响日常协作。其次,没有哪个团队不重视质量,只是有时候它们在质量改进方面并不是足够专业,这时候反而是测试人员扮演老师和教练角色的时候,带领他们一起做分析、改进和提升。
获取完整版思维导图,请关注公众号【测试开发加油站】,回复:质量度量与运营