How to do a Test Bug Bash for your Software Project?

Bug Bash is a unique exercise that is seldom used by projects. Not many people are aware as to what is a bug bash, and why it is used. Lets start our learning process about software bug bash activity.

What is a Bug Bash?

Bug Bash is a test activity that is carried out by a number of people of simultaneously. It may comprise of people of the same team, or it could have people from different teams participating in it. It is not uncommon to involve people in a bug bash who are not exposed to the product at all. It places no constraints of the type of people that may participate in it. It is common to see developers, analysts, managers as well as testers take part in project bug bashes.

What is the use of a bug-bash?

The reason why a bug bash is conducted is multifold.

• It helps in bringing in a fresh perspective to the testing. Having the same test team who is testing it since time immemorial, brings in a certain staleness to the test strategy. This is similar to a pesticide effect that happens in our houses. Testing and using the same system over a period of time, makes the testers use it in set ways. They rarely will go outside the convential approach they regularly use. Bug bash brings in a fresh pair of eyes who use the system in unconvential / untrained ways.
• It helps in pounding the system from a load as well as test focus perspective.
• It can generate a whole new set of suggestions for either enhancing the feature set, or tweaking them to make the application more valuable.
• It acts as a basic sort of usability as well as acceptance testing for the application having a number of untrained people use it.

How to do a bug bash for your project?

• Declare a time slot of 3-5 hours of bug bash in advance.
• Compose a team having a good mix of experienced, new and untrained people to participate in this exercise.
• Have a small briefing session with the team. Give them an overview of what the system does, and explain them what its most important workflows are. Ensure that this is not an extensive training session.
• Let them pound the system for 3-5 hours. Do not peer over their shoulders to guide them, or correct them. Let them use the system on their own.
• Have the bug bash team make a record of the issues faced, crashes encountered, and any suggestions or enhancements they would like to see.
• At the end of the exercise you can consolidate all the issues and suggestions and summarize them for the team.
• Filter out the known issues, by-design issues, and suggestions / enhancements that are not warranted from this list. Now what you are left with will probably be a good number of never encountered / tested defects, and suggestions and enhancement that will improve the software further. This is very valuable information!

Enjoy the bashing :)