Bugbash的那些事儿

Bugbash是质量保障的一个手段。一般项目过程中，研发阶段之后就进入测试环节，经过QA一番测试后，基本可以进行预上线。但是，bugbash这种检验形式的存在更是对QA测试过程的一种补充。近期，我有幸在项目过程中组织了一次bugbash活动，下来就分享一下这个过程。

Bugbash是一种在项目测试完成到一定阶段，产品质量初步可评估后采取的一种集体体验产品功能并发现潜在缺陷和改进的集体活动。参与人可以是项目内的，也可以是项目外的，可以对业务有所了解，也可以对业务一无所知，所以这就在弹性的同时增大了活动把控的难度。从我的实践总结来看，bugbash主要从以下过程来组织和分析其开展思路：

一．要不要Bugbash

1、开展Bugbash的目的

Bugbash一般是作为QA测试的补充，在上线前一段时间内引导用户进行功能体验，基本上让体验者自由模拟真实用户的部分使用场景。因此，如果你的产品并不需要这个环节或者到这个环节已经临近上线的deadline了，就不太适合做bugbash。

2、项目产品类型

对于业务太复杂、场景需要一系列构造且数据难以伪造的产品并不适合做bugbash。另外，对于业务太简单功能很少的产品也没有必要进行bugbash，投入产出比太大。因此，一般情况是对大型web类产品、手游等比较适合进行bugbash，让用户尽情的在页面上发挥他们的想象力驱赶一群bug。结合我自己的产品，虽说业务较复杂，bugbash投入会较大，但确实是一款web类应用，用户的发散性操作对跳出业务流去寻找bug确实有所帮助。

3、项目所处阶段

一般项目处于新上线、功能点较多、业务范围大、上线临近且留有一部分时间的情况下做bugbash是比较好的。我这次进行bugbash主要是想在测试中后期对前期的测试进行补充，上线还有一段时间，但是功能已经比较稳定。

 

二．Bugbash前期准备

1、提供测试环境和数据

首先，从自己测试的角度思考参与者会需要哪些环境、配置、权限、资料和工具来开展测试，需要通过文档、笔记、图表等形式整理成文并放在一个公用的、大家都能够获得的地方。其次，测试环境最好是原先功能测试的环境，确保环境可用。另外，测试数据的构造是较重要的一点。有三种选择，一是让参与人员发散性构造；二是给出条件和说明让参与者按规定构造；三是替参与者构造。三种方式要根据项目本身的业务来选择，尽可能模拟线上可能存在的用户场景。本次bugbash由于业务限制，有一定的用户场景，考虑到提用户构造好各种类型会对用户限制得比较紧不利于发现更多的问题，我们选择上半场放开限制，让用户自己构造；下半场则提供给部分参与者一些我们事先构造好的场景，让他们在这些场景下进行测试。

2、邀请和激励

准备好了测试需要的数据之后，就需要告知目标用户，把他们召唤过来进行bugbash了。考虑到bugbash的自愿性，我们需要一些激励和鼓励来能把人气带起来。看看下面的邮件：

注意，把你需要强调的信息放大醒目的表示出来，并且多次重复会有一定的收效哦。

3、用户培训

对于业务较为复杂的类型，建议前期准备一份用户培训资料。比如，我这次的bugbash有一点就做的不好，因此测试的业务有较多限制，会触发一些锁定类的操作，需要一些接口工具解锁。一旦锁定了就需要调用工具接口，这样在活动过程中就会难以控制。对于这种情况，如果去掉限制则一部分功能无法测到，不去掉限制的话就只能通过前期对参与人员进行一个培训资料的准备并引导他们，会比没有这个过程效果更好。

4、现场支持

安排本项目团队中对业务和实现较熟的人员做现场支持和答疑人员是必须的。因为参与人员无法确定他们看到的是否是一个bug，因此需要支持者。特别是参与者较多活动规模较大的时候，一个较好的人员安排计划是必不可少的。

三．Bugbash进行中

1、现场气氛

在现场大家找bug的过程中，需要更轻松预约的气氛和力争向上的精神，这样能帮助我们在有限的时间内达到更好的效果。因此不妨准备一些零食、水果，其次对现场的bugbash做一场小型bug争霸赛等。

2、进度控制

Bugbash需要控制在几小时至半天的时间内，bugbash不是常规测试会延续几天甚至更长时间，它只是一个体验过程，因此如何高效运用这段时间是bugbash组织者的一个考虑因素。我们可以将bugbash划分成几个阶段，这样便于控制。但是千万不能忘记，要在一定的时间点给出一些结论来鼓励大家，比如还有10分钟，目前bug发现最多的是xxx，还有希望超越等等。（此处POPO截图略过）

3、记录和反馈

在整个过程中，应该实时反馈给大家目前的进度是什么，尤其是发现了多少bug，分别是谁发现的，这不仅起到一个气氛的煽动作用，而且是对bug发现者的一种激励，并且发现了的bug后续就不会重复提交了。另外，bug发现后最好是由支持人员确认这是一个bug并进行记录比较好，一是参与人员记录的会比较自由和凌乱，不一定需要要求，二是时间上不一定来得及。

四．Bugbash结束啦

1、统计和修复安排

Bugbash的结果是我们的目的，这其实是前期我们就应该准备好的材料，用于记录我们关心的数据，可以根据不同项目流程定制，但是一般情况下会有以下信息是必须的：

当然，我们需要对bug的优先级进行划分，结合对上线功能的影响以及修复进度等安排来评估一个bug是否修、是否马上修等。

2、奖励和反馈

最后，我们应该要把bugbash的结果反馈给所有的参与者和关心这次活动的人，对于表现好的小伙伴给出相应的奖励。最后的最后，这就会是一场有收获、有意思且有爱的项目活动啦！

本文来自网易实践者社区，经作者何美玲授权发布。