5

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.

Improve this question
1
  • Cash incentives are always motivating. Especially in today's economy. ;-)
    – Cody Gray - on strike
    Feb 12, 2011 at 6:15

4 Answers 4

Reset to default
7

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.

Best of luck!

Improve this answer
1
  • 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.
    – Britt Wescott
    Feb 13, 2011 at 2:12
2

Public recognition though some kind of ceremony works. Give a can of Rockstar(TM) energy drink to the best in each department and then the best overall.

P.S. Of course money works too (e.g. gift cards). P.S.S. Sounds fun - let us how you handled it and how it went.

Improve this answer
2

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:

  • bug basher 10 (find 3 bugs in 10 minutes)
  • none-of-your-business bug basher (find 3 bugs in areas of not owned expertise, say programmer find a flaw in graphics, or something else)
  • been-there-done-that bug basher (found a bug that someone has found before)

The titles are limitless here. Achievements can have a shape of t-shirt, framed photo or a mug with appropriate text/image on it.

Improve this answer
0

Ring a bell whenever the 1st, 2nd, 4th, 8th, ... bug is found.

Improve this answer
1
  • 1
    Might consider that, if there are a lot of bugs, this could have a negative effect on team morale
    – frogstarr78
    Feb 12, 2011 at 20:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.