如何来进行一次bugbash

• 聊一聊bugbash

bug bash ，解释为缺陷大扫除，通俗一点可以解释为大家来找茬吧（笑了）。

这是一个可以很有趣也很有意义的活动，为什么这么说，下面一点点的来剖析一下，一场bugbash的开展。

• bugbash的作用

在具体说一次bugbash的展开之前，我们来说说为什么要做这个事情呢？由于来到一家新公司，想要推广bugbash的开展，必须拿出足够的理由来说服领导。

1.对测试

让测试更有信心，可以说是先于外部用户的第一次检测，其实也是一次查漏补缺。

由于参与的人员多种多样，故而在操作习惯上会有很大的区别，对于随意性测试来说，这是一种很好的测试路径。同时，对于移动应用来说，也是一个兼容性测试的绝佳机会，毕竟参与人员的机型是多种多样的。

这也是上线前的一次演练，对于版本上线，需要准备的环境，需要新建的运营活动，数据库的准备等等，这个过程本来是上线前才手忙脚乱的准备起来的，现在有必要在bugbash之前就理顺了。

2.对开发

这是开发全面了解自己做的产品的一个机会。

平常，开发同学们可能非常的忙碌，紧张的在做功能的开发，但是却没有机会实际的来用一下你所为之开发的产品（真的，很多开发对于产品很多的功能都是不清楚的），bugbash是一次非常好的机会，来让开发同学自己检验一下你的代码。

同时，开发更加了解自己开发的功能里面的弯弯绕绕，可能你在开发过程中，没有实际的走一遍，现在，就请好好的使用下你的产品。

3.对产品

首先，产品人员是第一个对产品负责的人员，故而，bugbash是一种保障，对产品人员的意义，很大程度上，和测试对产品人员的意义是一样的。当然，并不是说有了bugbash，就不需要测试了，毕竟测试做的工作更加的系统和全面。

其次，我们要明确，bugbash的过程中，并不是不能产生除bug以外的东西，一些内部人员都觉得不好用，缺失了的功能，很大程度上，就是真实用户的反馈，是值得产品人员好好听一听的。

4.对项目团队的总结

一个项目的成功上线，绝不仅仅是测试的责任，对于项目的使用体验，性能，视觉设计都是一种考验，只有用户满意了，或者说项目的预期目标达到了，才能算成功，而这个过程，这种成功的满足，是归属于项目团队的所有角色的。所以，bug bash对于项目团队的所有人都是有利的，而参与活动的人员包括各种角色，这个时候，参与者们可能会提出很多有建设性的意见，当然这些意见可能是针对产品的，可能是bug，可能是UI的缺陷等等，这些意见成果很可能就是项目目前或者将来的改进点。

其次，当大家聚集在一起，在一个短时间内进行一次团队的bug bash，可以加强整个团队的交流，也使得成员们对自己的项目有更全面的了解，你总不希望看到产品不知道功能有没有实现，开发不知道功能存不存在，这样乌龙的事件出现吧。如果在bug bash的过程中，碰到不了解的地方，随即可以咨询在场的人员，这是一种非常好的面对面交流的方式。

• bugbash如何开展

下面讲到了过程，bugbash是如何开展的呢?

1.时间

对于什么时候进行bugbash，这个时间点，可以是大家根据项目的具体情况来确定。

一般建议在项目上线前，bug趋于收敛的时候进行，这样的话，bugbash过程中不至于有block使过程进行不下去。但是这个时候呢，项目上线时间可能已经很紧张了，所以在bugbash中的产出，就要进行详细分类，只有很紧急，修改稳定性高的bug才会被解决，其他的建议，小bug可能就会放到遗留问题和需求池中。

对于是不是每个版本都要进行bugbash呢？

我的感觉是，不是的。一般来说1个月会发布一个版本，像我们目前的团队，整个团队有3个进行中的app，分2个端，那不就是1个月可能有4-6场的bugbash，别说人叫不齐了，就是大家的参与热情也被耗光了呀。

所以在一个大型版本，或者说几个小版本的累积之后，可以进行一次bugbash，控制好间隔时间和版本大小。

2.人员

参与人员是bug bash中的主要角色，我们会邀请哪些人呢？

团队成员，开发，客服，运营，产品经理等等，都是邀请的对象，不过，每次都可以有些小变化。

3.场地

最好可以大家聚集在一个会议室中，当然移动产品，请找一个网络好一点的地方。

4.过程

4-1.开始前，测试或产品同学，需要准备好这次bugbash的新功能checklist，因为这是你希望大家可以重点关注的东西。准备好测试产品，产品最好能稍微回归下，确保包的正确性，准备好方便的安装环境。

4-2.bug bash开始后，可能会出现不同角色的争论，这个时候，希望活动的组织者，可以控制好场面，大家应该回归到活动本身来，而不是将话题扯开去，一些有意义的争论话题，可以记录下来，在活动后，由涉及双放再好好的谈一谈。

4-3.这里，需要考虑下，如何来调动参与者的积极性呢？

也许第一次组织bugbash的时候，大家都是很有热情的，但是到了后面，慢慢的参与者的积极性就会越来越低，所以组织者就需要想想如何调动大家的积极性。

下面这几个方法都是可以参考的，给予bug提的最多的人员 一些实物奖励，bugbash过程中，提供一些小零食等等。

5.建议

通过第一次组织bugbash，我发现以下几点值得去改进的地方。

5-1.对于bug bash的进行，最好在项目开始的时候，就通知到项目团队的成员，这样，可以使开发有个明确的时间点概念。

5-2.在bug bash开始前，最好可以进行一次规则说明，让大家明白要干什么，尤其对于刚开始做这个事情的团队，很多时候，都会走偏。

5-3.跟产品和开发人员沟通好，其实测试不是bugbash的主人，很多时候只是一个辅助角色，所以作为需求方和实现需求的人员，要有个意识，这个bugbash的产出，需要他们来进行思考和改进的。

5-4.团队内所有成员，应该讨论下，是否能接受在bugbash中提出需求建议，产品功能缺失，不易用性的建议，一般这都是允许并欢迎的。但是有时候，刚开始组织这个活动的测试和产品人员都是拒绝这种产出的，所以大家要明确好意识。

• bugbash产出反思

其实产出，上面已经讲过了，主要是bug和产品建议。

这里很实际的，要根据当前产品的上线时间，bug走向，来对这一系列产出进行整理，不是所有bug都要修改，在时间紧急的情况下，应该双方沟通，解决一些重要的，修改风险性不大的bug。

而且，对于建议，产品人员不应该放任不管，而是要记录，并真正的面对。

• 总结

目前在我们的新团队中，还没有真正的进行过一次成功的bugbash，所以我将原来公司的一些进行过程详细的记录了下来，希望能对成功的组织一次bugbash有点帮助。