什么是Bug Bash？
Bug Bash http://en.wikipedia.org/wiki/Bug_bash，也称为Bug大扫除，是软件测试的一个很重要的实践，是对日常测试的有效补充,它在很多互联网公司（比如微软，淘宝等）都是一项重要的测试实践。简单的说，Bug Bash就是对产品找茬；具体来说，就是在产品稳定的阶段，选取一个特定时间段邀请一组不同角色和背景的人员在会议室里对被测产品找Bug。一旦发现问题后可以请熟知产品的观察员确定是否是Bug，对发现最多或者最严重Bug的人员给予一些奖励。项目组成员在搜集好所有Bug和潜在Bug的清单之后，全员进行Bug分析，制定出解决的方案并实施。
为什么在测试中我们会引入Bug Bash呢？
由于参与Bug Bash的人员有着不同的角色和背景，甚至来自不同的项目和领域，所以每个人都会通过自己的观察，结合自己的经验，给我们的测试工作带来更多的视角，帮助我们发现那些被我们忽视了的问题。因此通过Bug Bash，我们可以：
发现尽可能多的问题。对于确定是Bug的问题，项目组成员可以通过分析Bug产生的原因，避免类似的Bug再次出现。而有些发现的问题不一定就是Bug，可能是一些潜在的需求，我们同样可以分析这些来优化我们的产品。
了解不在预期之内的用户行为。通过了解这些用户行为，我们能分析出哪些用户旅程User Journey是需要添加进我们的测试场景中，甚至需要加入自动化测试的。
对于并发的测试，尤其是多用户同时执行不同的场景。大部分时间我们在测试产品时都是单人在操作，即使我们有性能测试来覆盖这些场景，但是通过Bug Bash，我们可以更好地接近用户真实使用产品的并发场景。
进行更多的用户测试User Testing。一般来说我们在开发中会不断地进行用户测试，来验证产品是符合用户习惯，以及开发方向是正确的。鉴于产品可能需要保密，并且使用Bug Bash可以用更小的代价，进行更多的用户测试，所以我们会不时地进行Bug Bash。
Bug Bash除了给我们带来上述4点主要益处，还可以为我们带来一些附加的价值：
帮助QA更深入了解系统。在测试过程中QA进行测试，会不断加深对于产品的理解；不过由于在Bug Bash中QA需要向其他人员描述产品，并规划不同的测试场景和目标，所以会对自己已有的产品知识进行更深入的梳理，而且通过Bug Bash最后的分析阶段，加深对于产品远景、目标和原则更进一步的理解。不同的QA之间也可以相互进行学习和交流。
宣传项目。通过Bug Bash，我们可以邀请不同部门，不同角色，不同背景的人员参与，所以无形中就向更多受众宣传了自己，对于项目获得更多资源，以及通过受众进一步影响更多的人。
引发更多关于产品的思考。根据Bug Bash搜集的问题列表，项目组成员会对这些问题进行集中讨论，并详细解释如何处理以及为什么这么处理，让项目组所有成员对于产品都各抒己见，而且通过这些讨论，引发更多的思考。
既然有如此多的益处，那我们如何组织Bug Bash，还有哪些细节需要注意的呢？
1. 活动准备
首先确保被测产品功能基本稳定。如果被测产品还处于不断出现Bug的开发早期或者中期，就不适合进行Bug Bash。因为如果进行Bug Bash，发现的大部分问题都是已知问题，并不能带来很大的价值。所以我们最好确保被测产品功能基本稳定，并且进行过性能测试和并发性的测试（至少可以支持并发操作）。
其次准备对应的测试设备。例如对于Web和桌面产品进行Bug Bash，我们需要准备足够的显示器和键盘，甚至椅子，来保证Bug Bash可以顺利进行；自然，对于测试移动App，我们也需要准备不同型号和操作系统的移动设备。
除此之外，我们需要准备产品的特性列表并且准备Bug Bash中参与人员需要完成的任务列表。这份任务列表一般会基于不同浏览器，不同平台，不同语言，不同功能模块，设计出针对每组参与人员需要完成的不同任务列表（具体实例见图1）。对于参与人员的分组，具体根据参与人数和特性列表来确定，可以一个人一个组，两个人结对，或者两个测试人员和组内一个QA结对（这么做是因为这样可以及时确定发现的Bug是否有效）。当然如果组内QA有限，可以让QA充当全场的观察员动态协调。
图1 － 根据产品的特性列表制定的Bug Bash任务列表
同时，我们还需要准备好测试环境和测试账号（如果涉及角色权限等功能的任务），并把这些测试环境信息通过邮件告知参与人员，或者张贴在Bug Bash活动场地附近，以便Bug Bash中所有人可以随时获取这些信息。
我们还需要设计一个Bug报告模版并告知参与人员。这么做的目的在于方便参与人员及时记录发现的Bug，也便于我们在Bug Bash后重现和分析bug。因此Bug报告模版格式尽量简单清晰，最好能有截图来帮助说明Bug。Bug报告可以是电子的也可以是纸质的，需要注意的是，尽量保证Bug Bash的参与人员可以方便地访问模版，从而进行Bug记录。
重中之重的是确定参与Bug Bash的人员。这些成员既可以包括组内各种角色，比如开发人员，业务分析人员设计人员，项目经理，还可以包括产品经理，客户；当然，邀请一些对产品不太了解的人员也是很重要的，因为他们更能从一个新鲜的视角来测试产品，比如公司销售，前台或者其他组的开发和测试人员。在Bug Bash举办前，我们需要确保有足够数量的人员参加，尽可能地提高举办Bug Bash的投入产出比。
我们还需要确定进行Bug Bash的时间和时长。在项目中后期，我们通常会以两周或者一个月的频率进行Bug Bash，比如利用午休时间进行1～1.5小时的Bug Bash。当然不同的项目Bug Bash时长和举行时间各自不同，但是原则上，选择尽量适合所有参与人员的时间段和时长。
除此之外，确定举行Bug Bash的活动场地。我们可以选择会议室，来帮助参与人员专注于发现产品Bug，而且由于会议室远离常规工作的场所，有助于为参与人员提供一种新鲜的视角。当然，如果基于宣传的考虑，我们也可以选择公共区域作为活动场地。
在确定了Bug Bash的参与人员，时间和地点之后，应尽早向所有参与人员发出邀请，确保参与人员都有时间参与。
最后，在Bug Bash开始之前我们准备一些小奖励（比如酸奶，巧克力和小礼品），等Bug Bash后发放给每位参与者，以感谢他们对于活动的支持。
2. 活动中
在Bug Bash正式开始前，我们首先要欢迎并感谢所有参与人员，说明本次测试目的、时间、流程、规范和奖励规则等，使所有人都明确Bug Bash会如何进行，以及他们在活动中需要如何测试和记录Bug。随后，我们向每个测试组分发需要测试的任务列表、测试环境和账号，以及纸质或者电子的Bug报告模版。
当正式开始Bug Bash后，每个测试组中的两位参与人员需要共用一个显示器和键盘（或者移动设备）进行结对测试。对于确定的Bug，测试组需要记录其重现步骤，并且记录在Bug报告上。如果条件允许，还需要让测试组在测试报告中添加对应的截图。对于不确定的问题，作为观察员的QA可以适时参与确认，减少测试组在一个Bug上花费的时间。
与此同时，QA作为观察员，除了在测试组中进行协助并帮助确认发现的Bug是否有效之外，还需要观察每个测试组的行为，必要时还需要了解他们这么做的原因。如果条件允许，我们还可以通过录制视频来记录每个测试组的操作过程，以便后续的Bug分析和用户测试分析。如果测试组在完成某项特定的任务时有不能解决的争议时，如果QA作为观察员也没有办法说服双方，那可以暂停并切换到别的任务。此时我们也需要记录任务切换的原因和相应的细节信息。
最后，作为观察员的QA可以记录测试组完成特定任务所用的时间，以便在Bug Bash后对用户测试进行分析时，了解对应功能的可用性和易用性。
3. 活动总结
准时结束Bug Bash，并对参与者赠送一些小礼物（比如酸奶，巧克力等）来感谢大家参与测试。我们还需要对发现最多Bug或者发现最严重Bug的参与人员给予特殊的物质奖励，例如具有团队Logo的徽章或者T恤等。
当然作为组织者，我们还要负责搜集并整理所有发现的Bug。具体来说，首先合并重复的Bug，并且验证它们的重现步骤，尽可能附上对应的截图。最后，组织项目组所有成员就是否需要修复Bug，Bug优先级达成一致意见，这样便于尽早解决高优先级的Bug。
对于那些需要解决的Bug，我们还要考虑是否需要把它们添加到手动测试用例集和自动化测试中。进而考虑是否需要把新添加的自动化测试用例／场景和已有的自动化测试用例／场景进行合并，以保证所有的测试都是分层的，而且是符合测试金字塔的。
针对所有确定的Bug要分析其产生的原因，制定相应的计划以避免再次产生类似的Bug。
在制定了对于Bug的解决方案和计划之后，我们可以通过邮件或者其他方式，如故事卡墙或者缺陷墙，告之所有参与人员。这样不仅可以让参与人员更有参与感，更重要的是使更多人监督我们执行这些计划。
最后，我们还可以整理Bug Bash中收集到的数据（测试时长，录制的操作视频等），检查是否功能设计不合理，导致用户需要很长时间才能完成操作，从而做出产品改进。
千里之行，始于足下
也许你觉得在项目中实践Bug Bash很耗时间和精力，而且不一定会得到领导的支持。其实我们可以在更小的范围内，例如只是项目组的测试人员中开展Bug Bash，通过成果展示来一点一点地得到各方面的支持。
虽然以上是笔者在敏捷软件测试中总结的Bug Bash实践，但是Bug Bash的形式并不局限于特定的开发方式，所以我们可以在自己的项目中采用这个实践，来帮助我们促进产品日臻完善。