缺陷大扫荡

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

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问题反思每迭代都做，容易失去新鲜感

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

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

另一个是，真的觉得有必要的时候，才做Bug Bash。团队如果平常会主动走查、用户反馈也很积极，到也就不必特别做Bug Bash，我们不用为了做而做，真的是发现有价值有需求，再推动效果反而更好。像是我网易有数的项目，就是QA同学与开发负责人感觉测试时间紧张，需要调动大家一起来Bug Bash，反而这样大家自己提出来积极性更高，最后也认真准备小礼物，大家玩的也很high。

Bug Bash的限制?

有人会问BugBash是不是什麽功能都要测？其实也有限制。例如支付功能、跟实际时间相关的功能（教育产品的学期）、还有权限类等功能，会比较难在一两个小时内众人来做测试，对於团队来说，要真的充值、还是要弄虚拟金钱、调整权限等，会比较麻烦，反而会阻碍其他功能的试用。建议这类功能，尽量让专业QA来做测试。当然如果项目组事前准备工作妥善，当然BugBash能覆盖这类功能是最棒。

总结与建议

Bug Bash不是一定要举行的活动，如果有时间举行，是对于团队、产品等多方面都有好处的活动。其实不是只能让内部团队参与Bug Bash，例如二次元这个项目也曾经邀请用户参与Bug Bash，效果也是很不错的。让我们一起提高产品质量，打击小强！

作者：张孙恩，网易杭研项目经理，CSM、PMP。土生土长的台湾人，台湾大学MBA毕业。曾服务于美商默沙东药厂、顶新集团。在网易担任猛犸大数据平台、网易有数敏捷数据分析平台的项目经理，并服务过感知与智能中心（AI、AR）、ColorTouch、搜索算法等项目。关注大数据项目集的敏捷实践，与企业级产品的战略规划、项目管理。《网易一千零一夜》主要作者之一。

本文由@网易杭研项目管理（微信公众号：NetEasePM）原创发布于人人都是产品经理。未经许可，禁止转载。