Despite the advances in technology and development methodologies, software development is far from being perfect. Defects are inevitable during software development. A few bugs are likely to slip through the development phases to reach production 🐞 Such bugs impact end-users despite all the testing and automation activities. No matter how diligent your testing is or how effective your automated tests are, there will always be hidden risks.
Bug Bash is a secret weapon that several organizations employ to roll out high-quality software. In this article, we will learn how to organize bug bashes by harnessing the power of your entire organization 🙌
WHAT IS A BUG BASH?
A bug bash is a collaborative event that aims to unearth a large number of bugs within a short timebox. Bug bashes are not an exclusive testers-only event. It’s an organization-wide event that anyone can participate in. It can involve developers, testers, product managers, engineering managers, designers, marketers, solution engineers, even executives like CTO, CEO, etc. 
WHY SHOULD YOU CONDUCT BUG BASHES?
- Bug bashes are a relatively cheaper way to find a large number of bugs in a short span.
- Bug bashes harness the power of perspective from different participants and are effective in finding bugs, product gaps, usability issues, and potential improvements.
- Bug bashing fosters a shared sense of responsibility and ownership for quality in your organization.
- It is a good exercise for non-testers to practice testing and get better at the craft.
- 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.
WHEN TO CONDUCT BUG BASHES?
Ideally, bug bashes are conducted before major releases. Factor the time and effort required for conducting bug bashes during your sprint planning. After the bug bash, there can be a large number of bugs reported, so add enough buffer in your estimates to accommodate the unknowns.
HOW TO CONDUCT BUG BASHES?
1.PRE-BUG BASH
A. DEFINE AN ENTRY CRITERIA – For a feature to be eligible for bug bash, a certain condition should be met. This is essential to shield poor quality builds from being pushed for bug bashing. For example, not more than 10 issues to be open (2 Major issues, 3 medium, and 5 minor issues). QA leads will evaluate the readiness of a feature for the bug bash.
B. DEFINE ROLES FOR THE BUG BASH
- MODERATOR – The moderator is responsible for organizing and facilitating the bug bash. The moderator makes sure that participants are focused on bug finding while keeping it a fun activity. Moderator works on required logistics like rooms, tables and chairs, food and drinks, etc. The Moderator role is typically played by the tester who is testing the release candidate. There can be one or more moderators for a bug bash.
- PARTICIPANTS – Participants take part in the bug bash with the objective to find bugs. Diverse participants bring better results. The moderator ensures that participants with different roles and perspectives engage in bug bashes.
- STAGER – The stager is responsible for setting up the test environment and ensuring the uptime during the bug bash. Stager provides all the required devices and tools for the participants. The stager works closely with the moderator to resolve the challenges that participants face during the bug bash event. The stager’s role is typically played by the developer who has developed the feature. There can be one or more stagers for a bug bash.
C. CONDUCT A PREPARATION MEETING – For large and complex features, the moderator conducts a preparation meeting a couple of days in advance before the event. In the preparation meeting, the moderator will walkthrough the participants about the feature to be explored in the bug bash. This session can be recorded and shared with participants who missed this session. Such recordings can also be used as onboarding/knowledge transfer resources in the future.
D. SEND OUT A CALENDAR INVITE – As a moderator send out a calendar invite at least a week before so that participants can plan their schedule accordingly. Let the email also contain detailed instructions of the following: 
- Scope of the bug bash – clearly specifying the focus areas for the participants.
- List of known issues and problems – so that duplicated issues are reduced.
- Test basis like Requirement document, Designs, tech docs, etc.
- How and where to report bugs – Details of the bug tracking tools and bug reporting template. Ensure that bug reporting is kept as simple and minimal as possible.
- Roles – let participants know in advance, who will play the role of the moderator and the stager.
- Create teams – split the participants into different teams and assign them to work on different parts of the product during the bug bash. Have people from different roles in the team, the key is to keep teams as diverse as possible. Have healthy rivalry among teams to boost the competitiveness in bug bashes 🏆
- Place where bug bash will be conducted – Book the biggest room available in advance where a large number of people can sit. Ensure the room has a projector and a screen to display important information like known bugs, bugs reported, a countdown timer during the bug bash. In case of a remote bug bash, share the meeting link (Zoom, Skype, Google Meet, etc.)
- Link for the recorded preparation meeting.
- Details of the test environment where participants will test.
- Prerequisites like required devices or applications.
- Access to the systems, and other resources they may need during the session.
- Not all the participants in bug bashes are testers. Help non-testers to test better by:
- Listing some tools for recording videos and annotating screenshots.
- Share some tools like Bug magnet to check for problematic values and edge cases.
- Share a cheat sheet of Heuristics by Elisabeth Hendrickson to generate test ideas.
2.BUG BASH SESSION
A bug bash is usually a timeboxed session of 90 minutes. You can experiment with different time splits and decide on what works best for you. Below is the recommended time split:
A bug bash is usually a timeboxed session of 90 minutes. You can experiment with different time splits and decide on what works best for you. Below is the recommended time split:- 10 minutes – Moderator clearly communicates the scope of the bug bash and the required instructions.
- 60 minutes – Focused and uninterrupted time for the participants to explore the application and report issues. The moderator and the stager are available for a chat during this time in communication channels like Slack, Zoom, Google Meet, etc. During this time, the moderator and stager work on evaluating and categorizing the bugs as and when participants raise the bugs. This greatly reduces the post-bug bash activities.
- 20 minutes – For debriefing, where participants can explain the bugs they have captured and provide feedback on the feature they have bashed. The debriefing session is the critical part of the bug bash. The moderator should ensure that the product and tech stakeholders take part in the debriefing. The participants advocate for their issues and why they should be fixed before the release.
Note that all participants may not be technical, do not dismiss their point of view, or discourage them from sharing their thoughts. The moderator should keep the team morale high by creating a safe environment for participants to share their feedback. When you reject a bug explain to them briefly why you are doing so.
3. POST BUG BASH
Moderators work with Product and Engineering leaders to clean up and triage all the bugs. Though this activity is extremely important it can be time-intensive. Despite sharing ‘known issues’ with the participants, some will still report duplicate issues. There can be some invalids and inconsistent bugs with little information which demands moderator and team members to investigate issues before acting on them. Not all the bugs reported in bug bash need to be fixed before the release. Testers, developers, and product managers collaborate and prioritize the bugs. The rest of the bugs are moved to the backlog.
Get feedback from the participants about how you can improve the entire process of bug bash.
HOW TO MAKE PEOPLE PARTICIPATE IN BUG BASHES?
- Get support from your executives – Influence influential people to participate in bug bashes. For example, if your CTO and VP attend the bug bashes, your programmers will not have an excuse to skip bug bashes.
- Rewards – Incentivize Your Participants. Appreciate the time and efforts of the participants by ordering pizzas, snacks, and drinks as an incentive. In case of a remote bug bash, you can share an e-gift card with all the participants. Incentives encourage participation and create a fun atmosphere in bug bashes. Reward the participants who discover valuable bugs, find useful information, or provide valuable feedback.
Here are some ideas of rewards you can roll out:
- Best Bug hunter
- Best Bug
- True explorer
- Most unique bug
- Most valuable feedback
- Best team
- And so on
Here are some ideas of rewards you can roll out:
The moderator should get feedback from both product and tech leaders to finalize the winners for the bug bash.
- Gamify your leaderboard – Gamification is the application of game thinking and typical elements of the game playing in non-game contexts. Gamification fosters engagement, participation, and competitiveness by turning monotonous and tedious tasks into exciting and fun activities. Leverage the inherent competitiveness of geeks to increase engagement in bug bashes. Introduce an element of competition by creating ranks for participants, this will make them keep coming back for more and participate in upcoming bug bashes.
Example of a modified League of Legends ranking system for bug bashes
COMMON PITFALLS TO AVOID
- Bug bashes can be an excellent addition to your existing process. However, it is not a replacement for any testing processes or practices.
- Bug bashes happen late in the development lifecycle. The later you find the bug the more expensive it is to fix. So ensure you do not ignore finding bugs with the assumption that they will be found in bug bash.
- Bug bashes should not be used as a way to get testing done. For example, some teams provide a set of test cases for participants to execute. Participants should be free to explore the application and not restricted to follow a script.
- Keep your bug bashes focused. A wider scope (like testing the entire product) will not give you the ROI you need. Participants will be lost if the scope is too wide.
- Moderators should avoid participating in bug bashes, they should focus on facilitating and supporting the other participants.
CONCLUSION
Bug bashes require your time and effort, but the benefits you get outweigh the costs. Bug bashing is an effective technique to combat bugs before major releases. Take a step towards building a shared sense of responsibility towards quality in your organization. When do you plan to organize your first bug bash? 🤩
Let me know your thoughts in the comments!
Image credits: https://www.freepik.com