网易方法论：手把手教你做Bug Bash（缺陷大扫荡）

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

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

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

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

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

有同学会问：那是不是我们可以只做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都可以。

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

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

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

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

我在几个项目内推动，第一次一定是大家非常有新鲜感，参与度高。但是每个月迭代下来，大家逐渐对於这活动会失去激情。项目经理这时候就要好好反思一下，该如何改善与调整。我自己的经验有两个思路：

不一定每个迭代都搞，可以在大版本或者累积好几个小迭代认认真真做一次大的Bug Bash、发发奖品，这样可以保持大家的新鲜感。

（编辑：ASP站长网）