4 Answers
4

What's your goal for the bug bash? Think carefully about what you want to get out of it, and plan accordingly. (I'm assuming that your bug bash is including people outside the tech team too, and that's how I've answered below.)

For example, if you want to use it mainly as a chance to get everybody in the company together for a couple of days, to build company morale & encourage people to feel they're all on the same team, build relationships between tech and the rest of the company - but you're not really expecting to get a lot of usable input out of it, then you probably won't be worrying too hard about the following issues:

Volume: Prepare to be BURIED in bug reports. Especially if you give incentives for number of bugs reported. You may find on review that a lot are duplicates, but you'll still have to sift them to find out.

Quality: Writing good, reproducible bug reports is hard. Professional testers work on this skill constantly, but here you're going to be getting a lot of non-professionals in, who have no real understanding of what a dev might need to see. You may get a lot of reports of the "I clicked on the page and it DID NOT WORK!" level of quality. (Seriously, I have seen reports from non-testers where that was pretty much the whole report.)

Boredom: Non-testers often run out of test ideas pretty quick. People will start off with plenty of enthusiasm, but excitement will pall after a few hours. Especially if your app is not stable, and blocking bugs prevent people accessing stuff.

Focus: You could get a ton of useful usability feedback from people, but you should not expect a bug bash to cover all the aspects that you might want to test in your application. I'm pretty sure you know this already though - it should already be reasonably well tested and beta-ready before you go for a bug bash, IMHO.

You can mitigate these issues:

Get your testers and programmers to
give a quick, very simple walkthrough
of what a good bug report looks like, and why it's useful.

Group people into teams - make sure
each team has a tester (ideally), or
programmer assigned as a point of
contact. When people find a bug,
they grab their team's tech, who can
walk them through repro steps and
help them report the bug in a form
where it'll be useful to you later.

Make sure you've got some kind of half-decent bug tracker available, so you can log bugs, and search to see if it's already been logged. (Again, the teams will probably need a bit of help on hand to figure out good search terms). That'll reduce the duplicates.

Start off with a couple of hours
unstructured playing with the system,
you can learn a lot from what people
have picked up, and what they didn't
manage to figure out. When people
start running out of steam, have a
few more structured missions for them
to try out. (Read up on the idea of
tours, or exploratory charters). Focus these on areas that you particularly want additional feedback on.

Encourage reporting, tagged separately if necessary, of things that aren't bugs per-se, but "issues". For instance, someone may find a problem that doesn't actually count as a bug, but is actually very valuable feedback. Don't dismiss these just because they don't fit into the bug category.

Oh - and lots of nice munchies, and coffee/tea and soft drinks on hand help a lot.

Thanks @testerab, great suggestions. My goal at this point in the software development process is not to find every minute issue with the application, I am only interested in finding bugs that prevent the software from functioning properly. I will be using non-development staff for the bug bash, and I would like them to try to go through actual client scenarios for how the software will be used in the field.
–
Seth P.Feb 13 '11 at 2:12