The term bug bash has been around for decades yet does not seem to have a formal definition. It is widely used and understood by many people, yet in two distinct ways. Over the years, I’ve participated in and organized two different types of bug bashes with different goals and results.
A bug bash could refer to one of two activities:
- A time-boxed event where you bring in people from inside and outside of the development organization to ad hoc test the application to find as many bugs as possible in the time given.
- A time-boxed event where a software development team focuses on fixing as many bugs as possible in the time given.
Both types of bug bashes have a few things in common: they are time-limited, focused on bugs, and typically occur outside the normal development process or cycle. Each option has its own benefits and drawbacks, but both can benefit your team if done well.
Bug bashes focused on bug hunting
This is likely the most common use of the term “bug bash,” and it was also my first experience with it. It is a lightweight way to uncover many potential issues quickly and without requiring much effort to organize.
All you need is some people, an environment to test in, and some way of documenting the findings, such as a bug reporting tool. That’s it. Anything else is a bonus, even if the lure of pizza and beer might increase your chances of getting participants.
The primary purpose of this exercise is to find as many bugs as possible in a limited amount of time. When well planned and executed, bug bashes can promote knowledge sharing, relationship building, and overall quality improvements. Even a poorly planned bug bash can be a net positive (you’ll certainly find more bugs than usual), but a genuinely successful bug bash builds camaraderie amongst team members as well.
To make sure you reap all the benefits of a great bug bash, start by identifying the when, why, who, and what.
When should you schedule a bug-hunting bug bash?
First, the product must be at the right stage for a bug bash. You don’t want to hunt for bugs too early, as many features might not be ready for testing. Make sure you have key functionality set up in a testing environment before diving into a bug bash.
For scheduling, you need to find a time when people will be available to attend. Doing it during office hours will increase the attendance of some groups, while others might be more likely to attend if you run it as an event after work with some food and beverages. Depending on your context and culture, this will differ, so spend some time figuring out the best approach.
Talk to team leaders across your organization to find a date and time that works for most people. Even if everyone can’t attend, proactively having these conversations will encourage more people to participate in testing efforts and make teams feel heard and valued. The key is to make this an invitation rather than a mandatory event — trying to force people to participate will only cause friction.
It’s also important to plan for time to process the actual results, preferably as soon as possible after the event. You can’t schedule a bug bash two days before a big release and expect to be able to fix the problems you found. You’ll need time to review the results, find the critical bugs and interesting problems, prioritize everything, and implement fixes. The timeline will depend on how deep you go with the bug bash.
For example, when I ran a small bug bash with an experienced crew, the results were sorted and roughly prioritized within the same day. When running my largest bug bash, however, we spent an entire day reading through, cleaning up, and grouping the findings, which included two release-stopping bugs. In the first scenario, we could release as planned, while the second scenario required an additional two weeks of work because we had to rethink the flow of a core feature.
As you get more experienced with bug bashes and your team, you’ll find a cadence that works well for you.
…
This is a snippet of an article I wrote for Qase. Read the article here.
