如果我们把项目的开发过程比作驾驶过程，产品质量就是安全驾驶，那么测试就像是驾驶中看挡风玻璃的过程，需要融入到整个开发中。总之，产品质量需要在开发的各个环节中来保证，Bug Bash作为常规测试的有效补充，也是产品上线前的重要一环，组织成功的Bug Bash必能使产品日趋完善。

背景故事

第一天

“感觉没啥问题啊”
“是啊，没啥好测的，我们系统挺稳定的”
“嗯嗯，我也觉得！”

一个小时后……

“就俩问题？既然没有别的问题了，结束吧，回去记得这俩修修哈”

于是，在产出两个问题后，我们一行五个人结束了年底最后一次上线前的Bug Bash。

第三天

微信群：

组长：“各位看下邮件，明天需要紧急Hotfix这个问题”。

一个小时后

我：（思考）为啥做了Bug Bash还没能避免线上问题发生呢？Bug Bash如何做才能更有价值？

（注：线上Bug的锅是我的，漏测了功能点。不过恰好引发了我对Bug Bash的思考而已<认真脸>）

什么是Bug Bash

Bug Bash这个词，我是来TW才听说。第一次作为参与者，是被分配了一份Windows IE的web测试任务，在业务还不熟悉的情况下进行了一次盲目的Bug Bash。过后，我终于对Bug Bash有了初步的认识。哦！Bug Bash 原来就是开发，测试，项目经理，需求分析师……所有相关的或者不相关想参与的人，一起放下手中活计，找个会议室玩大家来找茬啊！

组织了两次失败的Bug Bash

了解了Bug Bash是什么后，作为组内唯一测试，我就跃跃欲试在组内搞了一次。步骤：定会议室、定时间、发组内全员邀请邮件、准备好测试账户和要测哪些平台、建了一个Trello板子给大家做记录。（你们也是这样组织Bug Bash的吗？）于是在一个风和日丽的下午，我们六人组风风火火的开始了近半年第一次Bug Bash！经过一小时的奋战产出了几个不大不小的问题，恰好上线前有时间修复。看起来一切都恰到好处，并无异样。

所以，年底的上线前，我们又照猫画虎进行了文首提及的这次Bug Bash。

为什么说这两次Bug Bash失败呢？

第一，没有划分测试范围，纯粹的随机测试导致重复测试率较高效率底下；

第二，未能就此次Release的功能和代码修改的部分进行说明，使大家测试没有侧重点；

第三，没有奖励机制大家的积极性不高；

第四，未能在事后积极收集反馈导致同样的问题延续到了第二次。

后来在组内的Retro中，我们组员就此也提出了很多建议，吸取了大家的建议，加上自己的反思后我又去了解了其他组组织Bug Bash的经验，总结了关于如何组织成功Bug Bash的几点建议。欢迎大家指正和补充。

如何成功的组织Bug Bash

选择合适的时间

建议有较大Release之前两三天进行。这样做的好处第一是版本稳定一般不会再有新的代码合入，第二是发现问题还会有一到两天时间修改，改完也会有时间测试。具体时间选择，个人更倾向下午4点以后。在即将下班的时间，大家一起约到会议室，进行一场游戏式的Bug Bash，然后结束一天的工作，似乎听起来比早上做完Bug Bash，下午就要开始改代码好的多。

确定地点

如果有通风好，又安静，还能晒到阳光的大会议室就太好了。头脑清晰才能有更多产出嘛。

确定参与人

虽然Bug Bash是一场测试活动，但是参与人不应该仅限于测试。我们要求组内全员参与的同时，也应该考虑到非组内成员往往会有更加新鲜的视角和思路。我们可以邀请其他团队中有相关经验的人，比如邀请做过类似项目的测试，了解该领域业务的需求分析师。参与者在技能和角色上的差异有助于发现不同类型、不同层次的缺陷。

准备测试设备，测试环境，测试账户，提单模版等

我们是支持手机的web项目，所以一般会准备安卓手机，苹果手机，Windows笔记本，Mac笔记本。具体需要测试哪些设备根据各自项目而定，提前找好设备事半功倍。

测试环境的话我们是前后端分离项目，所以首先会和后端确认是否现在的版本是准备上生产环境的，确定可以我们会把最新的前端代码部署到预生产环境。确保我们进行Bug Bash的环境是准生产环境版本。

根据不同权限分配不同的测试账户给参与人员也是很重要的，这样可以保证每种权限的功能都被测试到。因此，作为Bug Bash的组织者，需要提前为大家准备测试账号，避免使用同类型账号遗漏测试点。

