How to conduct a successful Bug bash

What is a bug bash?

A focussed, time bound event, in which testers, developers and other employees from various specialities are solicited to find bugs in a product. Core product team members facilitate and triage the bugs.

DO’s for a successful bug bash

Clear definitions of the scope
Understandably not all products can be defined with in a scope. As noted one of the chief motivations for a bug bash is to bring inputs from various kinds of viewpoints. One way to remedy this is to point to the existing bugs that the core team has identified in past.

Advanced communication and schedule — This will help external users schedule accordingly. Send an outlook event 3–4 days prior to the event.

Clear instructions to file bugs — Tell users how to create a bug, which database, which labels etc. Each team follows a different practice so be sure to be clear here.

Communication during the bash — Don’t expect users to follow your instructions in calendar invite, many of them will try to figure things during the event or will have additional questions. Keep communication lines open, a lync group chat or slack channel work best.

Encouragement and participation from managers Show participants that management is bought into this idea and their time invested is not only granted but encouraged.

Rewards and motivation Tap into the vanity of people. Give them something to work for. A trophy, gift card or other perks and bragging rights works best. Also have different categories of prizes — most filed, most affective, security fix etc.

Timely triage and conclusions A successful bug bash can expect about ~100 bugs, going through many of the duplicates, understanding repro steps, asking clarifying questions can be a pain. But you have to do it fast (3–4 days) and send out conclusions to ensure your users will be motivated in future events.

DONT’s for a bug bash

• Don’t do bug bash as a remedy for not having a test team. The focus a tester brings is at a completely differently level. This is an ad-hoc event that will aid in testing but it is not a replacement
• Don’t ask for a larger audience time — limit an even to an hour or less.
• Closing a bug as NOT A BUG is a sure way to ensure that this external user will never participate in your future bashes. Add a comment and/or mark it as Won’t fix. Show some respect for the time vested.
• Another way to close a bug that I don’t like is to say not a requirement. That may be true and you could lower the priority of the bug, just like you would for a customer request.

Bug bash is not dog fooding

Dog fooding is an extension to a bug-bash, it is asynchronous. Users get instructions and they are free to play with the product at leisure. It happens over a period of days and can be happening continuously.

Many of these ideas are borrowed from successful bug bashes lead by manager, PD.