What Is a Bug Bash?

What Is a Bug Bash?

In software development, a Bug Bash is a procedure where all the developers, testers, program managers, usability researchers, designers, documentation folks, and even sometimes marketing people, put aside their regular day-to-day duties and “pound on the product” —  that is, each exercises the product in every way they can think of. Because each person will use the product in slightly different (or very different) ways, and the product is getting a great deal of use in a short amount of time, this approach may reveal bugs relatively quickly. [Wikipedia]

Putting it in a simpler way, Bug Bashes are organized by the software teams where people collectively from all the relevant departments join hands to check the product and discover if it is fit for production release. 

The bugs, observations, and feedback received from the different participants are recorded and accordingly, a plan is created to fix them before the product is released to the end users.

What Is the Objective Behind Organizing a Bug Bash?

As the name and definition already mention, it is Bug Bash, so the major objective is to find bugs hidden in the application and resolve them before it reaches the end users of the product. However, The developers, business analysts, Project Managers, and quality analysts should all be on the same page. There should not be any blame game once a bug is found, as this is a collective team effort to make the application more stable and robust by providing faster feedback, so as to release a quality product in the market.

Why Should a Bug Bash Be Conducted?

• Most importantly, Bug Bashes are a relatively cheaper way to find a large number of bugs in a short span of time.
• Bug bashes provide an opportunity for everyone in the organization to learn about the different parts of the product they are less familiar with.
• It improves cross-team collaborations, communication, and relationships.
• Helps to test the product with a wide variety and combination of devices/browsers/mobile versions/mobile OS’s which in general is very difficult to test in a short span of time
• People with different experiences in the team can collaborate and test the product effectively with different perspectives.

Who Facilitates the Bug Bash?

Ideally, the Tester or the Test Lead should facilitate the Bug Bash.

When to Conduct a Bug Bash

Bug Bashes are advised to be conducted before a major release or if there is any critical release that may impact the overall working of the product. The time to schedule may vary according to the collective decision made by the team. 

Normally, it should be conducted before a week of release or even sooner. A point to note here is that all the cards/tickets that are tagged for the release should be either "QA Done" or "Dev Done" before the Bug Bash is scheduled. It doesn't make any sense to have a Bug Bash if the feature that is going to be released is half-baked.

How to Run a Bug Bash

A Bug Bash session can be divided into the 3 different phases:

1. Pre-Bug Bash session
2. Bug Bash session
3. Post Bug Bash session

1. Pre-Bug Bash

1. Define the facilitator for the Bug Bash. It would be ideal if 2 QAs could pair and lead this.
2. The owners of the Bug Bash should set up a preparation meeting with the team, explain the agenda of Bug Bash to all the participants, and set up the pre-requisite, if any. If any team member requires any access related to the product/application, this could also possibly be figured out in the preparation call.
3. It would be an added advantage if a representative from the client side could join the Bug Bash. It would help in terms of business requirements.
4. Send out a calendar invite for the Bug Bash to all the participants and ask them to RSVP to it so you can plan out the event successfully.
5. The following points need to be considered while sending the calendar invite:
   • Mention the scope of the Bug Bash.
   • The place where Bug Bash is scheduled to happen: Mention the meeting room details, or else, if it is a Zoom/Teams/Meet Call, update the link in it.
   • Mention the details about the test environment and test data that could be used for testing.
   • Attach the link to the Bug Bash sheet which has all details related to pre-requisites, OS/Browser/tools setup/description of features of the product.
   • If it is a mobile app, do share the link from where the latest build should be downloaded for iOS as well as Android applications.
   • Check if all the participants have access to the Bug Bash sheet as well the required links to download the artifacts (in case of mobile app)/links to the website under test.

2. Bug Bash Session

It should be ideally a one-hour session, but could be increased to 90 minutes depending upon the requirement. It all depends on how well it works for you and your team.

1. The facilitator should start by welcoming everyone to the session and explaining to them the scope and details of Bug Bash and ask them to start with it.
2. Once initiated, the facilitator should monitor the participants' activities by checking if they can perform the testing without any blockers. If someone is blocked, he should help them in resolving the queries.
3. Facilitators/coordinators should continuously monitor the Bug Bash sheet where issues are recorded.
4. It should be thoroughly checked that participants are adding the bug details correctly, with proper test steps, screenshots, device/OS/browser details, and also their respective names; otherwise, it would be difficult to reproduce and recheck the same once Bug Bash is complete.
5. Keep an eye on the time as well as once the decided time is reached. A call-out should be done by the facilitator if someone needs more time to perform tests. Accordingly, the session should be extended, if required. The facilitator should thank everyone for their participation and for giving their valuable time for the Bug Bash.

3. Post Bug Bash Session

This is the most crucial and important session that needs to be set up. Most importantly, in this session, the business analyst, QAs, and the Product Owner should prioritize the issues reported.

This session doesn’t require the whole team to be present. Business analysts, QAs, and Product Owners can meet and analyze the issues reported. They might also need to reproduce the issues and update the steps, if any, in the sheet.

It should also be noted that all observations reported in the Bug Bash may not be a bug. Therefore, appropriate clarifications may be required to be taken from the reporter as to what is their perspective in reporting the respective observation. Once that is done and understood, the appropriate action to take would be to mark it as a Bug or Not a Bug.

Once the priorities are defined for the bugs reported, tickets/cards should be created in the Sprint board labeling them as Bug Bash bugs. The ones with higher priority should be taken in the current Sprint and resolved at the earliest before the release. Accordingly, tickets/cards should be prepared for the lower priority issues as well and should be placed for the later Sprints.

Bug Bash Template

A sample “Bugbash_Template.xlsx” has been added inside the "Templates" folder of this GitHub repository which could help you in bug bashing!

Conclusion

To conclude, a Bug Bash is a great way to perform exploratory testing. It brings in people with different experiences and different teams. It also provides us with a variety of device/OS/browser coverage in a short time, which might help in uncovering the hidden issues. Having someone participating from the client side would help us in getting faster feedback before releasing the product to the end user.

Happy Bug Bashing!!