I am trying to put together a bug bash at my office and I was what was the best way to conduct it.
Ideally, I'm looking for the most effective way to manage testing and provide the staff with incentives to find relevant errors.
Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.Sign up to join this community
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:
Oh - and lots of nice munchies, and coffee/tea and soft drinks on hand help a lot.
Best of luck!
If staff is not interested in fixing all possible bugs in the product they work on (without incentives, that is) - I don't think staff is good at all.
Aside that - think of some achievements to them:
The titles are limitless here. Achievements can have a shape of t-shirt, framed photo or a mug with appropriate text/image on it.