Bug Bash? How To Run It?
1. What is Bug Bash:
Nowadays, even though we have a lot of advancement in development methodologies and testing techniques, there is still a big gap in the testing quality between the actual result and expected outcome. This leads to a persistent sense of insecurity about quality, causing us to find more and more bugs. Especially since we recently implemented Agile into our workflow, the pace increased, and we needed to devote more time to testing to ensure everything was in check, particularly for the start-up company that did not have a professional tester or a staff member who has a similar role.
As a result, the Bug Bash can be used to solve the problems mentioned above.
Bug Bash can be imagined as a place where everyone gathers to find bugs in a product within a set period of time. Anyone from within or outside the company can be among the participants. People that joined were typically those who worked as designers, developers, PO, PM, EM, and others from within companies, such as Executive-Cxo, Marketers, and so on.
Some companies even allow loyal customers and people from the outside to join the company as hackers to determine the product‘s security level.
The more people from various fields who join the team, the more diverse our perspectives will be. Then we can determine whether or not the product is suitable for the target client.
2. The benefits of Bug Bash:
1. Unearth bugs
Obviously, the first benefit of it is that it helps us detect bugs more efficiently. The more bugs we can find, the fewer bugs can occur in production or to the end users.
2. Increase quality
Because we are able to catch more bugs. So, of course, the quality of the product could be increased.
3. Increase testing diversity
Normally, only the QA team and development team can fully understand the requirements from PO (Project Owner), but this also makes the teams difficult to find a diversity of perspective on the product. With many people from different backgrounds joining the Bug Bash team, it enables all participants to come up with their own ideals and the testing approach method and area can be more diverse.
4. Learn internal products
And this is another benefit of Bug Bash. It can help all the participants have opportunities to learn more about the product. even if they come from different teams like marketing, sales, or customer service, etc. With that knowledge, we can provide a better answer to the client by researching the product on their own based on what they know from the Bug Bash team, rather than simply sending the original document to the client as we normally do.
5. Strengthen relationships across teams
We work for a product company, so the relationship is something very important. We receive the requirements from the marketing team, we qualify the bugs with the CS team, and we provide more understanding to the sales team so that they can promote the product better to the client. It is critical to strengthen the bonds between the development team and other stakeholders.
3. When to conduct a Bug Bash?
These are the two occasions when we can hold a Bug Bash.
1. Prior to major releases:
We need to conduct a Bug Bash session before the major release. Normally, we need several working days before the final release. The "several days" that I mentioned here is just a recommendation for reference. It‘s all about the timing that we considered good for us. If we make it too early, the product has not matured enough, so of course there will be a lot of bugs. On the other hand, if we conduct it too late, we won‘t have enough time to fix the bugs.
2. Prior to other releases:
We can also conduct Bug Bash for minor releases or system upgrades, especially for teams that do not have QA and QC members to test the system, so they normally set up a Bug Bash team to test it before release. It is conducted by a smaller group of participants or by an internal development team in order to find as many remaining issues in the application as quickly as possible.
4. How to conduct a Bug Bash
There are 3 steps to conducting a Bug Bash session
In this step, we define the entry criteria for the product and feature, ensuring that they meet the requirements and that we can handle them without any issues.
Then we move on to the next step, which is to define the roles. I would like to introduce three typical roles, as follows:
And this is how we should go about gathering the participants. Schedule & Send out Calendar invitations:
- Scope of the Bug Bash
- List of known issues and problems
- Test basis: Requirement, Designs, tech docs…
- How and where to report bugs
- Roles in the session
- Venue/ Place
- Prerequisites: Required devices or apps…
- Bug Bash session
The Bug Bash should last 60–90 minutes and be divided into 3 parts:
- Starting (5~10 minutes)
- Share the feature, scope, test environment, and required instructions.
- Bashing (45~60 minutes)
- Focused and uninterrupted time for the participants to explore the application, communicate with Moderator/ Stager, and report issues.
- Debriefing & Closing (10~20 minutes)
- Participants explain the bugs captured, and provide feedback on feature bashes.
- Sum up and close the session, and give the prizes to winners if any.
3. Post Bug Bash
And now for the final session, I would like to introduce some typical actions:
- The Moderator and Project Team will analyze the reported issues to clean up and triage all the bugs.
- Actions to be taken are classifying if the issue is valid or not, prioritizing and planning for resolution.
- The Project Team will check the prioritized list and fix/retest the issues.
- Or get feedback from the participants about improvements to the Bug Bash if any.
5. Best practices
And here are some best-practice methods that I would like to recommend:
- In Preparation step,
- Finding a diverse range of participants.
- Ensuring a test environment is stable.
- Participants understand what their role is.
- During and Post Bug Bash Session,
- Keep participants focused on exploring the software rather than investigating issues encountered.
- Create a convenient communication channel for participants to confirm their questions.
- Do not dismiss participants‘ points of view as they may not be all technical, or do not discourage them from sharing their thoughts.
- Make it fun, Bug Bash could be followed by a party and has some prizes for participants who find the worst bug and the greatest total of bugs.
- Bug Bash should focus on products or features that are really needed to test, not give a wide scope to participants.
- Bug Bash can be a perfect addition to the testing process, but should not be the only testing or replacement of any testing in the process.
Author: Henry Cao
Graphic designer: Jessy