此文已由作者夏君授权网易云社区发布。
欢迎访问网易云社区，了解更多网易技术产品运营经验。
BugBash源至微软概念，翻译为《缺陷大扫除》，顾名思义是集中大家力量全面清扫Bug，确保产品质量。
下面通过5w1h分析方法谈谈BugBash活动：
What 什么是BugBash？
BugBash活动就是给项目产品找出Bug的活动。该活动主要在产品发布前，由项目主管或者QA发起，召集各种角色来体验产品，让各种类型的Bug尽早发现，Bug趋势尽早收敛。
Why 为什么开展BugBash?
互联网行业产品迭代周期短，QA与开发处于半敏捷状态，包括前期的需求评审，发起BugBash，而不只是从测试人员角度发现问题，可以集产品、项目主管、运营、甚至其他业务团队成员所有人的力量，让各种类型的BUG尽早发现，可以在项目周期短的前提下，让Bug趋势尽早收敛。尤其是移动端产品、全新上线产品，介入BUGbash是十分必要的。
注意：
不是每个迭代都需要开展BugBash，可以在大版本或者累积好几个小迭代认认真真做一次大的BugBash、发发奖品，这样可以保持大家的新鲜感。另一个是，真的觉得有必要的时候，才做BugBash。团队如果平常会主动走查、用户反馈也很积极，到也就不必特别做BugBash，我们不用为了做而做，真的是发现有价值有需求，再推动效果反而更好。比如网易金融智投组合基金的项目，QA同学与开发负责人测试时间被压缩紧张，需要调动大家一起来BugBash，反而这样大家自己参与度高，积极性更高，最后大家体验得也high。
有人会问BugBash是不是什么功能都要测？其实也有限制。例如组合基金后台交易对账清算功能、需要时间效应，用户交互无感知，需要业务底层数据逻辑，会比较难在一两个小时内众人来做测试，对于团队来说，要真的体验整个产品整个生命周期、还是要调动相关人员关注几个交易日资产状态、金额及收益变化等，会比较麻烦，反而会阻碍其他功能的试用。这类功能，一般尽量让专业QA来做测试。当然如果项目组事前准备工作妥善，当然BugBash能覆盖这类功能是最棒。
Where 在哪里开展BugBash?
需要选择一个集中的环境，比如大培训室，这样保证大家都不被打扰和中断，能集中精力找Bug。
Who 谁来参加BugBash?
参与的人员，应该包括项目组全体成员，比如开发、测试、项目经理等等，有资源条件，也可以邀请非本部门团队来参与体验，比如会咨询用研部门的同事一同来体验产品
When 什么时候开展？
项目迭代测试一般为3个周期，建议是在上线前，QA第二轮测试结束通过后，确保线上没有重大bug影响试用、服务是稳定的状态下，可以举行BugBash。时间点我倾向于选择项目中后期，功能基本稳定后，但是也不能太晚，假设在快要发布前做Bug bash，发现的Bug没有时间得到修改，那作用也会打折扣。Bugbash的执行时间，根据项目的规模吧，我觉得可以定1个小时左右。但这边有个两难是：确实等到前面描述的状态完成后，bug bash比较正规，团队不会因为重大bug而block各环节的试用，而且是比较接近上线后用户的使用状态；但坏处是通常开发时间是很紧凑的，当到第二轮测试结束后，通常离上线也没几天，如果BugBash提出很多需求类的bug、新需求、大改动的部份，其实已经来不及在本版本实现，就会放入需求池或之后版本实现。经常最后BugBash很多提出的问题或需求都会越积越多，修复之日路漫漫。
当然解决方式，可以在提测后，就邀请产品策划、交互、视觉针对产品做个验收，确认产品是否跟设计符合，以及是否有些需求bug、新需求、改进提出，可以减少BugBash时的需求类bug的数量，及早让团队因应。
How 怎样开展？
前期准备：邮件内容覆盖（时间、地点、准备工作、规则、统计BUG工具、权限是否开通等）
说明测试内容：产品未实现功能告知，避免无用功。
安排答疑、环境解决人员。
报Bug的格式、标题内容需要说明。
组织者实时播报Bug战况，营造竞争氛围，提升参与者的士气。
Bug结束时，组织参与者进行Bug triage，评估Bug是否修复、何时修复。
组织者负责整理本次Bug bash活动的胜利成果（Bug数、Bug类型、找Bug获胜者），邮件通知参与者。
为发现Bug数量最多的人颁发小礼品。
统计工作：Bug Bash结束后，QA/产品主持人要统计全部issue数、有效bug数、需求数（案例见下图）。并检查是否有重复提交的问题，若有重复可以按照提交时间的先后顺序，决定这题算是谁的，或是各得一半的分数。然后再把bug跟需求区分开来。另外有些团队也可以根据提bug的价值与重要程度，给予不同奖励。当然BugBash如果经费允许，可根据不同表现，给予对应同学一些奖励，促进大家积极参与。
网易云免费体验馆，0成本体验20+款云产品！
更多网易技术、产品、运营经验分享请点击。
相关文章：
【推荐】 NOS跨分区灾备设计与实现
【推荐】 消息推送平台高可用实践（下）
【推荐】 分布式存储系统可靠性系列五：副本放置算法&CopySetReplication