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.
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.
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.
There are 3 steps to conducting a Bug Bash session
1. Preparation
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:
The Bug Bash should last 60–90 minutes and be divided into 3 parts:
3. Post Bug Bash
And now for the final session, I would like to introduce some typical actions:
And here are some best-practice methods that I would like to recommend:
Author: Henry Cao
Editor: Michael
Graphic designer: Jessy
References
https://en.wikipedia.org/wiki/Bug_bash
https://blog.testproject.io/2021/04/05/the-ultimate-guide-to-organizing-a-bug-bash/
https://www.bugreporting.co/blog/the-ultimate-bug-bash-testing-guide-how-to-run-a-bug-bash/
