Benefits of organizing a bug bash with your team

Organizing a bug bash takes quite a lot of effort.

You have to book a room, reserve an entire afternoon off, gather enough people, provide enough testing devices, order enough pizza, etc., etc.

Since these events can be time-consuming to put together, you might ask yourself if they’re even worth the effort.

After all, how many bugs can one realistically expect to find in such unstructured testing?

This article is here to convince you to organize a bug bash regardless. Its pros far exceed its cons, and you’ll be doing your entire organization a huge favor.

Continue reading to find out why.

Uncovering high-priority bugs before release

The main objective of a bug bash is to uncover as many software bugs as possible. As such, the event is often held right before a release.

That way, participants unearth errors before the new build goes live.

By organizing a bug bash early enough (e.g., one week before release), developers have time to debug, ensuring high-quality software is delivered.

Therefore, a bug bash raises the quality of your new build simply because it can uncover high-priority bugs that would have otherwise crept into production.

A bug bash can reveal countless new bugs—minor and major. To address the critical issues, your team must categorize the defects, separating high-priority bugs from low-priority ones.

Here’s a simple yet effective triage process:

By simply sticking post-its on a whiteboard, defect sorters isolate errors that require immediate attention from the five-minute fixes.

With this strategy, your developers have a clear overview of bugs that need their attention.

If you’re unsure how to differentiate the high-priority bugs from the lower-priority ones, ask yourself the following questions:

If the bug affects many users or appears on several devices, it should be treated as a critical issue.

The same applies to the functionality it’s impacting. If your application crashes at checkout, a universally important feature, the error can be considered high priority.

Finally, if the bug carries legal implications or will likely influence your users’ trust, it should be addressed soon.

All of the above examples are high priority bugs, which a bug bash will hopefully uncover and therefore ensure a smooth, bug-free release.

Finding different types of bugs

Development isn’t the only department participating in a bug bash. The event is often a company-wide effort, including non-technical departments such as Marketing, Sales, etc.

Given the various expertises, each employee will have a different perspective while examining the software.

A developer likely won’t notice the same features a salesperson would because they specialize in separate areas.

Because of these unique approaches, a bug bash usually uncovers many different types of bugs.

Consider the screenshot below. Would you know how to navigate to other pages within the Benchmarks tab?

Klaviyo’s developers knew how to do so, seeing as they developed the feature. The secret lay in clicking the downward-facing arrow next to the Overview tab.

However, finding it wasn’t so easy for their colleagues, as they had difficulty spotting the arrow. They discovered a usability bug the developers had missed.

As you can see, although the developers didn’t notice any issues, users would. That’s why bug bashes are beneficial—they reveal bugs that would otherwise be overlooked.

Kent Beck remarked on this, highlighting different perspectives of quality:

Bug bashes combine both metrics. Developers and testers will notice incompatibilities between browsers and other codebase errors.

However, non-technical attendants will comment on usability issues, loading speed, and other external quality metrics.

In sum, a bug bash has the potential to uncover every type of software bug.

Once your attendants stumble across an error—whichever type—they’ll need to report it. For that, it’s worth investing in a bug-reporting tool like Shake.

With Shake, simply shake your device, and a comprehensive bug report will immediately be sent to the developers.

Here’s an example of a bug report:

The report contains everything the developers will need: screenshots, screen recordings, steps to reproduce, network specifications, app version, etc.

This tool significantly improves the productivity of a bug bash, as it allows participants to report bugs—all types of bugs—effortlessly.

Discovering more bugs in less time

Discovering bugs is usually a task reserved for the QA team. However, there are only so many testers, with only so much time devoted to bug-hunting.

After all, testers also report to stakeholders, perform requirements analyses, and more. With these additional tasks, finding bugs can drag on.

This is another benefit of a bug bash—they reveal many bugs in a short time period.

Bug bashes are always time-boxed, typically lasting an hour or ninety minutes.

The event brings together a room full of people and has them concentrate on finding bugs—only on finding bugs— for the allocated time frame. Therefore, the results are usually impressive.

Look at the outcome of this bug bash:

One hour was enough to resolve nineteen bugs and log another eighteen of them. These dramatic findings prove the bug bash was productive.

When organizing bug bashes, this is how that one hour is normally structured:

The first five minutes are typically used for instructions and sometimes a brief Q&A session.

These are followed by forty minutes of concentrated, exploratory bug-hunting.

The event ends with a debriefing session, where everyone explains the bugs they found, and a final tally is recorded.

There’s not even a full hour devoted to bug-hunting itself. However, participants often produce impressive results regardless.

To really encourage quick bug-finding, consider equipping your attendants with a tool like BugMagnet—an exploratory testing tool that facilitates testing user scenarios.

The resource adds common problematic values and edge cases to the context menu, making it easy for your participants to check situations where issues might arise.

Here’s the tool in action:

Instead of brainstorming possible problematic scenarios, this tool hand-feeds them to you. Your attendees won’t lose time devising potential situations.

On the contrary—they can quickly zip through all the offered scenarios and speedily determine if there are any bugs.

