A bug bash, much like any coordinated effort, requires planning. Here’s a guide on how to get the most out of everyone’s time.

Preparation

Step 1: Collect your use cases

This is where you scour all the documentation that has been generated – via wiki, tickets, discussions, meetings, designs, etc – and capture the use cases that your feature needs to satisfy. In a perfect world, this is a collation effort; in an imperfect world, you’ll be writing them by exploring your application.

Step 2: Write Scripts

Every use case above needs to be distilled into a simple, easy to follow script for an uneducated user from a different team to follow. Assume that they have zero context, and that they only read english (and don’t understand nerd). Each script should complete a single task, and should take no longer than 10 minutes to complete. This time constraint gives each participant space to explore your feature and discuss what they’re seeing.

The purpose of the scripts is twofold: First, it focuses the attention of attendees. Secondly, it removes discussion about ancillary topics such as “how do I log in”, and generally makes everyone productive.

Step 3: Prepare meeting resources

You will need the following resources before the bug bash.

• A home, or identification schema, for tickets created during the bug bash. These will come hard and fast, so make sure you either have a parent ticket, or a tagging scheme, ready beforehand. It can be as simple as the “bug bash” tag.
• A backchannel. Whether a chat channel, a video conference, or smoke signals, you will need a place for participants to discuss what they’re encountering.
• A Ticket format, which participants will use to report issues discovered in the bug bash. Each should include:
  1. The name of the script
  2. The step in which the issue was encountered
  3. The name of the person who found it if other than the reporter
  4. Whether the reporter thinks it’s a release requirement or not
  5. Expected behavior
  6. Actual behavior

Step 4: Prepare testing resources

In order to satisfy the constraints of each script, you need to create the input resources necessary to complete that script. This might include:

• User accounts with specific access rights.
• Images to upload into the system.
• API Keys to access the system with
• Postman collections by which the system can be tested
• Prepopulated integrations (if your product posts to slack, for instance)

Each of the above should be directly added to the relevant script.

Step 4: Appoint a moderator

The moderator’s job is to answer functional questions while the participants are following their scripts, and to keep the conversation from going into the weeds and distracting other participants. Before the bug bash, make sure that this individual is deeply familiar with the feature.

You may also want to appoint a scribe, who’s job is not to file all the tickets, but to have a deep understanding of outstanding work and thus intercept duplicate issues in real time.

During the Bug Bash

1. Start promptly. End promptly.
2. Demonstrate how to report an issue using the above scheme. Remind everyone that you can’t read their minds, so please document each issue extensively.
3. The strategy for a bug bash is “report as many issues as possible”, duplicates will be sorted out later.
4. Assign scripts. Every participant should get 1 script for every 30 minutes of time scheduled, and try to get each script assigned to at least two participants. If a participant finds they have extra time, they are welcome to explore.
5. Go find your bugs!

After the Bug Bash

Immediately after the bug bash (to avoid forgetting details), the moderator and any scribe should triage all the issues that were reported. Each issue should be evaluated for:

• An accurate, reproducible description of the issue.
• Duplication (best description wins)
• Priority

Offer prizes!

To really encourage the filing of many issues, you can offer prizes for the most non-duplicate issues reported!