随着越来越多的"新人"在日常工作以及大促备战中担当大任，我们发现仅了解自身系统业务已不能满足日常系统开发运维需求。为此，大数据平台部门组织了一次Bug Bash活动，既能提升自己对兄弟产品的理解和使用，又能促使自家产品功能日趋完善。今天来给大家分享一些实际操作过程和经验总结~
Bug Bash，顾名思义就是缺陷大扫除。通常由 QA 主导发起，团队全员放下手中的活，找个会议室一起集中精力来找缺陷。
图 1
1、常规测试的有效补充，更多用户测试发现更多问题或需求。
有可能发现业务流程上存在不同类型、不同层次的疏漏，整体设计上隐蔽的缺陷，甚至产品规划上暗藏的新需求。不同的人员更容易发现兼容性、权限差异等问题。测试人员也可以根据发现的问题完善自己的测试策略，
2、提高团队凝聚力，促进团队彼此沟通。
在增加了一些比赛的元素缺陷大扫除中，比如时不时的播报谁发现的 bug 多，配上轻松愉悦的音乐，让大家你追我赶的找出 bug。这样来推动人员之间的良性竞争，从而鼓舞团队人员的士气，增加团队的凝聚力。
3、深入产品学习，带来更多附加价值。
在日常的工作中，产研测更多时间都是在独立的工作，只关注自己负责的部分，很少就产品问题进行集体交流，很少深度使用整个产品。通过 bugbash 可以让团队其他角色作为用户体验产品，深入了解业务。在对这些问题进行集中讨论，并详细解释如何处理以及为什么这么处理过程中，可以引发更多产品的思考。
图 2
在部门工作咚咚群内通知本次 bugbash 活动的计划安排（https://joyspace.jd.com/sheets/XXXX），确定活动组织时间、活动会议室、小组划分情况。目前部门内产品主要包括 JDQ、JRC、集成平台三大产品，为更有效的进行相互"扫除"，我们进行了轮次划分，小组划分。如下表所示：
| 轮 次 | 小 组 | 答疑人员 | 时 间 | 地 点 | 备 注 |
|---|---|---|---|---|---|
| 第 1 轮 | JRC vs JDQ | JRC：段东妮 JDQ：尹伟 | 2023.11.15 18:00 | 红河会议室 | 自由探索人员自行选择产品扫除 |
| 第 2 轮 | 集成平台 vs JRC+JDQ | 集成平台：郭卫卫 JRC：段东妮 JDQ：尹伟 | 2023.11.22 18:00 | 红河会议室 | 自由探索人员自行选择产品扫除 |
表 1
提示：本次 bugbash 是针对生产环境进行扫除，涉及到流程审批环节时需提前通知对方审批，避免因未审批导致阻塞后面的流程。
bugbash 正式开始之前，测试人员应提前准备各自负责产品的测试用例，并邀请产品经理、产品主研发一起进行用例评审，划定活动范围。可以参考以下几个方面：
产品的主流程业务场景。比如创建 binlog 采集任务、正常消费 topic 数据等。
日常运维工作中经常用到的场景。比如消费者暂停消费操作等。
跨平台联合查询场景。比如通过 JDQ 消费者 username 查询关联的 JRC 的 flink 任务等。
隐藏性功能场景。比如正常情况下 A 功能不会显示，需要打开某个开关才可正常显示等。
图 3
根据用例场景、活动参加人数来准备测试数据。主要包括所属平台、测试数据类型、测试 jed 数据表、测试 ck 数据表、测试数据说明、使用人如下图所示：
图 4
提示：提前给活动参与人员统一添加权限。比如使用指定的项目空间。
活动时间安排：10 分钟介绍本活动轮次情况，50 分钟任务执行，10 分钟交流发言。
根据活动轮次、小组划分情况进行任务划分，以 JRC vs JDQ 为例，JRC 的研发等相关人员执行 JDQ 的任务，反之，JDQ 的研发相关人员执行 JRC 的任务。
为避免使用相同测试数据导致任务创建冲突等情况，双方人员需对测试数据进行标记认领。如上图 4 使用人列。
双方人员在大扫除过程中发现问题及时记录到 joyspace 中，不需要现场讨论产品细节，标明测试验证人、测试时间、结果填写、测试验证结果。将来可以根据问题的价值与重要程度给予不同奖励。如上图 3 所示
产品主测试人员为活动答疑人员，双方人员可能存在以下场景需要现场支持：
任务创建成功了，需要 XXX 审批，答疑人员跟进审批操作。
对产品功能不了解，对用例场景描述不太理解，需要指导。
对发现的所有问题进行合并去重、分类汇总。包括问题编号、问题所属产品、执行的任务编号、问题缺陷描述、截图或错误日志、记录人（任务执行人），问题分类。
问题处理。和产品主研发、产品经理一起组会评审问题优先级、是否改进、改进方案、改进负责人、改进预计完成时间、改进状态等。
图 5
本次 bugbash 活动共发现问题 40 个，其中功能性 bug 2 个，确定需要改进的有 30 个，以前端优化为主。
测试人员根据发现的问题完善产品用例，进一步提高产品质量。
① 提供了学习其他产品的机会
了解别的产品都是做什么的，以及怎么用的，交叉体验更符合用户的身份，发现更多问题。在大家都很忙的时候，能抽出这么长的时间不容易。
② 提供了测试场景，避免盲目测试
活动中选取的测试场景主要都是日常工作中遇到，测试人员将操作步骤描述的很清楚，方便大扫除的人员进行执行。
① 关键节点审批阻塞
由于流程环节审批人因各种原因（临时开会、临时请假等）不到场，导致流程审批阻塞，任务无法向下执行。后续可在审批环节增加 backup 人员。
② 时间紧，有的任务执行不完
由于整个活动只有一个小时时间，非业务相关人员理解业务知识需要一定的时间。后续可适当延长活动时间并精简任务场景，比如可以分专题开展活动，类似产品界面易用性、安全性、国际化等等。
③ 激励机制待提升
本次活动缺少一些物质（比如小礼物：酸奶、巧克力等）或精神（徽章、T 恤）奖励，大家参与的积极性有待提升。建议引入游戏竞争机制，可以增加趣味性，调动积极性，真正做到真正寓工作于娱乐。
① Bug Bash 平台化
本次 bugbash 大扫除活动主要还是线下组织 + 共享文档形式为主，如果能建设拥有一个平台可以随时随地的组织 bugbash，自由选择产品业务场景，灵活多变的任务下发就会更高效。
② Bug Bash 范围扩大化
不是只让产研测内部团队成员参与 Bug Bash，也可以邀请用户参与，参与的人越多，越容易发现问题。
作者：京东零售 尹伟
来源：京东云开发者社区 转载请注明来源
