Often as testers, we question where could we can make improvements, bring fresh ideas and add value in our organisations. Based on past experience I have seen huge benefits of running a Bug Bash. In this post, I want to cover the topic of the Bug Bash and why I believe is so effective.

What is a Bug Bash?

In simple terms, a bug bash is a set period of time where a range of internal staff test the product, to find bugs, simply use a new piece of functionality and provide feedback.

All the developers, testers, product managers, designers, sales, customer support and anyone else willing to spare time, put aside their regular day-to-day duties and focus on the product to gain greater much focus on the product.

Why run a Bug Bash?

‘Are we building the right product’

From the v-model we took two simple principles ‘Are we building the product right’ and ‘Are we building the right product’.

‘Are we building the product right’, bug bashes help us find the most important bugs quickly or at least before we release.

‘Are we building the right product’, more importantly, bug bashes help us understand that we are building a product that brings business value, by inviting a diverse range of internal staff members such as sales and customer support we get early feedback if we are on the right path. Bug bashes in this context should be complementary to other strategies such as Behaviour Driven Development (BDD).

Efficient

It is much more efficient to have a number of people from different backgrounds testing software than just a tester testing alone, developers and testers pairing or even a team mobbing. Ultimately this leads to finding critical issues earlier, in other words finding problems that people care about faster.

Diversity

It ensures diversity is incorporated into your testing in both terms of Cultural and Specialist Diversity. A bug bash adds cross-functional specialist skills by adding marketing, sales, and support specialties.

I currently work in a cross-functional team of six members, we represent 4 nationalities including Irish, Scottish, Polish and Spanish. When we run a bug bash, that spreads out to other nationalities such as English, American, and Brazilian.

When you are developing software for a global market you need that level of diversity in your testing. A more diverse group will help you find problems such as user experience issues, that if resolved could be the difference between a successful or unsuccessful feature.

Earlier than other group testing approaches

Bug bashes are an early group testing strategy approach and earlier than other group testing approaches such as Beta, Bug bounties and Crowd-testing services. The focus of Bug Bashes is prior to release whereas the other strategies listed above are typically post-release.

When do you run a Bug Bash?

There are Generally two distinct times when you would want to schedule a Bug Bash.

Prior to release

A Bug Bash could perhaps be a week before the release date. In my experience, it has to be late enough that the product is of a reasonable level of quality(no critical or major defects) but not too late for changes to be made.
The implementation of the code should be complete and the team is satisfied with the quality of the software.
There may still be known open issues but these are deemed acceptable for the release. i.e. the purpose of this Bug Bash is having a final round of testing and the expectation should be that no major issues should be uncovered.
It is worth noting that mock-ups and demos of the product can be demonstrated outside the team. Although but in my opinion, the software has to be of a reasonable quality before inviting others outside the team. I believe that bug bashes should still be considered part of a shift left strategy.

Tight Testing timelines

A Bug Bash might be scheduled if after initial testing a significant number of issues have been found and there is a limited time to code completion. A significant amount of regression testing needs to be completed and there is limited time
The purpose of this Bug Bash is to find as many of the remaining issues in the application as quickly as possible.
This approach is similar to using an Exploratory approach when testing timelines are tight and Exploratory test techniques may be complementary to the Bug Bash.

Summary

Bug bashes bring many benefits such as diversity in testing, early group testing, quality improvements and validation we are delivering business value. Bug Bashes compliment other test approaches such as Exploratory and Behaviour Driven Development(BDD).

For the time and effort spent on organising a bug bash, there are few other approaches that are more efficient and effective.

Why don’t you give it a bash?

If you enjoyed this blog, check out the next Blog – Guidelines running a Bug Bash

This is a personal blog. The opinions expressed here represent my own and not those of my current or previous employers.