集体缺陷大扫除，也称为缺陷大扫雷，Bug Bash，Team Explore等，目标是在发布前最后检查一轮，尽可能发现残留的严重缺陷。它是敏捷团队质量共建最重要的活动，没有之一。探索式测试天然就适合集体进行，在正确的组织形式下，通过团队放大探索测试的惊人效果，让探索测试理念深入人心。
在本活动的组织形式上牢牢把握三点，即比赛制、不争论、跨角色参与。
比赛是最好的氛围催化剂。那能否把找Bug当作比赛呢？
参与者在1-2个小时的测程中，集中全部精力，运用各方面的知识经验，比赛谁找到的Bug（也可以是好的产品建议）数量最多，获胜者有惊喜小奖励。
比赛过程时间有限，如果因为提出Bug被质疑有效性，陷入着急澄清业务逻辑的环节，那时间就很快过去了，影响比赛效果。建议比赛中设置一个记录员，专门确认各位参赛同学提出的缺陷名称和截图，作为汇总的参考。
比赛鼓励项目组不同岗位角色共同参与，包括产品人员、开发人员、项目经理、运营人员，甚至普通用户。也可以跨业务团队互相邀请。
活动步骤：
- 挑选适合做缺陷大扫除的产品，最好是有UI界面，能快速验证结果的项目。对于复杂的算法测试，底层框架测试，可能不太适合这种全民活动。在活动前进行预热，鼓励大家积极参与集体探索，占用时间有限，优胜者有奖励。
- 如果报名人数较多，产品比较复杂，可以对探索产品做一定程度的分区，比如以本次新发布的功能探索为主，每个人以特定的特性分区为主要探索区域。
- 准备好集体大扫除的环境，会议室，如果有零食饮料更佳！
- 准备好测试环境，必要的测试数据和工具，安装包，足够的终端设备。
- 活动进行中，组织者强调大扫除的纪律，规则，并介绍本次测试对象（产品）的探索重点。
- 活动完成时，组织者根据搜集有效问题的数量（和等级），宣布优胜获得者，并颁发奖品。
- 最关键的环节来了：每个参与者谈一谈，自己参加缺陷大扫除的体会，以及收获。
活动结束后数天，组织者将精心准备的缺陷大扫除报告，发布给业务团队，对参与同学表示感谢，激励更多同学积极参与未来的大扫除活动。
收获和启示
缺陷大扫除的收益往往出乎意料，根据我的实际组织情况，10个参与人，2个小时往往能发现高达80，甚至100个有效缺陷及建议！相较于日常测试过程，发现Bug的效率提高了4倍，而且还是在已经完成了一轮系统测试的稳定版本上，新发现了很多的问题。
正因为数量惊人，质疑声也随之而来。缺陷大扫除在稳定版本还发现这么多问题，是不是测试人员专业度不够，漏测严重？
并非如此。
不同角色、不同人员在测试产品的探索角度不同，对产品各维度信息的认知不同，他们的输入对于现有测试流程是非常完美的补充。测试人员在日常测试中会逐渐形成自己的习惯，通过在本次活动中对其他成员探索Bug方式的观察，对于扩展自己找Bug的技巧盲区会有很大启示。
另外，测试人员作为缺陷探索的组织者和分析者，自身也实现了测试产出的关键价值，把Bug暴露在发布之前。
大扫除最后一个环节-所有角色谈感想，是点睛之笔，因为大扫除的核心价值是全民为质量负责，团队并肩作战，质量必须内建，通过理性和感性的形式把共同负责的文化传承下去。
我们经常能听到令人动容的感想，比如：
- 测试外部合作伙伴：以往时常感觉自己是个提Bug的机器，通过这类活动，我能够对产品和开发提出更多有建设性的意见，同时我看到其他岗位的同学还有这种找Bug的技巧，开了眼界，感觉测试也是很有乐趣的：）
- 测试组长：活动的数据打破了我的固有认知，从来没测过这个产品的测试同学，发现Bug的效率甚至高于经常测这个产品的同学，看来找Bug有经验并不是优势，固有思维是有害的。
- 开发工程师：我自己写的代码，没想到质量这么差，我第一次感到如此汗颜！刚才我差点偷偷提交修改代码，在比赛完成前把Bug赶紧消灭掉。刚才已和主管达成一致，下个月我们把新版本需求计划修改一下，专门做一轮重构，消灭掉大多数遗留问题！
- 产品经理：不同成员从不同的视角来体验我们的产品，共同思考，产生了实际的效果，请将活动常态化进行吧！不，应该强制执行，两个小时过得太快了。
- 设计同学：集体比赛找Bug真是太刺激了，之前我觉得抓虫就是测试的责任，我们提提意见就好，现在深入的感受到，测试过程也是可以很愉悦的，让团队的关系更亲密！
参与者不约而同地希望缺陷大扫除能够常态化。从此，在每个关键版本正式发布前，我们都会把缺陷大扫除活动作为“卡点”，必须完成，并输出总结。