How to run a successful bug bash

A bug bash is a team or company-wide effort to track down as many software bugs as possible.

Participants block off their afternoon to sit down and explore the company’s products as thoroughly as they can.

By unearthing so many bugs, developers have a good chance of thoroughly preparing the product for release.

Instead of customers reporting problems, the issues are brought to light before deployment.

However, for such an event to be effective, it should be well-organized and run smoothly. That’s what this article is for—to show you how to best run a successful bug bash.

Set a clear date and time for the bug bash

Bug bashes are long events involving at least one team. Considering the many participants and the prolonged time period, you can’t host one on a whim.

Therefore, to ensure plenty of your colleagues attend and you have enough time to bug-hunt, it’s essential to set a clear date and time.

Try to communicate the date and time at least three weeks before the event. That far in advance, most schedules won’t have filled up yet.

The easiest way to convey the date and time is by using a scheduling tool. For example, Calendly allows you to create group events that can be distributed to multiple people.

Here’s a sample group event:

The location and time are clearly stated, and you even have the option to set a maximum number of participants.

After your invitees accept the event, they can then add it to their calendars. The option will appear in the following e-mail:

With the event in your attendees’ calendar, they’ll have a clear reminder of the bug bash.

Most bug bashes are an hour or ninety minutes long. However, these are suggestions, not steadfast rules. For example, Notion’s bug bash was much longer:

The company turned its bug bash into a five-day marathon. Although not the standard recommendation, it worked for Notion.

Try timeboxing your first bug bash to ninety minutes and then tweaking the time limit however works best. But whatever timeframe you decide, ensure it’s clearly communicated on time.

Convince influential team members to participate

A bug bash is usually a voluntary event. All employees can attend, so in theory, you should have plenty of bug-hunters.

However, bug bashes take your colleagues away from their regular work.

Not everyone will forsake their tasks to search for bugs, and non-technical employees might not understand the event’s benefits.

This is why it’s crucial to convince influential team members to participate. When your colleagues see senior employees attending the bug bash, they should realize its value.

After all, the event must be important if a manager makes the time to participate.

This realization should incentivize other employees to follow in their managers’ footsteps and also join the bug bash.

For example, here’s a tweet from Ahmed Al-Balaghi, the co-founder of Biconomy:

His excitement clearly comes through. When employees see such enthusiasm from their senior leaders, they are likely to be motivated to participate themselves.

Some team members go one step further than simply participating—they document and market the bug bash.

Farah Hawa is a Team Lead Security Operations at Bugcrowd, and she took the time to record a recent bug bash:

Her video recording (or vlog) is a great medium to showcase the benefits and excitement of a bug bash.

Whoever watches the video will probably be interested in future bug bashes—and part of that interest stems from Farah being a team lead, a position to look up to.

Create a separate bug category for the bug bash

After the bug bash is over, you’ll want to know how effective it was and how many bugs the participants found.

The simplest way to accomplish this is to somehow categorize the bugs found during the event. That way, those errors aren’t mixed in with all the other known defects.

When using a bug-reporting tool, this is quickly done. For example, Shake offers different feedback types, including custom feedback.

You can view this here:

A custom bug bash category would be a huge help.

Simply instruct participants to report all the errors they come across under this feedback type, and you’ll know precisely how constructive the event was.

Here are the technical specifications with sample feedback categories:

As you can see, there are numerous classifications you can create (e.g., bug bash audio, bug bash video, etc.). However, a simple bug bash category will do the job for your first bug bash.

If you’re using Jira (arguably the most popular bug-tracking tool), there’s a similar workflow. In Jira, bugs are characterized as tasks, and the software allows users to assign labels to tasks.

Here’s a task with a blog label:

Just click the pencil highlighted above, and you can add more labels. This screen will appear:

You can add as many labels as you want. As such, attaching a bug bash label to all bugs found during the event would be a good idea.

With this category, you can easily measure the bug bash’s impact and how productive it was.

Instruct participants on how to report bugs

Only some people attending your bug bash will know how to report bugs. Therefore, to have a productive event, it’s well worth instructing participants on how to do so.

There are several essential components every bug report has, displayed below:

A title or bug ID comes first, as this significantly facilitates organization and identification.

Next is the environment in which the bug occurred—operating system, browser, app version, etc.

Following that comes a description that concisely yet clearly describes the bug in detail.

Steps to reproduce are a huge help, as they allow developers to recreate the bug.

The actual vs. expected results are also vital since they compare how the software currently functions to how it should function.

After that, the bug’s severity or priority should be indicated. This metric evaluates how seriously the bug affects the software.

