What is a Bug Bash? And how do you run it?
So what is a Bug Bash?
Bug Bash literally means to hunt for bugs. Bug Bash is a collaborative team effort where a cross-functional team aims to find as many bugs as possible in a product they develop. My understanding is actually quite close to what is stated in Wikipedia. So the idea of a Bug Bash session is to find as many bugs as possible in a time-boxed period. Usually, a Bug Bash is conducted prior to a release, when a development team wants to identify the most critical bugs and fix them. I prefer to conduct a Bug Bash one sprint before a release. So this last sprint is fully devoted to bug fixing.
Benefits of Bug Bash
You find lots of bugs. As a result of a Bug Bash meeting, you will receive various unprioritized and uncategorized bugs in your product backlog.
The team learns about a product. This might be a great opportunity for team members who are not that close to development to get acquainted with new functionality prior to a release.
Strengthens relationships between teammates. This event is a way for your team members to go outside of their normal responsibilities.
What I also find very important is that Bug Bash gets you fresh eyes on a product. Inevitably, a development team loses the “beginner’s eye” along the development process. They cannot tell if a feature or workflow is easy to use and an interface is predictable. So you might end up receiving some useful enhancement advice or feature requests for your product backlog.
What does it take to run a successful Bug Bash?
Step 1: Collect a team
A successful Bug Bash team should be cross-functional. I try to bring designers, developers, testers, customer support, product managers, etc. to test a product from a variety of perspectives. Since different roles are conducting testing, it is more likely a product will be tested in different ways.
Step 2: Assign a moderator
You need to choose someone who is very well familiar with a product. The moderator’s job is to answer the Bug Bash team’s questions and keep the conversation from going into the weeds.
Moderator can also take notes on some useful feedback received from the team. They might report some enhancements or even features.
Step 3: Collect your use cases and write scripts
Set up a document and provide the basic instructions for your Bug Bash session. Add use cases you want users to complete. Every use case needs to be decomposed into a simple, easy-to-follow script for an uneducated user from a different team to follow. Assume that they have zero context.
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.
Step 4: Testing resources
Make sure the testing team has the necessary testing resources to execute each script. Those need to be created in advance and added to each script if necessary. An example of such testing resources might be:
- A user account with specific permissions
- Files to upload into the system
- API keys
- Postman collection
- Prepoulated integration. For example, your product requires integration with third-party software for some features to work.
Step 5: Define a process of filing bugs
A Ticket format, which participants will use to report issues discovered in the Bug Bash. Each should include:
- The name or ID of the script
- The step in which the issue has been encountered
- Reporter
- Whether the reporter thinks it’s a release requirement or not
- Expected result
- Actual result
Step 6: Post Bug Bash, evaluate results
Right after the Bug Bash is completed, the moderator should triage all the defects that were reported. The moderator should evaluate issues for:
- An accurate description
- Duplication
- Priority
Pro tip: reward participants
Prizes are a great way to motivate a team to do the Bug Bash and it brings a competitive spirit. You can reward a person who contributed the most bugs (non-duplicate ones), or the one who broke your product in the most unusual way.