准备提单模版，我们组会在Trello上建一个Kanban供大家使用。约定好不同优先级的问题使用哪种颜色标签。一般会有Backlog、 In Progress、Fixed、in QA、QA done、Not an issue，这几个泳道。

准备特性列表

Bug Bash虽然是一场随机测试，但是不应该只让大家随意点点。作为测试，应该准备一个产品的特性列表以供大家选择。确保我们产品中重要的特性都被覆盖到的同时，也能很大程度减少重复性测试。

准备好列表后，测试还应该就自动化测试覆盖不到的部分，本次Release有过修改的模块在会前重点说明。让大家有侧重点的去测试。这是非常重要而我们之前缺失的部分，也是导致我们Bug Bash失败的主要原因。

沟通与日程安排

做好上述工作后，就可以安排时间对参与者发出邀请了，我们尽量选择适合所有参与人员的时间段和时长。

确定活动形式

以往参与的几次Bug Bash我们都是拿起设备就开干，形式=无形式。

其实为了调动大家积极性，我们可以采取竞赛形式，以个人为单位，也可以组队进行。提出问题较多和提出问题的严重级别较高者获胜，对于获胜者准备物质奖励。巧克力，饼干等小食品大家都很喜欢。也可以准备一个奖杯，类似于学生时代的流动红旗，在每次Bug Bash后它将拥有一个新主人。

整理与合并

最后的时间要留给问题整理。把大家提出的问题挨个过一遍，过程中可以澄清问题避免理解误差，同时进行问题分类。把重复性问题进行合并，排除Not a bug，进行问题优先级排序。分类好之后，对需要解决的问题和团队达成一致。最后将整理结果记录并发送给团队成员。

收集反馈

准备一份金数据，在会后收集大家对于本次Bug Bash的体验和建议。有反馈才能帮助我们提升后续活动质量，除此之外反馈还承担着我们TW人追求卓越的精神，和捍卫公司文化的重要责任。

一场成功的Bug Bash带来的好处

我们做了那么多准备工作，花费了那么多人的时间经历所做的Bug Bash价值在哪里？

提早发现问题 ，避免严重性问题在线上环境发生。
帮助团队发现更多问题。 我们参与人数较多，且是不同角色，更容易发现不同类型、不同层次的缺陷。除了缺陷外，我们也会收到很多建议性问题，潜在的需求往往由此产生。
帮助团队学习 。除测试外的其他角色，往往很少使用产品，通过Bug Bash可以让团队其他角色作为用户体验产品，深入了解业务。测试同学也可以从问题中累积经验，完善测试策略，补充测试用例，这是后续提升产品质量的基石。
团队建设 。平时大家各自忙于手头工作，鲜少就产品问题进行集体交流。Bug Bash提供了这样一个机会，让大家一起以竞赛形式玩大家来找茬，过程中还可以调侃下某些有趣的bug，说一些无关逗乐的话。这些小小的交流逐渐让我们的团队更加稳定。

Bug bash无所不能？

并非如此，Bug Bash也是有局限性的。

比如，Bug Bash往往发生在开发后期，临近发布，这与敏捷测试中测试左移的思想不符。搭配开卡, 桌面检查等其他敏捷实践使用效果更佳！不过Bug Bash并不限定开发方式，其他开发模式的团队也可以采用此实践来完善产品。

再比如，Bug Bash中我们往往更关注较大的功能点，无法覆盖到很多产品业务细节，比如修改某个字段所产生的影响，选择某个下拉框才能展示某个字段，这类小的测试点往往会被忽略。这就要求测试能够在最初测试用户故事时设计比较详尽的的测试用例来覆盖这些测试点。也可以设计比较完善的自动化测试用例在回归测试时运行。

基于以上两点，我们了解到只有Bug Bash是不能确保产品质量。

如果我们把项目的开发过程比作驾驶过程，产品质量就是安全驾驶，那么测试就像是驾驶中看挡风玻璃的过程，需要融入到整个开发中。总之，产品质量需要在开发的各个环节中来保证，Bug Bash作为常规测试的有效补充，也是产品上线前的重要一环，组织成功的Bug Bash必能使产品日趋完善！

作者介绍：

作者简介：李攀，Thoughtworks 质量保证咨询师，6年软件测试经验，擅长Web及接口测试，致力于敏捷软件开发中的质量保证工作。

本文转载自ThoughtWorks洞见。

原文链接：

如何成功的组织Bug bash

创作场景

如何成功的组织 Bug bash