The Conclusive Bug Bash Testing Guide That Will Help You To Eliminate Bugs Efficiently (+ Bonus Section)

Testing can be hard. Especially if you do not have enough resources for a big quality assurance team. It binds valuable resources and consumes a lot of time if done correctly. That’s probably nothing new, we tell you here.

But what we can show you is that it doesn’t have to be that way.

Big players like Microsoft already use the bug bash approach successfully and the nice thing is, that it is also applicable to small and medium-sized companies.

By hosting a bug bash you will focus your team within a limited time frame on finding as many bugs as possible, while simultaneously encouraging team building. Sounds awesome, right?

This post will help you in 8 simple steps to organize your very own efficient bug bash. Plus, we have also included 4 templates in our “Bug Bash Organizer Bundle”; all you need to do is fill them out and you will

Download Your Bug Bash Organizer Bundle

Download your bug bash organizer bundle to set up your Bash within minutes:

In the bundle you will find:

• Role Definition: Place this on each table so everybody knows the definition of each role
• Testing Scenario Template: This template will help you define a testing scenario more easily
• Team Segmentation Cards: These will help you with your team segmentation
• E-mail bug bash invitation template

“Integrating Usersnap into our review process has added tremendous value, clarity, and efficiency.”

Crazy hunch-backed old guy from the movie Aladdin

What is a bug bash?

A bug bash is a company or team-wide event held to discover a large number of bugs within a short time frame. It involves not only your developers or quality assurance team but also marketers, testers, the UX team, designers or management.

Typically it is held in a big shared room and the one who discovers the most bugs will get a prize. Bug bashes provide a broad variety of benefits, including:

• Exposure of the product to unplanned test environments
• Bug discovery (obviously)
• Support of team culture and coherence
• A better understanding of the product for the whole team

Bug bashes will ensure that everybody is eager to make the product better while simultaneously having a company party.

[Tweet “The Conclusive Bug Bash Testing Guide That Will Help You Eliminate Bugs Efficiently (+ Download Bundle)”]

Bug bashes will allow you to test your new digital products, release or feature in a real-life environment. It will supplement your existing testing processes.

However, by no means will it eliminate the need for your automatic regressions tests with which you test and validate existing code or use flows.

By using this exploratory approach, you will be able to test new features or products and see how humans are really interacting with them. Furthermore, it’s a very convenient way to find issues that no one has tested before.

8 Steps to a successful and fun Bug Bash

Organizing a bug bash is easy as long as you know how to plan it. Since you might not have organized one yet, actually doing it can be a little off-putting.

By using our 8-step process, you’ll be able to organize it on the side without needing too many resources.

Step 1: Set a date and organize a room

The first step in organizing your bug bash is to set a date and get the biggest room available.

Although it might sound trivial, it’s important that the majority of your team or company has time. This improves the testing quality as you have more eyes to spot a bug, but as mentioned before, it will also help with team spirit.

Your room should have the following characteristics:

• Big enough to host your testers: Don’t use a room where your testers might feel cramped. Remember, it should feel a little bit like a party (which it will eventually be at the end of the test).
  Use a room with good ventilation to always have enough air for your brains!
• Projector: You will need to show your testers some testing scenarios & showcase your bug tracking tools. It’s way easier with a projector.
• A different set of chairs and sofas: Make the environment as relaxed as possible. Provide your testers with different ways to sit so that they feel the most comfortable.
• Tons of power plugs: Yes you heard right, don’t forget them!
• Strong internet connection.

Step 2: Decide on the roles

A bug bash needs different players involved. Make sure that you’ve defined them right from the beginning so everybody knows their role:

• The Invitees: These are your testing folks; they can be anybody from the company or team that is involved in developing the product.
• The Stager: This role is responsible for setting up the testing environment. Make sure that there are enough testing devices, that they have the necessary testing templates and tools installed and that the staging server and database are in order.
  This is usually a role for developers who have domain knowledge.
• The Bug Master: The bug master is the conductor of the whole event. She defines the testing scenarios and test teams and makes sure that the invitees are focused on finding bugs.
  This will most likely be your role.
• The Note-Taker: This person is responsible for gathering information regarding the bugs, how they occurred and where. This person should be very organized, someone who doesn’t lose his or her nerves when in a stressful situation.

Step 3: Send out invites

Everybody these days receives a lot of emails, slack notifications or meeting invites. That’s why your bug bash invitation needs to stand out if you decide that it’s not mandatory to participate.

Some things you should consider when sending out your invitation:

