The Power Of The Bug Bash

Question: What is the easiest and most cost effective way to implement exploratory usability testing prior to a release each sprint?
Answer: A bug bash between the teams on your project.

Regardless of whether your organisation has dedicated QA personnel or not, there comes a time when the people who have built a feature would like ’someone else’ to have a look at it prior to a release. Someone who will provide an objective, prejudice-free assessment of the work. This honest feedback is invaluable just before ‘flicking the switch’ and can save a lot of time and money, and prevent embarrassment.

The QA/test team may have worked wonders throughout the sprint and prevented numerous issues from remaining in the final product but, along with the developers, they will have been 100% focused on the feature and are thus at a slight disadvantage when it comes to user-focused testing. They know it too well and can be prone to overlook the obvious.

Although the product owner is representing the customer/end user, they also have been involved full-time on the functionality during the sprint and have their ideas on what will work and what won’t. Through in-depth discussions their opinion may have become distorted on what works and what the customer won’t like.

What is needed are fresh pairs of eyes provided with a mission to ‘play with the feature’ and see what they think. An end user, someone who has been handed an app for the first time and asked “What do you think?”. Considering first impressions last, and with the myriad of options available in the software space creating a very competitive environment, something that either isn’t intuitive, doesn’t work as expected or just looks crap is going to die a death in production.

Now, employing a team of usability experts, crowd-sourcing or a team of offshore trained UAT people will certainly get the job done, but it will also certainly cost What I suggest is to use the people in the company and call a bug bash. Teams are given 30 minutes to play with another team’s new feature and provide feedback within that timeframe. The related product owner then reviews the comments and acts on them as they see fit. Here are the core rules :-

1) The exercise lasts 30 mins, not a minute longer.
2) A team shall be informed directly before the bug bash of what they’re going to look at (make it at most a 3-word title, to provide focus but also to allow people the freedom to do as they wish within that guidance).
3) Everyone in the company can join in (it’s actually encouraged).
4) All testing is performed on the same test environment.
5) No discussion is allowed between team members.
6) Feedback can consist of bugs found, questions, comments, general feedback, whatever.
7) The remit is to “play with the feature and see what you find/think”.

After the 30 minutes, everyone returns to their normal work.

The method of submitting comments can be via an existing tool in the company. I’ve done this with Jira, but it runs the risk of people responding to issues and then a chain of communication starting up, thus dragging the bash into the rest of the day. What is wanted is feedback for the product owner to do with as they see best - even having people use post-its and hand them in after the 30 minutes would work.

The benefits of this exercise? It’s a short, timeboxed activity where technically-minded ‘guinea-pigs’ provide focused information on a new feature and its integration with all others in the system. It also acts as an unofficial demo for each team and as a learning exercise for all.

The downsides? To be honest I can’t think of an argument against a company forming as a team to check what they’re about to provide to a customer.

One pointer might be the timing of the event during the sprint - to perform it so near to a release may prevent any meaningful changes being made. My outlook on this is that by the end of the sprint there should be no catastrophic news to broadcast so the bash should mostly uncover small glitches in functionality, recommends for future work and overall opinions.

And if something really bad is found then it can be scheduled for resolution in the next sprint and, most importantly, it has been prevented from going live.

It just makes great QA sense. So do it

 

From:http://www.agilequalityassurance.com/2010/04/the-power-of-the-bug-bash/