开发者社区 > 博文 > 大数据平台Bug Bash大扫除最佳实践
分享
  • 打开微信扫码分享

  • 点击前往QQ分享

  • 点击前往微博分享

  • 点击复制链接

大数据平台Bug Bash大扫除最佳实践

  • pi****
  • 2023-12-28
  • IP归属:北京
  • 190浏览

    一、背景

    随着越来越多的"新人"在日常工作以及大促备战中担当大任,我们发现仅了解自身系统业务已不能满足日常系统开发运维需求。为此,大数据平台部门组织了一次Bug Bash活动,既能提升自己对兄弟产品的理解和使用,又能促使自家产品功能日趋完善。今天来给大家分享一些实际操作过程和经验总结~

    二、什么是Bug Bash?

    Bug Bash,顾名思义就是缺陷大扫除。通常由QA主导发起,团队全员放下手中的活,找个会议室一起集中精力来找缺陷。

    图 1

    三、Bug Bash好处

    1、常规测试的有效补充,更多用户测试发现更多问题或需求。

    有可能发现业务流程上存在不同类型、不同层次的疏漏,整体设计上隐蔽的缺陷,甚至产品规划上暗藏的新需求。不同的人员更容易发现兼容性、权限差异等问题。测试人员也可以根据发现的问题完善自己的测试策略,

    2、提高团队凝聚力,促进团队彼此沟通。

    在增加了一些比赛的元素缺陷大扫除中,比如时不时的播报谁发现的bug多,配上轻松愉悦的音乐,让大家你追我赶的找出bug。这样来推动人员之间的良性竞争,从而鼓舞团队人员的士气,增加团队的凝聚力。

    3、深入产品学习,带来更多附加价值。

    在日常的工作中,产研测更多时间都是在独立的工作,只关注自己负责的部分,很少就产品问题进行集体交流,很少深度使用整个产品。通过bugbash可以让团队其他角色作为用户体验产品,深入了解业务。在对这些问题进行集中讨论,并详细解释如何处理以及为什么这么处理过程中,可以引发更多产品的思考。

    四、Bug Bash组织实践

    图 2

    1、活动准备

    1.1、部门宣贯

    在部门工作咚咚群内通知本次bugbash活动的计划安排(https://joyspace.jd.com/sheets/XXXX),确定活动组织时间、活动会议室、小组划分情况。目前部门内产品主要包括JDQ、JRC、集成平台三大产品,为更有效的进行相互"扫除",我们进行了轮次划分,小组划分。如下表所示:

    轮 次小  组答疑人员时  间地  点备  注
    第1轮JRC vs JDQJRC:段东妮
    JDQ:尹伟
    2023.11.15 18:00红河会议室自由探索人员自行选择产品扫除
    第2轮集成平台 vs JRC+JDQ集成平台:郭卫卫
    JRC:段东妮
    JDQ:尹伟
    2023.11.22 18:00红河会议室自由探索人员自行选择产品扫除

    表 1

    提示:本次bugbash是针对生产环境进行扫除,涉及到流程审批环节时需提前通知对方审批,避免因未审批导致阻塞后面的流程。

    1.2、用例准备&评审

    bugbash正式开始之前,测试人员应提前准备各自负责产品的测试用例,并邀请产品经理、产品主研发一起进行用例评审,划定活动范围。可以参考以下几个方面:

    产品的主流程业务场景。比如创建binlog采集任务、正常消费topic数据等。

    日常运维工作中经常用到的场景。比如消费者暂停消费操作等。

    跨平台联合查询场景。比如通过JDQ消费者username查询关联的JRC的flink任务等。

    隐藏性功能场景。比如正常情况下A功能不会显示,需要打开某个开关才可正常显示等。

    图 3

    1.3、测试数据准备

    根据用例场景、活动参加人数来准备测试数据。主要包括所属平台、测试数据类型、测试jed数据表、测试ck数据表、测试数据说明、使用人如下图所示:

    图 4

    提示:提前给活动参与人员统一添加权限。比如使用指定的项目空间。

    2、活动进行

    活动时间安排:10分钟介绍本活动轮次情况,50分钟任务执行,10分钟交流发言。

    2.1、任务分配

    根据活动轮次、小组划分情况进行任务划分,以JRC vs JDQ为例,JRC的研发等相关人员执行JDQ的任务,反之,JDQ的研发相关人员执行JRC的任务。

    2.2、测试数据分配

    为避免使用相同测试数据导致任务创建冲突等情况,双方人员需对测试数据进行标记认领。如上图4 使用人列。

    2.3、问题记录

    双方人员在大扫除过程中发现问题及时记录到joyspace中,不需要现场讨论产品细节,标明测试验证人、测试时间、结果填写、测试验证结果。将来可以根据问题的价值与重要程度给予不同奖励。如上图3 所示

    2.4、现场答疑

    产品主测试人员为活动答疑人员,双方人员可能存在以下场景需要现场支持:

    任务创建成功了,需要XXX审批,答疑人员跟进审批操作。

    对产品功能不了解,对用例场景描述不太理解,需要指导。

    3、活动结束

    3.1、问题收集

    对发现的所有问题进行合并去重、分类汇总。包括问题编号、问题所属产品、执行的任务编号、问题缺陷描述、截图或错误日志、记录人(任务执行人),问题分类。问题处理。和产品主研发、产品经理一起组会评审问题优先级、是否改进、改进方案、改进负责人、改进预计完成时间、改进状态等。

    图 5

    3.2、问题复盘

    本次bugbash活动共发现问题 40个,其中功能性bug 2个,确定需要改进的有30个,以前端优化为主。

    测试人员根据发现的问题完善产品用例,进一步提高产品质量。

    4、活动总结

    4.1、参与用户心声

    提供了学习其他产品的机会

    了解别的产品都是做什么的,以及怎么用的,交叉体验更符合用户的身份,发现更多问题。在大家都很忙的时候,能抽出这么长的时间不容易。

    提供了测试场景,避免盲目测试

    活动中选取的测试场景主要都是日常工作中遇到,测试人员将操作步骤描述的很清楚,方便大扫除的人员进行执行。

    4.2、待改进的地方

    关键节点审批阻塞

    由于流程环节审批人因各种原因(临时开会、临时请假等)不到场,导致流程审批阻塞,任务无法向下执行。后续可在审批环节增加backup人员。

    时间紧,有的任务执行不完

    由于整个活动只有一个小时时间,非业务相关人员理解业务知识需要一定的时间。后续可适当延长活动时间并精简任务场景,比如可以分专题开展活动,类似产品界面易用性、安全性、国际化等等。

    激励机制待提升

    本次活动缺少一些物质(比如小礼物:酸奶、巧克力等)或精神(徽章、T恤)奖励,大家参与的积极性有待提升。建议引入游戏竞争机制,可以增加趣味性,调动积极性,真正做到真正寓工作于娱乐。


    五、思考

    Bug Bash平台化

    本次bugbash大扫除活动主要还是线下组织+共享文档形式为主,如果能建设拥有一个平台可以随时随地的组织bugbash,自由选择产品业务场景,灵活多变的任务下发就会更高效。

    Bug Bash范围扩大化

    不是只让产研测内部团队成员参与Bug Bash,也可以邀请用户参与,参与的人越多,越容易发现问题。


    最后附一张现场活动图片~

    文章数
    2
    阅读量
    263