One of the beautiful results of using an Agile process is seeing the application develop in a usable way. This enables product owners to evaluate the state of development easily. But, how can you engage them, and developers further? A bug hunt.

/Who should take part?

Stakeholders, business representatives, developers, product owners, business analysts. Anyone with time and an interest in ensuring the software that is to be delivered meets or exceeds expectations.

/What is a bug hunt?

A bug hunt is essentially a group testing session or sessions.

/Why?

A bug hunt is a chance to exercise the ‘fresh eyes finds failure’ heuristic early. Think of it as early alpha testing. Through using the application, possibly for the first time, people that haven’t seen or used it may spot problems and find failure; or for those involved in it’s development, by investigating areas of the software with goals in mind, those with knowledge of the system can find problems previously undetected.

/Where?

Anywhere you can fit the team into one room. With access to the software under test. So laptops, pcs, tablets, mobiles. Somewhere you can fit any, or all of this and the participants comfortably.

/When?

When the application has enough functionality to enable, possibly a large group of people, to spend a few hours attempting to find problems. This will generally be nearer the go-live date, but not too near that any important bugs found can’t be fixed in time.

/So where’s the fun and how do you make it effective?

Fun is subjective, but depending on the size of the application, the number of participants make the sessions interesting. Goal orientated tasks make it effective. Prizes make it fun.

/Here are some tips for organising and running sessions.

/Session length

Make testing sessions no longer than 90 minutes. Have refreshments available for breaks and, if this is an all day session, get some lunch organised for everyone.

/Divide and conquer

Split into teams or pair up. Give each team or pair a different task, or area of the application to look at. Try not to be too specific, but provide some guidance on the kind of things you are looking for, like performance or functional, typical usage, look and feel.

/Help!

Be prepared, as a tester with knowledge of the system as a whole to provide guidance, or information to anyone unfamiliar. Don’t tell people how to do something though until you understand what they are trying to do. There could be a problem if someone can’t figure out how to use the application correctly. Make a note of it before giving further help.

/Post it

Give everyone post-its and get them to write down their bugs and put them on a wall. More often than not, even though people may be looking at different areas of the applications, the same issues may well be found and this is an easy way to see any similar issues. It also obviates the need for any bug logging systems at the location.

/You be the judge

This is a chance for the testers to sit back, relax and hand out prizes.
Have some categories defined beforehand to motivate people further. e.g. Best bug. Most interesting bug. Highest criticality. Most bugs (though this isn’t a metric I would recommend normally).

With any bug hunt, the primary goal is to ask questions of the developed software and identify any possible problems that can be discussed later. As the organiser, you need to make sure people are happy, know what they are doing. Be clear about what you are trying to do. But also, ensure there is engagement across the team and encourage people to talk. The room should be abuzz with chatter and the click of keyboards (or tap of tablets).