“Imagine a day where a crack cross-functional team at your organisation comes together to test a product you helped make, not just to find bugs but also to improve its value…”
What's a bug bash?
Ever want to make a party out of testing? A bug bash can help you do exactly that! Well, it's not all fun and games; usually, the strongest beverage available is black coffee, and you probably won't want to hire a DJ. But you can have some fun and learn some important things about your product and quality in the process.
Bug bashes enhance collaboration, provide diverse perspectives on your product, and help build and reinforce quality culture. A bug bash usually looks something like this:
- You invite a cross-functional team: testers, developers, product owners, designers, stakeholders. Maybe it's just your product team, or perhaps you want to invite some folks who don't usually attend your team meetings, like legal or marketing.
- Make sure to invite some folks who haven't yet used the product (or haven't yet tried new features).
- You set out some guidelines for how to test the product. Just as at a social party, you need to be a good host, and setting out clear guidelines and expectations is part of that.
- Make it fun! Gamify testing (some tips below).
- For a few hours or maybe even a few sessions of a couple of hours, the team focuses on testing the product, following the guidelines you laid out.
- Make sure to include break times.
- Snacks and drinks are always welcome, too.
Preparing for the bug bash
Make yourself a template
It's a good idea to create a reusable template for bug bash planning, because once you host one, chances are there will be more in the future. You can always tweak the template, and eventually, you will end up having a great list of bug bash planning ideas to refer to. Creating a template will also make it easier if anyone else in the organisation is willing to facilitate a future bug bash.
Our template contains sections for:
- Explaining the what and why of the bug bash: define the purpose
- What is in and out of scope
- Test charters that can be used by pairs of testers
- Test data and environments
- Instructions for reporting bugs
- Blank sticky note templates that can be filled by each pair of testers:
- the names of the testers,
- their test charter,
- note-taking instructions to capture problems, questions, ideas, and praise (see What Is Exploratory Testing? PQIP: Four Simple Words To Level Up Your Testing Efforts)
Do your homework on the technical aspects in advance
A structured approach makes all the difference. For one bash, I collaborated with a developer to prepare everything we’d need: test data, risk-based test charters, and links to tools like CloudWatch, Lambda functions, APIs, and DynamoDB.
When creating test charters, we focused on the "why" - identifying high-risk areas and expected outcomes rather than defining exact test steps. We even explored how the front end consumed our APIs to understand real-world use cases, ensuring our charters reflected practical scenarios. Input from the product owner also shaped the charters, helping us align with business goals.
Create solid test charters
Test charters are critical for good bug bashes. They help participants focus on the "what" and "why" of exploration, and they provide enough structure to outline goals while leaving room for creativity and discovery. This balance was especially important in our context, where we needed participants to understand what to explore and why without constraining them to rigid instructions.
The test charter below is an example from a Restful booking application:
Explore the /booking endpoint for creating new bookings
With different combinations of request payloads (valid, incomplete, invalid data types)
To discover:
- The minimum number of required fields to successfully create a booking
- How the API handles invalid or unexpected data types
- The default values for fields not provided in the request payload
Inviting guests
Once everything is prepared, send an invite to all the participants and give just enough detail about the plan and the charters. You can get into more detail at the beginning of the bug bash itself.
Bash day! What to do and expect
Starting the bash
Before the bash begins, go over each section of the bash plan so everyone understands what is expected. Pair your attendees off and assign them test charters.
When I run a bug bash, I start the session by setting the context and giving all the participants an option to pick the test charter, create their own test charter, or just explore. This allows all participants to have the opportunity to explore any feature or section they’re curious about.
During the bash: party games!
Once everyone has gone over the features, they can get to work. Ideally they will find bugs and raise questions where more information is needed, following the charters you provided to them or by exploring on their own.
To make the bash engaging and fun, try these ideas:
Leaderboards: Display “Most Bugs Found” or “Best Pair of Bug Hunters”
Prizes: Offer rewards like gift cards or vouchers. For example: £50 gift card for "Most Creative Bug," a trophy for the "Best Pair of Bug Hunters"
After the bash
Ask each pair to debrief the group on their findings. This can help stimulate the sharing of ideas and suggest other areas to explore.
At one of the bug bashes I hosted, we identified at least 18 bugs, of which seven were critical and five were of medium severity. And we made eight requests for clarifications on requirements. Out of these, three were converted into requirements that were missed during implementation, while five remained open questions that the product owner needed to discuss with the business stakeholders. We did all this in a two-hour bug bash.
To wrap up: our experiences and moving forward
Organising the bug bash was easier said than done. Some team members were unsure about its value, questioning whether it was worth the time, while others struggled to see how it could work for a back-end product. With no UI to test and APIs that were consumed by a front end owned by another team, it was hard to imagine how we could engage participants and uncover actionable findings.
The biggest challenge was ensuring participants could truly explore rather than just follow instructions and tick checkboxes. Bug bashes succeed with creativity and uncovering unexpected behaviors, but with only APIs, workflows, and back-end logs, I had to strike the right balance between guidance and freedom.
Even with the challenges, though, the bash participants understood the benefits of the session. And our team now holds regular bug bashes as a result.
For more information
- Two Heads Are Better Than One: The Benefits of Pair Testing Across Disciplines, Anneliese Herbosa
- What Is Exploratory Testing? PQIP: Four Simple Words To Level Up Your Testing Efforts - Simon Tomes
- Testing Treasure Maps: The Art of Crafting Charters, Jenna Charlton
- The Awesome Power Of The Debrief: Why Debriefing Is The Key To Successful Exploratory Testing, Callum Akehurst-Ryan
.jpg)
