BugBash，即，缺陷大扫荡。产品版本发布前，团队全员集中起来、共同找Bug。是软件工程、互联网产品开发过程中，验证环节很重要的一个活动。

什么是Bug Bash？

Bug Bash，顾名思义就是缺陷大扫荡，让大家在产品版本发布前，一起集中精力来找缺陷。是软件工程、互联网产品开发过程中，产品验证很重要的一个活动。通常可以由项目经理或QA主导发起。

什么时候做？

建议是在上线前，QA第二轮测试结束通过后，确保线上没有重大bug影响试用、办事是不变的状态下，可以举行Bug Bash。

但这边有个两难是：确实比及前面描述的状态完成后，bug bash比较正规，团队不会因为重大bug而block各环节的试用，并且是比较接近上线后用户的使用状态；但坏处是通常开发时间是很紧凑的，当到第二轮测试结束后，通常离上线也没几天，如果BugBash提出很多需求类的bug、新需求、大改动的部份，其实已经来不及在本版本实现，就会放入需求池或之后版本实现。经常最后BugBash很多提出的问题或需求都会越积越多，修复之日路漫漫。

当然解决方式，可以在提测后，就邀请产品策划、交互、视觉针对产品做个验收，确认产品是否跟设计符合，以及是否有些需求bug、新需求、改进提出，可以减少Bug Bash时的需求类bug的数量，及早让团队因应。

跟QA做的测试区别是什么？

有同学会问：那是不是我们可以只做Bug Bash，不需要QA了？其实QA是有更专业、更全面、更完整的测试计划与策略，Bug Bash则可以增补QA的工作，发现一些QA可能没发现的问题。或者当QA人力不足时，众人一起找bug的效率也较高。

加上Bug Bash参与者多，更能发现兼容性或用户登入、权限差异等问题， 事先就可以约定好哪些人别离使用差别浏览器、手机、作业系统来找问题。并且一样米养百样人，大家对於产品操作的理解，也会差距十万八千里；加上多人同时协作来使用系统，这个操作的复杂度就会呈现指数级的差异，可能会发现在测试环节不容易找出的复杂bug。QA在设计测试用例只能针对功能点来测，但许多新功能点交叉加上老的功能点，复杂度也会增加，这就需要众人齐力发现复杂性bug，使得质量更有保障。

有QA同学做测试，不做Bug Bash是可以的；但是只做Bug Bash，没有QA则是很大问题。

为什么做Bug Bash？团队集体试用，发现需求

可能有人觉得Bug Bash都提需求会不会走偏？其实提新需求也是很重要的，因为Bug Bash中，我们的角色就不只是研发团队，也是以用户的角度来看产品。如果内部团队本身都有觉得很多需要添加的需求，那产品经理或策划也该好好考虑调整产品的设计。网易教育产品的项目经理也针对这问题做过问卷，团队原本都是对於在Bug Bash提建议有疑虑，问卷统计出来，大部分人还是支持在Bug Bash提需求与bug都可以。

此外在Bug Bash前，开发都只是专注在本身的部份，可能都没有完整真正试用过整个产品，要促使团队本身主动去试用比较难。当测试第一二轮结束后，Bug Bash是一个强制的活动，促使大家真正把本身做的产品用一遍。很多之前只是在设计、交互稿看到的都只是纸上谈兵，真正用起来，才会发现问题或需求，也是看交互与案牍是否容易被大家理解。所以我负责的兩個项目，经常是新需求以及需求类的bug多过开发产生的bug数。

及时梳理，发布前的剩余事项

用户手册、环境、帐号等等，由于大家要开始使用，会促使团队思考上线还缺什么。由于开发与测试同学对于产品操作、环境都很熟，但在BugBash时，视觉、交互、策划、项目办理都可能第一次看到成品，应该思考：用户手册看的懂吗？数据库资料有没有准备好？等问题，让产品上线前准备更完善。

游戏化激励团队

如果光只是宣导：「大家要注意质量喔」、「QA要尽量找出bug喔」，或者要求大家工作职责，可能团队成员执行的动力就比较单薄。但藉着bug bash，其实就是一种工作游戏化，透过大家聚集一起参与，然后加一些角逐的元素，会让大家有个冲劲要努力找出bug，比谁找的bug数最多。这边有一点要注意，主持人项目经理或QA不消只是在旁边不雅观看或加油，也应该积极参与，一马当先多找一些bug出来，来提升大家参与度。当然最后可以利用统计工具，计算一下大家的排名与bug数给予奖励。

团队平时本身可能会做团建，有些团队不必然常搞活动。在这种类似游戏化的活动中，会促进团队间相互的沟通、良性竞争，对于整体团队建设也是很有帮手的。如果项目经理要办Bug Bash，其实可以弄的热闹一点，酿成一种团建。

如何做BugBash？说明规则：准备一份ppt可以在周会上，跟团队宣导说明：什么是bug bash、宗旨跟目的是什么、时间地点是什么、准备工作确认、游戏规则等，便利大家可以随时查阅Bug Bash规则。问题记录的工具：如果有用jira，先确认大家都有jira 6的权限、并可以建立一个叫Bug Bash的模块（也可以是标签，只要便利筛选、统计）。没有jira也可以用云协作、Google doc、Wiki工具来代替，甚至每人发一张纸笔也一样可行，只要便利大家纪录，结束好统计即可。提醒大家做好准备：包孕用户手册、环境是否都准备好、权限都开了没、测试是否确保重大bug修复并验证完毕。如果有经费，准备一些点心、水果、奖品，更有助于提到大家参与的兴致。会议场地：项目组如果人少且都有条记本电脑，可以借一间大会议室，便利随时讨论、合作、排除问题，让大家能更集中投入这活动，气氛也会更热烈。但是如果没有措施借到大会议室或者大家都是台式机未便利移动也不妨，只要座位距离不远、使用即时通讯软件沟通，也一样可以把BugBash做的有声有色。统计工作：Bug Bash结束后，项目经理要统计全部issue数、有效bug数、需求数（案例见下图）。并检查是否有重复提交的问题，若有重复可以根据提交时间的先后挨次，决定这题算是谁的，或是各得一半的分数。然后再把bug跟需求区分开来。别的有些团队也可以按照提bug的价值与重要程度，给予差别奖励。当然bug bash如果经费允许，可按照差别表示，给予对应同学一些奖励，促进大家积极参与。最后也最重要的是，Bug Bash活动之后的问题落实。团队要开个会，大家一起整理所有提出issue的优先级：判断到产品上线前，哪些bug是要修好的、哪些是可以留到未来修。因为Bug Bash到产品上线时间可能已经很接近，除非是很严重的bug，，或者是工作量小、效果大的（性价比高），可以考虑处理；其余都不该该做，这样才能保障代码的不变性，以及准时交付。当然这版本不修的bug、不能实现的需求，可以标示重要性为minor放到需求池，在未来版本去实现。BugBash问题反思每迭代都做，容易失去新鲜感