What’s your secret to running a successful bug bash?

🙋 Questions
, , ,
1

Check out my MoT article, “How to throw a bug bash: A tester’s guide,” to learn how to run a bug bash that uncovers critical issues and helps in team collaboration.

Whether you’re planning your first bug bash or looking to refine your process, this guide walks you through everything from preparation to execution and follow-up, ensuring your bug bash delivers actionable insights.

What you’ll learn

  • Define clear objectives and scope for your bug bash
  • Engage cross-functional teams and enable a collaborative environment
  • Use tools and techniques to streamline the process, such as using Miro for documenting findings or pairing between cross-functional roles

After reading, share your thoughts

  • What strategies have worked best for your bug bashes?
  • Do you have tips for engaging teams to make bug bashes more effective?
  • What challenges have you faced during bug bashes, and how did you address them?
4 Likes
2

In one of my previous organizations, we used to inform in organization’s official group two weeks before the event, that we were organizing the event. It was open for all except the QA & PMs of the project. Still, regular updates were sent to the group regarding the code of conduct, prize, etc.
We usually start it on Friday evening and would close it on Monday evening. So those who were interested were allowed to explore the project on the weekend or Monday morning and log the bugs. On the day of event a demo would be given by the lead and then sheet was shared for logging the bugs and drive folder for uploading the screenshots/screensrecording.
There were 4 categories of issues reported by users - improvement, bugs, and rejected and need to be discussed.
All the improvements were forwarded to PM so that they could review and create a ticket for it, valid bugs were further categorized according to priority and severity, and then some were rejected which were not valid, lastly “needs to be discussed” which include the issues to be discussed with those people who raise.

There were points for improvements and valid bugs (in case of bugs, like critical bugs were given the highest point then so on. ). If any bugs of “Needs to be discussed” turn out to be valid bugs, it was also considered in points.

Also if two persons raise the same issue then who had logged the bugs first in the sheet was considered for point calculation. It would usually take almost 1 week to tirage all the issues logged by all the users.

The prize was given as an Amazon gift voucher for the top 3 persons.

1 Like