Anyone ever tried Bug Hunts?

My team is hoping to encourage a whole team testing approach. One suggestion that came from this was to have a bug hunt day on the final day of the sprint, which the entire team take part in.

One advantage of this is that we have a couple of colleagues who are new to the team and unfamiliar with parts of the application?

Has anyone else ever run bug hunts? How did you organise and plan them?
Has is been a useful exercise? Were there any issues?

1 Like

Whilst I’ve not done a bug hunt, to encourage whole team testing, especially with them learning the application, have you considering mobbing?

You could have themed sessions, so one could be a bug hunt, making a charter and exploring it. Another could be getting the code written, so the testers could gave ideas if how to make it testable that the devs hadn’t thought about, whilst the devs can teach the testers how the code is written.

Hello @lgibbs!

On a past project, a Test Lead within the group organized a Bug Hunt for my project. The intent was not only to find bugs, but to raise awareness of changes in their application and gain familiarity with them.

The Bug Hunt was schedule about two weeks in advance, and would last about two hours. I provided information about the changes as well as screen shots to assist with navigation and familiarization. Also, I provided a link to the environment where the new behaviors were deployed, and a place to record bugs.

We executed two Bug Hunts like this - one after the project had been executing a while, and one closer to production elevate. In both cases, we found some bugs and some “scenarios of interest” that required a closer look.


I wrote up our experiences with whole team testing on my blog which you may find useful. Good luck with yours, woudl love to hear how you get on.

1 Like

We did a bug hunt in a previous project of mine. It was before a major release date and we took about 2 days. Testers from other groups, POs, BAs and of course the developers from the team were all invited. Our scrummaster organized it all very nicely with cake and candy rewards for most bugs found (and it all had a nice cowboy/sherriff and bug theme). We build pairs (tester and some other person if possible) and designed missions that were given out at the beginning of each window of testing (around 2 to 3 hours) - the teams chose them themselves. We did breaks and exchanged infos. One important thing was that we didn’t record all bugs in a proper fashion but just recorded them with a screenshot. That way it wasn’t to much effort to record them all since you had many doubles or even triple findings. It was very successful, not just from the number of found bugs but also for insight into the workflows of the software.

1 Like