Encouraging friendly competition

Bug bashes are collaborative events where employees from every department are invited to find bugs. By enlisting everyone’s help, the product is improved.

However, despite this cooperative environment, you can also encourage friendly competition between team members.

For example, many bug bashes distribute titles recognizing their participants’ achievements. This is how Kantan operates—look at how many rewards they issued:

With these awards, the company subtly creates a competitive atmosphere, thus motivating its bug bash participants to do their best.

There are plenty of awards that help create this stimulating environment. Here are the most common ones:

Most bugs found goes to the most productive individual, whereas Best team is for the group with the best results.

Speed is rewarded with the First bug found award, and whoever locates the weirdest error receives Most unique bug.

The Bug least likely to be fixed award is usually given to whoever finds the most minor bug, whereas the Most severe bug acknowledges the most serious error.

However, these titles are only half the story. Once someone obtains this acknowledgment, it’s also worth handing out tangible prizes. That way, there’s an additional incentive for competing.

The prize doesn’t need to be extravagant. A simple lunch voucher, an Amazon gift card, or maybe a bug plushie is sufficient.

When Dukka hosted their bug bash, they also distributed prizes, as shown below:

Although it’s likely that only Gabriel knows what the prize is, at the end of the day, the actual object is less important.

What matters is what the prize stands for—a job well done. That’s what your participants are vying for: recognition.

In other words, the rewards you hand out encourage attendees to compete against each other and do their very best.

Improving cross-team collaboration

Bug bashes aren’t restricted to a single team. Every employee can attend, from interns to C-level executives.

Given how wide the participant pool is, the event is perfect for improving cross-team collaboration.

Try to prioritize inviting new hires to the event precisely because it fosters this type of collaboration. Newcomers might still feel out of place, and the bug bash could help relax them.

Misha Abasov also recommends this:

Pro tip: Invite the new person, someone who’s recently joined your organization. It’s a great way to engage them, entrench your values, and help them connect with more coworkers.

His tip makes sense, as bug bashes are often light-hearted, fun occasions (there’s often pizza, too). It’s the perfect chance for newcomers to bond with their new coworkers.

For example, a bug bash is a great opportunity to teach that new hire and anyone else how your organization reports bugs. After all, participants will report bugs as part of the bug bash anyway.

Using one single platform for bug tracking greatly facilitates debugging.

All errors will be logged in a designated space, meaning no bugs will be left unnoticed in your emails or instant messages.

This topic was also discussed in a Quora thread:

A bug bash is perfect for explaining your bug-tracking software, as the event will require the use of the tool anyway. However, you’re also improving later cross-team collaboration.

Bug bashes can bolster cooperation even when done remotely. For those events, open a dedicated Slack channel.

Bug bash participants can use that space to share funny errors, despair over critical issues, and debate whether something is a bug or not.

For example, Vivaldi employees had to seriously discuss whether they had found a bug or a feature:

These are the type of entertaining conversations you can expect during a bug bash, especially for non-technical teams.

Even though everyone isn’t physically present, Slack still enables the same atmosphere of collaboration, as teams share knowledge and work together to improve their product.

Learning more about the product

Bug bashes are often categorized as a form of exploratory testing, similar to ad-hoc testing.

And testing, according to Brijesh Deb, is defined as:

Learning about a product goes hand-in-hand with testing it. After all, how can testers evaluate if the software is working correctly without knowing what working correctly entails?

During the bug bash, your participants will likely discover an unknown (to them) component. For example, why would an HR manager know all the different possible integrations?

However, the HR manager will still have to examine these unfamiliar product sections.

As a result, they’ll also learn more about the product to determine what constitutes a bug and what doesn’t.

IBM utilized a similar approach, as explained below:

In these bug bashes, Tom Ellingwood prioritized communication and collaboration.

All attendees were encouraged to speak to their colleagues and learn about a specific software component before reporting their error.

It was emphasized that fully understanding the product was essential to creating a helpful, informative bug report.

However, if that bug bash had never been organized, the participants wouldn’t have investigated further and wouldn’t have learned anything new.

In this way, the bug bash taught its participants about the product they were examining.

The participants that will likely learn the most are your non-technical peers. As such, ahead of the bug bash, it’s a good idea to provide some support, a way to answer their inquiries.

Your attendees will grasp the software more quickly with a subject matter expert available for consultation.

Alternatively, some well-written supporting documentation can also efficiently teach participants about the software.

In any case, either option will help the newfound testers find bugs, enabling them to simultaneously also learn more about the product.

Conclusion

Organizing a bug bash pays off in the long run. Although primarily designed to uncover bugs and therefore improve your product, these events have several other significant benefits.

For starters, they’re excellent for improving cross-team collaboration and can even inspire friendly competition.

A bug bash is also an opportunity to learn more about your product while uncovering high-priority bugs before release.

Finally, it’s a fantastic medium for discovering a wide variety of bugs quickly.

Considering all the advantages a bug bash offers, hosting one is never a bad idea.