As we see out the remaining weeks of 2021, we can look back on what will be nearly two years of accelerated innovation a...
5 Easy Steps to an Effective Bug Bash
“It's not a bug - it's an undocumented feature.”
Finding bugs can be a draining experience, especially with limited resources and a small QA team. Increasingly, however, development teams are turning to the bug bash as a solution for streamlining this process, and as a means for gaining more confidence in the quality of their products.
In fact, even big corporations such as Microsoft regularly employ bug bashes throughout their product development lifecycles.
What is a Bug Bash?
A bug bash is a procedure through which all developers, testers, program managers, designers and even marketers, put aside their usual daily duties and try to ‘break the app’.
This is to say to use the product in every imaginable way so as to quickly smoke out any residual bugs that may still be hanging around.
It’s also commonly referred to as ‘pounding the product’.
The Advantage of Bug Bash
Everyone uses a product in their own way. Therefore, through this diversity of uses, successful bug bashes enable a team to identify a relatively greater number of bugs within a shorter time frame.
When to Use Bug Bash
To run a successful bug bash, the ideal time for running a bug bash will be before product release after all planned features have been developed and tested.
Otherwise, implementing bug bashes during the development process risks the involvement of bugs that have been entered into the sprint backlog, but have not yet been addressed by the development team. This will increase the chances of a tester having to deal with a redundant bug that should/would already have been remedied at the point of post-product launch.
How to Prepare for a Bug Bash
Bug bashes are usually announced to the team a few days or weeks before the scheduled date.
In some organizations, it will often be followed by a party and prizes for those having uncovered the worst bug and/or most errors.
Bug Bash Briefing
The test management team will specify which parts of the product require testing, with detailed instructions being given to each participant on how to test and record detected bugs.
For smaller applications, this procedure is usually bypassed, with participants simply acting as ordinary end-users.
How to Run a Bug Bash - 5 Steps
1. Define Bug Bashing Roles
Ensure you clearly define each role in a bug bash and that you distribute these roles appropriately.
Invitees should act as end-users and/or test the application based on the scenarios provided. There are three main roles involved in the procedure:
Stager - arranges meeting site, prepares all devices and provides access to the app being tested
Bug Master - head supervisor for the entire event, presenting scenarios and supporting testers where there are and/or issues
Minutes-taker - reports and records all identified bugs and gathers all information for reproducing them
2. Determine the Testing Scope and Duration
As sustained focus and productivity in participants will be limited, the prepared scenarios in the bug bash generally shouldn’t exceed 45 minutes at a time. These may be shortened so that extra time is dedicated to exploratory testing.
Test scenarios should include:
Any potentially useful notes and general scenarios for testers should be included; often these will be in CSV file form.
3. Invite Your Team
It is good practice that invitations be sent a few weeks prior to the bug bash meeting and that all participants’ availability is verified in good time.
An agenda outline of the bug bash should be provided in anticipation of the event as well as full details on prizes and incentives to encourage those taking part. Ensure a reminder is scheduled in the calendar a few days beforehand.
4. Create a Bug Bash Report Template
Composing the bug report is crucial to proper preparation.
The ideal bug template should include:
Steps to reproduce
The browser and its version
Test device (platform, model)
Screen recordings and/or screenshots
It is advised that all discovered bugs be put into a simple CSV file to avoid duplication, should two or more testers happen to identify the same bug.
There is also the possibility that a bug will be invalid. This way, a Bug Master can later decide which bugs require attention and repair.
Lastly, it is beneficial that some space in the template is provided for testers to submit their own ideas on UX improvements and on any new features that might improve the app’s quality.
5. During the Bug Bash
Once all preparations are done, time for the fun part:
Intro - 5-10 minutes should be sufficient.
Outline bug bash guidelines and rules
Explain the bug template
Provide brief scenario description depending on the level of app familiarity and complexity
Disclose prize descriptions and presentation procedure
Encourage participants to ask any questions during the event
Set the countdown
Limit the procedure to 45-50 minutes so as to avoid fatigue and loss of focus
Present statistics on all bugs discovered, also outlining their degree of severity.
Should you be looking to establish bug bash as an integral part of the product development process, it is crucial that you gather feedback from your team so that you know how to improve the next bug bash session.
And again, it is strongly advised that you provide tangible incentives for all participants, particularly as a way to bring those non-development staff members into the nearer orbits of the product development lifecycle.
Some other ways to enhance the award ceremony would be to establish and award particular categories of achievement, such as:
Most severe bug
Most unique bug
Quickest bug discovery
Best bug hunter ('The Bug Hunter')
Most valuable feedback
Best ‘B-bash’ team
Bug Bashes Unite
Beyond the awards ceremony, you’ll also find considerable rewards for the time and effort you invest in implementing the bug bash. Not only will you see for yourself an efficient, effective and thorough means for streamlining your product prior to launch, but you’ll also find bug bashes an ideal way to promote more inclusive interaction among colleagues and thus grow greater awareness and understanding of what the product development lifecycle really entails.
Of course, at Startup Development House, we long loved a good ol’ bug bashing with the team, so if you’d like to get more ideas on how you can promote and develop this practice in your own establishment, feel free to reach out to us at hello@startup-house.
You may also like...
In an earlier blog, I had mentioned the sustained proliferation in startup companies around...