Bug Bash，顾名思义就是缺陷大扫除，让团队在产品版本发布前，全员一起发现 bug 的过程。一般在互联网产品开发过程和敏捷实践中使用较多，通常可以由项目经理或 QA 组织发起，全员参加。
1. 进行时间
发生在项目开发各阶段（一般叫里程碑）的末期，QA 完成了大部分的测试后，已经准备好要上线了之前来做这个事情。
有些团队会使用 1- 2 天来做 Bug Bash，对于敏捷团队来说，一个迭代只有 2 周，2 天比较奢侈，一般在 2 个小时。
2. 规划
Bug Bash 的工作只是模拟普通用户的使用，比较属于探索性测试的范畴。团队人数众多，使用的场景、设备、权限和其他外部因素也不同，更能发现问题。
QA 或者 PM 在组织 Bug Bush 的时候，需要做一定规划。
- 环境准备。 测试开始前，QA 需要完成一轮系统测试，没问题后开始 Bug Bash，测试的环境需要提前准备好。一般是 UAT (预发)环境。
- 小组划分。 当所有人都开始测试，大概率会重复测试一些热点功能和场景。通过划分小组，让每个小组关注不同的领域和软件部分。
- 奖励机制。 Bug Bush 需要动员团队，可以通过一些小的礼品 激励团队，让大家的参与感更强。
- Bug 收集方式。 在开始前统一 Bug 的报告方式，务必获得更多的 Bug 复现的方式和数据。Bug 收集需要注意操作场景、步骤、测试数据、用户等。
- QA 对 Bug 分类和确认。 Bug Bash 完成后，QA 需要及时的确认 Bug、分类 Bug 类型、对 Bug 的优先级定级，然后团队才好根据优先级处理 Bug。
3. 注意事项
Bug Bash 的一些经验：
- 固定时间。 一般团队的活动都需要固定时间，否则一下午可能直接就过去了，Bug Bash 是对 QA 工作的补充，一般来说 Bug Bash 的效果会随着时间边际递减，开始的 30 mins 会发现 80% 的问题。
- 避免注意力流失。 Bug Bash 会让开发人员参与，开发人员最大的特点是容易限于细节，如果在活动中发现的问题，及时报告即可。
- 做好记录。 记录是很重要的事情，无论是 JIRA、WIKI 或者就是纸张和笔，也可以使用 GIF、视频录工具记录。