迭代过程中的度量指标&效能提升实践-三笠

阅读量:

背景

9年初进入18年底新成立的业务线,半年后才有了第一个发布。

在漫长的发布周期中,组内的产品和其他成员一直分居两地,产品在上海,其他人在杭州,每天站会全靠zoom,沟通效率并不十分高效。

同时组内也没有PMO,在很长的发布周期内进度上相比其他组是有点吃亏的。

加上本身只有半个测试资源,跨组集成又比较多。

随之而来的一些问题,像是提测质量不高啊,regression bug占比比较高啊,sprint完成度比较低之类,包括还有每个迭代需要check的点非常多,忙着忙着有些点就忘记了(比如灰发的各个节点)。

由于前后端代码变更很频繁,单测一时难以添加,UI、接口自动化也难以维护,那么短时间来说可以解决的问题主要是两个,一个是组内的效率问题,另一个则是迭代部署周期内的测试效能提升问题。

问题一

先说组内的效率问题,无论是每个sprint完成的总任务点数,还是落实到每个人的具体完成点数,包括修复的bug数目,这些其实都是可以在jira里面找到的,但是筛选成本比较大,没有一个很直观的图表。

针对这种情况,我对kerrigan提了相关的需求,增加了几个指标:

  • 被打回任务(story/task)统计
  • 完成任务数(点数)统计
  • regression的bug数目统计

通过以上三个指标以及对应的图表,我们可以比较清晰地看到每个sprint整个团队以及个人的表现,通过这些数据可以帮助提升组内的效率。

问题二

另外来说一下测试效能提升问题,针对那么多的checklist,结合我们在每次发布中做的一些事情,比如说检查一下线下bug数目是否符合质量红线,所有任务是否都已经完成了等等。其实很多事情都可以交给代码来完成。

针对这种情况,经过讨论我们决定做一个checklist机器人。大致原理是往数据库添加定时任务数据,然后起一个定时任务(比如说每5分钟)去扫描数据库里面的任务信息,解析对应的cron表达式,判断当前时间段是否执行,是的话就去执行对应的任务并将结果通过机器人发送到对应群组。

下面是目前设计的一些需求列表

展示一些目前已经完成的功能的截图

前端的接入界面也比较清晰,可以自主设置想要运行的任务以及对应时间点,cron表达式赋予了我们很大的操作空间

小结

在这里需要友情提醒一下,指标不是万金油,各种数据可能可以反映问题,但是大多情况下都无法告诉你具体是哪里出了问题。

有时候会陷入“我如何找到更有效的度量指标”的死胡同,反而忽略了已经反映出有问题的一些指标。

想要深度优化度量指标,一个比较高效的手段是基于现有的指标,去深挖已经暴露的问题,在这个过程中可以去优化现有的指标,甚至是发现更好的指标,可以获得比较高的性价比。


comments powered by Disqus