Finally, screenshots or screen recordings are always helpful since they clearly show the bug’s actions.

All this information might be challenging for those without bug-reporting experience. As such, it’s a good idea to utilize a bug-reporting tool.

For example, with Shake, simply shake your mobile device, and a bug report is automatically generated. This tool instantly gathers all the information listed above in seconds.

Here’s a sample bug report:

This report has everything your developers need: environment details, logs, screenshots and screen recordings, steps to reproduce the error, and more.

Equip your participants with this tool, and they will effortlessly submit comprehensive and detailed bug reports.

Tell participants what to focus on

If your only instruction to participants is for them to find as many bugs as possible, you won’t have very fruitful results.

For a bug bash to be successful, attendants need direction to guide them.

This can be a specific portion of the software (e.g., the checkout page) or technical components (testing if all buttons are responsive).

However, whatever you choose, your participants must have a clear focus area.

In fact, if you know exactly which software sections are the most buggy, you can even write a list of tasks for attendees to complete.

For example, take a look at this document:

The list outlines all scenarios that need to be tested, serving as a roadmap for your bug bash participants.

Attendees can take their pick and explore whatever actions interest them most. In a long enough bug bash, they’ll even be able to trial all of them.

However, these tasks are relatively general. You can also make each user scenario much more detailed, providing step-by-step instructions.

Here’s an example of a more specific assignment:

This user scenario defines the exact preconditions and test steps and even indicates the expected result.

It’s best to prepare detailed user scenarios for user stories you know require improvement.

You’ll want to catch as many bugs as possible before release, and these comprehensive tasks will ensure this, as bug bash participants know precisely what areas to focus on.

Split participants up into rival teams

Although a bug bash is a joint effort toward finding errors in your company’s product, a little friendly competition is also welcome.

To motivate participants, and make the event more dynamic, split your participants into rival teams.

By creating groups, you’ll automatically create a kind of contest. Participants will be especially driven to find bugs, as they’ll want their team to take first place.

For example, look at this tweet:

The author of the tweet clearly was excited about the event, looking forward to performing well for her group, as well as beating rival teams.

Depending on the number of attendants, you can create small, medium, or large teams. The visual depicts what each team size typically looks like:

Small teams contain up to four members.

However, there should always be one bug master (or moderator) to organize the testing, ensuring their colleagues are focused and have the necessary tools.

Medium teams are made up of five to ten team members. Given the larger number of participants, the bug master divides his responsibilities, delegating technical tasks to the stager.

The stager becomes responsible for creating the testing environment, providing testing devices, servers, tools, and similar.

Finally, large teams can have between ten and twenty members. Because of the increased numbers, a small support team is included.

They answer participants’ queries and help resolve any technical issues.

Depending on the number of people, split your participants into rival teams as described above, and use the competition to motivate everyone for the event.  

Offer small rewards to top performers

Continuing the friendly competition strategy, you can also encourage participation by offering small rewards for top performers.

These little prizes indicate a job well done but are also gestures of gratitude. In any case, the tokens will definitely motivate your attendees.

For example, SIGiST offers prizes for their bug bashes:

The promise of a possible reward is sure to spur individuals to apply. Besides, these prizes don’t need to be anything fancy.

A lunch gift certificate, company merchandise, a copy of A Bug’s Life… any of these will do the job. You could even manufacture a gold medal for whoever finds the most bugs.

That being said, you can also create multiple award categories. Most bugs found doesn’t need to be the only one.

Here are some ideas:

The most common rewards category is probably Most bugs found, for whoever locates the highest number of errors.

Most unique bug is for the wackiest error—for example, a mobile app error message requesting the user to insert a Windows installation disc.

If a tester comes across a critical error like an app crashing once it opens, this is worth the Most severe bug award.

First bug found should go to your fastest participant, whereas Bug least likely to get fixed often indicates the most insignificant bug.

Finally, Best team is awarded to the team that uncovers the most errors as a group.

If possible, it’s worth creating a unique prize for each category to really personalize the awards. Your participants are sure to appreciate the small gesture.

Conclusion

A well-organized bug bash can be hugely productive. By unearthing so many bugs, you’re helping developers iron out the kinks before release.

To ensure an effective bug bash, set a clear date and time. It’d also be fantastic if influential team members participated.

You’ll need to explain how to report bugs, and it’s a good idea to create a bug bash-specific category. Also, don’t forget to emphasize the focus area.

Finally, to drive motivation, split participants into rival groups. Offering rewards will also help with this.

Follow these tips, and your next bug bash is sure to produce fantastic results.