Tips to Organizing a Successful Bug Bash

A Bug Bash is an event in the software development life cycle where the entire team comes together and logs bugs on the product, all the interest of improving the quality of the product before shipping.

Here are some tips in order to organize a great bug bash on your team:

1. Get the Entire Team involved in the Bug Bash.

This is extremely crucial. Testers test the product day in and day out. They have an eye on the product every day. It’s the third person’s eye that we are looking for here. If there is a person involved in building/deploying or even sustaining the product, have them all participate in the bug bash. This could range from designers, business analysts, testers, developers, release management, User Experience designers, operations, sustained engineering teams, and even high level managers. The more people looking at the product, the better bugs you will get. Bugs during the bug bash could be just feedback in general as well. It is this feedback that could drive certain design decisions that make the product successful when released to customers.

2. Give High Quality Guidance to people participating in the Bug Bash.

There would be a number of people involved in the bug bash who would be looking at the product for the very first time. Hence it is very important that they propel in the right direction when running the bug bash scenarios. This involves a number of important points and we will capture them all here:

a. Prepare a high quality test environment for testing – Folks should not struggle to log into the system or see random crashes. Be prepared in terms of your test environment. Have different log in accounts. Document all the information in a document and distribute it to all the people involved in the bug bash. That way there is no concern on the day of the event.

b. Prepare a document of all the core end to end scenarios for your system – It’s important that people know how to get started. A document outlining the core scenarios and how to execute them would be extremely helpful. That way the team can get started in the right direction and then test around those scenarios and find good bugs.

c. Have a Bug Bash template that the team can use to log bugs – Many people would be logging bugs for the very first time. They should not struggle with the actual process of using the bug management software that your team uses. Having a good quality template will ensure that the focus is on finding bugs rather and spending time with the tools of the team. The entire process should be encouraging to people rather than tiresome.

3. Time the Bug Bash properly.

A bug bash should be held at a time in the cycle where the build is in decent quality. If you time it too early where the build is still in flux, the focus moves away from logging good quality bugs and customer issues, but you will find blocking issues in the core scenario flow. You really don’t want to be in that state. You want to find all the low hanging fruit, the last-minute bugs that could really push the quality of the product. In my opinion its best to have a bug bash close to the end of the milestone/cycle. Maybe a week before you plan to release (again depending on how long your cycles are). Do remember that you will need some time to triage all the bugs and even fix the ones you want to take. So timing it too late might be problematic as well, especially if you find ship stopper bugs right in the end.

4. Block a Time during the Day on Every one’s Calendar

It’s important not just to send an email saying that there is a bug bash happening on the team during a particular time. Put the event on everyone’s calendar. Maybe an entire afternoon on a Thursday or Friday where it’s light-weight in terms of work on the team. Have detailed instructions in the meeting invite for the bug bash (as described above). This will ensure more folks get involved when its an actual meeting on their calendar.

5. Give Incentives to Participate.

The activity of a bug bash needs to be fun. Hence, having some good incentives to participate would ensure that more people come to the event.Some of the following could be used:

a. Give out prizes at the end of the event – You could have prizes for “Best Bug Logged”, “Top Bug Finder”, “Best Bug Finder – Developer”, “Best Bug Finder – “Program Manager” etc.

b. Make it a morale event – Have goodies, maybe some beer, food. Book a conference room where people can come and participate as part of a group if they would like. You can be creative in this space to make sure that everyone is encouraged to come and have a good time. I worked in a company once where alcohol was free-flowing during a bug bash. 200 bugs were logged in an afternoon of 3 hours:).

6. Encourage an “Anything Goes” attitude.

Don’t have certain rules for logging bugs. Encourage an “Anything goes” attitude. Let people be creative in their testing and log anything they see is not right. Of course this could result in a number of bugs that are “Duplicates”, “Not Valid”, “As per the Design” etc. but the more you have the more you can think about how customers perceive or will perceive your product. Bugs could be in the form of “usability feedback” like “It is difficult to do X”. With these bugs, the product teams can get some valuable feedback on changing the design in the future. You will be surprised as to how many design changes can occur due to a bug bash.

7. Have Management Encourage a Good Bug Bash.

If you want more people participating in the bug bash, management support is crucial. Having a top-level manager enforcing it for people or at least sending an email to people would ensure you get many more people to participate. The bug bash is normally organized by the test team, but having high level management support it will give you more benefits as compared to just an email sent out by a tester on the team. It should come top down. If you need to convince upper level management, then having a bug bash plan reviewed with them with details on the benefits and advantages will get them thinking in the right direction.

8. Have Teams focus on outside their Area of Expertise.

This applies to the product teams working on the product. If you are product that has two teams, have each team test the other team’s area. This will give you the advantage of a true bug bash. How many bugs will you find if you as a product team test the area that you have been working on through the milestone? It’s when you reverse roles that you get advantages of good quality bugs.

With these tips you will ensure that your product will meet a high quality bar right before shipping.