How to run a bug bash

No matter how much planning, documentation, and overtime you do, no product is ever perfect straight away.

In the pursuit of perfection, teams hunt for any errors that might interrupt the user experience — broken links, functions that don't do what they are meant to, buttons that lead people astray, etc.

One popular form of team bug hunting is called a bug bash. This article will show you how to run one!

Let's go! 🚀

What is a bug bash?

A bug bash is a team event where teammates get together and all use the product rigorously to find bugs. Think of it like a treasure hunt for bugs. 🙃

A typical bug bash lasts from 60 to 90 minutes, and in an IRL office, you would normally hold them in a meeting room, and in a remote team it's common to run them on a video call or async in a chat channel.

Typically, teams hold bug bashes at the end of the System Development Life Cycle (SDLC) before a feature ships to users. But, some teams hold them at recurring intervals weekly or monthly.

Bug bashing benefits

• They can help you identify many bugs and improvements in a short time-span.
• It's an awesome, unique opportunity for the whole team to work together (especially those who don't typically work together day-to-day).
• They help people without a development background learn more about product development
• It gets everyone on your team more familiar with the user experience and aligned on ways to improve it.

Bug bashes are not a replacement for product testing or quality assurance. They are another tool in your team's tool belt.

How to run a bug bash

Never fear. We are here to help. Follow the five steps below for a fruitful bug bash:

Step 1. Decide who to include and give everyone a role

You can't plan a party without guests, so start by writing down everyone you should invite.

Bug bashes are not a developer-exclusive event — they typically include everyone involved with the development of your product. Here's a shortlist of potential people to invite:

• Product developers
• Engineers
• Product testers
• User Experience (UX) designers
• Marketers
• Web developers
• Managers (your CFO, CEO, CIO, etc.)
• Interns and students

Next, you need to decide what role everyone will play in your bug bash.

The first role you need to fill is that of the moderator (probably you!). The moderator will lead the event, provide instructions, and answer questions throughout the event. If you are organizing the event, you should be the moderator.

The second role you need to fill is that of the stager. The stager is responsible for organizing the test environment and keeping it live throughout the bug bash. Select a member of the development team for this role.

The third role you need to fill is that of the notetaker. The notetaker is responsible for making sure bugs are documented properly.

(Though, if everyone at the bug bash downloads the Jam Chrome extension, then they can file bugs to your issue tracker of choice as they go, and no one needs to take notes and file tickets later)

Everyone else involved in the event is a tester (most important role!).

Step 2. Schedule your bug bash and define its scope

As bug bashes involve people from multiple teams, you'll need to plan them well in advance. Ideally, you'll want to schedule your bug bash a week ahead at least.

During this stage, you should also define your event's scope. Your bug bash is only a short event, so you likely can't test your product's full functionality. Focus on the newest or most important features (most likely the ones about to ship), and schedule a separate bug bash for the rest. It might help to write down functions that are "in scope" and "out of scope." Otherwise you will get a lot of bugs reported that are outside of the product team's current focus.

Step 3. (Optional) Write test cases

Most bug bashes are informal, and participants go through the product ad hoc looking for bugs.

Some teams prefer to bash through existing test cases to make sure everything is covered, often using chrome extensions for developers to streamline the process.. Write these in advance to maximize your productivity during the bash.

Test cases give step-by-step instructions for testers to follow. To write a test case, create a similar table to this. We've added an example of a typical test case for you.

You should leave the final two rows, "actual result" and "pass/fail," free. Testers will fill these out during the bug bash. (If they use the Jam chrome extension, they can quickly get a link to paste with a screenshot or video plus developer debugging info for failed tests)

Step 4. Establish a bug reporting process

Some of your test cases will be successful, but others won't (😢). And, when testers find bugs, you'll want to get as much information about it as possible so your team can resolve it.

That's where a bug tracking tool like Jam comes in. Jam is a Chrome extension that testers can use to take a screenshot, record a video, or share a rewind of a bug that just happened. It's the fastest way to capture and send bugs to any tracking tool like Jira or a Slack channel during a bug bash.

To use Jam at your next bug bash, participants will need to add the Jam chrome extension (it's free) at Jam.dev. Then, create a place for people to send their bug reports — like a Slack channel. And testers can quickly send bug reports there with Jam!

Step 5. Run your bug bash

Before you know it, the day of your bug bash will be here. So what exactly happens? Bug bashes have three stages:

🙋‍♀️ Stage 1. Introduction

For the first few minutes of your session, you'll need to show testers what they'll need to do, including how the bug bash will work, what to test, and how to report bugs they see.

🐛 Stage 2. Bug hunting

Then, the bug bash can really begin. Give your participants about an hour to bash through the product and hunt for bugs.

To set the vibe, you might want to play music 🎶 and set up spaces for people to sit and collaborate. Maybe even bring some snacks 😋.

🪞 Stage 3. Reflection

For the final 10 minutes of your session, gather everyone together so people can share significant bugs and reflect on the experience. For fun, you can gamify the event by handing out awards to the best bug catches, if you want.

And that's it! You've run a successful bug bash. Kudos! 🥳

Bug bash best practices

No one starts out as a bug-catching expert. But you can run a smoother bug bash by following these best practices:

• Limit the scope of what will be tested and commented on
• Put on some music and create a welcoming environment where people feel comfortable making suggestions for product improvements. The best bug bashes are casual, welcoming, fun, and productive.
• Help people create actionable bug reports (so that engineers don't need to chase folks for more follow up info later). (One easy way to do that is use Jam so that every bug report automatically includes all the info engineers need.)

Hope you have a great bug bash!