Bug bash的来源与意义

要做好这样的活动，首先我们必须明白这项活动的意义。

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的效果。

How to run a bug bash

Running a bug bash is a dirty secret of software development. You won’t read about them in software engineering classes, or in agile method workshops. But some managers, when overwhelmed with undocumented bugs and not sure what else to do, demand the whole team stop what they’re doing and get as many bugs into the bug database as possible. This is what’s known as a bug bash, and often they’re a waste of time.

It’s true that a proper QA effort, or test-driven development, minimizes the need for this sort of thing, but few software organizations truly qualify. Hell, many so called “first class” organizations don’t have any testers, or a quality assurance plan at all. I bet bug bashes are one of the most common QA techniques used in the world.

And they can be useful – but the most common mistake is doing them by half. A half-assed bug bash sends the message software quality is lip-service. But doing it the right way can turn a project around, raise morale and sharpen a team’s ability to find and manage issues.

How to run a successful bug bash:

• Don’t create panic. If you say “Tomorrow! Everyone find bugs! Aaaah!” You are creating a panic and look like an idiot. You should know a week or more in advance that the bug counts are soft, or the database needs scrubbing, and line up leads and key players to support the effort.
• Freeze the build. You can not do a bug bash on a moving target: you invalidate repro cases and bug findings. Pick a build, freeze it, and make sure no one, NO ONE touches the live codebase during the bugbash. This should go without saying, but you never know. If it’s your first team wide bugbash make sure the entire programming team understands this basic rule.
• Show what good bug reports look like. Remind everyone crappy bug reports create extra work. Provide two bug report examples: one good, one bad. In the good example show well written description, clear repro steps, and a search for duplicate bugs. In the bad, show incomprehensible descriptions, impossible repro steps, etc. If you don’t provide examples, don’t expect people to magically know what you’re looking for. Finding 1000 crappy bugs that need to be heavily cleaned up is a waste of everyone’s time.
• Have an area or type of bug to focus on . Saying “find bugs” is a shot in the dark. It shows you have no clue what’s going on in your project. Think through what the weakest areas are, or what types of bugs you are most afraid of, and designate them the primary goals of the bug bash. Or offer bonus points (e.g. bugs in area 6 are worth x2) for people who find the specific type of bug most valuable to you.
• Clear the afternoon from everyone’s schedule. A bug bash should be an entire team activity and a half-day is the perfect amount of time. Everyone should be working on the same goal: getting good data into the bug database, and getting that database in shape. If it’s voluntary, or only half the team is asked to do it, the bash will fail. People will smell you’re not serious about the effort, and will contribute accordingly. Get permission to reschedule all team meetings for that afternoon to later in the week, and send out a new meeting invite to the team for the entire bug bash time slot. Include details (see below) on where bug bash HQ is, what the prizes are, etc.
• Get support from big shots. Brad Silverberg, my VP on Internet Explorer 4.0, used to file bug reports regularly. When bug bashes started he’d set the tone: everyone gets involved. With the support of leaders it sets the tone of how important the activity is, and eliminates the BS excuses people find not to participate (”If Fred, our best programmer is doing it, I should be doing it too”). Find the key players on your team, either key leaders or the star programmers, and get them to help promote and contribute.
• Have a bug bash HQ. Finding bugs can be a social activity: have a bug bash headquarters. Grab a conference room, order pizza and beer, and invite people with laptops to hang out and find bugs together. This invites people to help each other find repro-cases, share knowledge and bug database tricks, makes keeping a scoreboard easy, and makes the bug bash a proper moral event. A case of beer and few pizzas costs $60. Well worth it.
• Keep score and have real prizes. Geeks are competitive. Use this to your advantage. Any bug database allows queries for open bugs by date: Get this up on a website or hallway monitor and show it in real time. Buy some nerf weapons, dinner gift certificates, or even some X-box video games, and have them visible at HQ – give them away as prizes, or set up a betting pool: $10 per person, and the winner gets the pot. You can get fancy and have special prizes for most twisted bug, the bug least likely to ever get fixed, etc.
• Create rival teams. If you are totally poor, use ego prizes. Have the designers challenge the programmers, or the marketing team challenge the management team. Throw down: “I’ll bet the whole marketing team dinner at Ruth Chris’ my 3 reports can find more bugs than your whole team can”. If you don’t have cash, bet embarrassment: loser shaves their heads, has to dress in costume the next day, has to wash the opponents cars, etc. Get two sets of people who have some built in animosity or rivalry, especially if it’s well known, to openly challenge each other. This rivalry will draw more people in, if only to follow along. Do this once and you’ll have a tradition to build on for the next bug bash.