• Send out the first invitation 3 weeks before the event
• Your reminder email invite should be 1 week before the bug bash
• The invite should be sent out by C-level staff
• Mention that there will be free drinks & food (always the best argument)
• Tell them that the winner of the bash will take home a prize
• Make it mandatory to either accept the invite or decline (no maybes)

If you do not want to come up with an email, we have prepared a template for you:

Step 4: Create the teams

After you have received your first replies you are good to go, right?

Not exactly!

This step is one of the two most important steps in organizing your bug bash because it will define whom among your testers will work together. Plus it helps you to mix people from different departments together so they can get to know each other better.

Mixing teams together depend on the size of your tester pool and your test scenarios.

What we have experienced is that a group of 3–4 members work the best because everybody will be involved in testing and the group isn’t so big that it allows members to slack off. If possible, create at least 3 teams.

The easiest way to tell your participants which team they belong to is to give them a paper with a number on it as they arrive at the meeting venue.

Make sure that for each team there is a designated table with testing devices set up (number each table).

You will find predesigned number cards in the bug bash organizer bundle, so there’s no need to design them yourself.

[Tweet “Grab this free bug bash organizer bundle from @usersnap to easily hunt down your bugs.”]

Step 5: Prepare your testing scenarios

Now that you have decided on the bug bash roles and tester teams, your next goal is to develop testing scenarios.

We are all humans, which means that we have a limited time frame of productivity during which tasks have our full attention.

You aren’t any different, are you?

This is why you should limit the time for one scenario to a maximum of 45 minutes, with 15-minute breaks between each test.

Things that a perfect testing scenario includes:

• Descriptive but short title
• A detailed description of what the users should test
• Assumptions & predefined conditions
• Mandatory test steps
• The goal of the test
• Scalability (meaning you can use them in another bug bash)

Show this scenario on a projector during your test so everybody can see it constantly.

Step 6: Define a bug reporting process & template

To easily track all the bugs, use your preferred project management tools like Jira, Trello, and Basecamp.

Within them, create your own project so you can see which bugs actually come from the bash and who submitted them. This is vital for awarding the prize to the best bug hunter afterwards.

The perfect bug reporting template includes:

• Title (what went wrong)
• Environment (Browser, OS, Device, App Version, Connection Type)
• Steps to reproduce (what steps were taken prior to the bug)
• Expected result
• Actual result
• Screenshot/Video of issue

Sometimes it is very hard for non-tech users to actually gather all the information needed.

This is where a visual bug tracking tool like Usersnap comes in quite handy.

With it, you can simply screenshot the bug, write or draw what is wrong and then automatically send it into your project management tool.

Your developers will also love Usersnap as it comes with all the meta-data included.

Just test out the Usersnap free trial and you will see how it speeds up your bug reporting process.

“Integrating Usersnap into our review process has added tremendous value, clarity, and efficiency.”

Rachel Panush, Executionists

Step 7: It’s bug hunting time – the bug bash

The preparation is done. Now it’s time to hunt down those bugs.

To make it a huge success you need to have a well-thought-out timetable. Be very strict about it in order to keep motivation high and optimize the results you will get.

Suggested Bug Bash Timetable:

1. At the start of the bug bash (10 min + 5 min Q&A)

• present how a bug bash works
• present the bug bash roles and who is responsible for what
• explain how the testing process works & how to fill out a bug report template
• show the award
• show your invitees the testing cheat sheet (use this Testing Cheat Sheet to give them some ideas)

2. Before testing starts:

• Present the testing scenario
• Set the countdown (use a big time clock which can be seen by everybody, set it between 30-45 min)

3.  During testing (not more than 45 min)

• Show countdown on wall
• Show bugs that are reported
• Be there to help out with any questions

4.  After testing

• 15 min break
• After the break, show who the bug hunting leader is

Repeat steps 2-5 depending on how many scenarios you have prepared.

Step 8: Wrap up the bash

After you and your team successfully hunted down all the bugs (hopefully), it is time to award the best bug hunter and celebrate.

On the next day, contact everybody and get feedback on how they liked the bash, what you could improve the next time and what went wrong.

This will help you to optimize your next bash.

Now, make your next bug bash a success

Armed with the knowledge in this bug bash post, you will be able to discover and solve bugs or user flow hiccups that negatively impact the success of your product or website. You know how to organize and execute a successful bug bash (and have fun during it, as well as during the after-party)!

Did you already organize a bug bash? Did we miss something or have you discovered techniques that we didn’t cover yet? Let us know all about it here. You can also try out the top-rated feedback solution that helps you build better products.