要做好这样的活动，首先我们必须明白这项活动的意义。
Bug bash（Bug大扫除）来源于微软，通常发生在项目开发各阶段（微软叫里程碑）的末期，比如Beta版发布前，划出一个专门的时间段（通常1-3天），在这期间所有参与项目的人员，集中全部精力，运用各方面的知识，尽全部智慧来搜寻项目的Bug。
这是一个非常有意思的活动，但要组织好这样的活动并非易事。一般有以下要点：
（1）尽管这是一个测试活动，但参与者并不仅限于测试人员。项目经理，开发人员甚至于高层管理人员都应参加，如同全民动员。目的是要集思广益；
（2）要鼓励各部门，领域交叉搜索，因为新的思路和视角通常有助于发现更多的Bug；
（3）为调动积极性，增强趣味性，可以适当引入竞争机制，比如当活动结束时，评出发现Bug最多，发现最严重Bug的个人，给以物质和精神奖励。
（4）可以分专题展开，比如安全性、用户界面可用性、国际化和本地化等等。
（5）as usual we'll have pizza and other fun food. Sometimes there's prizes for most bugs kept, most heinous bug, etc.
ZBB（零错误反弹）--软件稳定的指示器
为什么要做Bug bash，其实与另一个测试方法有密切联系。在此之前，先说说错误收敛。
错误收敛
错误收敛是指项目组在减少活跃错误数量上取得了重大进步的一个转折点。在错误收敛这一转折点上，解决错误的速度超过了发现错误的速度；因此实际的活跃错误数量开始减少。下图给出了错误收敛的图示。
即使错误数量从整体上开始减少，但具体数量还会出现升降变化，因此错误收敛通常来讲只代表一种趋势，而不是一个固定的时间点。在错误收敛之后，错误的数量将持续减少直到零错误反弹。
零错误反弹
Zero Bug Build：这一版本的构建把所有已知的bug都解决掉了。
Zero Bug Bounce：通常在一个Zero Bug Build之后，bug数目会以惊人的速度反弹，故称Bounce。系统要经历几次bounce，像阻尼震荡一样，bug的数目在弹了几次之后，最后固定在（或者无限逼近于） 0。要注意必须保证bug的数量要到0，以防止一些问题拖而未决。
上图是一个60人的团队的“预想ZBB 进军图”。每个小组的bug数量累加起来，就是团队的bug总量。图中的黑线表明修复的bug总量。
零错误反弹是指在项目中的某一点上，开发活动最终赶上了测试的步伐，当前已经不存在活跃错误。在零错误反弹之后，错误数量的峰值将显著减小，并且错误数量会持续减少直到产品足够稳定，进而构建出第一个候选发布版。取得零错误反弹是项目组逐渐接近稳定的候选发布版的明确标志。
注意，在到达这一里程碑之后，必定还会发现新的错误。但是，它却标志着项目组能够第一次诚实地报告已经不存在活跃错误了，虽然这只是针对当前情况。而且它可以让项目组集中力量保持在这一点上。
事实上，正是通过bug bash的方式，来达到ZBB的效果。
本次bug bash活动总结
本次bug bash总体效果不佳，真正参与人数不多，发现有效的bug数量不算多，达不到bug bash的效果。总结原因如下：
1、大家并不真正理解以上所谈的bug bash对于产品的意义，而仅仅将其当作一项临时活动，积极性不高，这是首要原因。因此，大部分同事没有全力投入进来，甚至是没有参与，这就没有达到bug bash活动的初衷；
2、活动组织者及部门经理在活动方式的理解不一致。在组织者发布了测试要求之后，部门经理并没有及时向参加人员强调活动的必要性及强制性，而对于部门人员到底参加了bug bash没有也不清楚，而组织者则认为部门经理会有良好的配合，事先做好这些事务安排工作；
3、活动缺乏良好的奖励及竞争机制，无法调动大家参与的积极性；如果能有一些物质或精神奖励，同时引入竞争机制，可以增加趣味性，调动积极性，真正做到真正寓工作于娱乐；
4、活动过程缺乏有效的监督，对于没有参加的同事，没有进行有效的监督；
5、产品稳定程度不高，影响测试的效率
希望在下次我们能有较大的改善！
