What is a bughunt?
A bughunt is an event to find application bugs, both functional and cosmetic in nature. As a team you invite your colleagues and maybe some stakeholders too for the event. Plan it about one or two sprints before a major release. Don’t forget to invite the people at the backoffice, or the callcenter, the secretary or the janitor. You are aiming to get a diverse group of people, you surely don’t want to have only developers.
The format of the bughunt is easy. Divide the attendees into small groups and let them use the application for a set amount of time, for example half an hour. If needed you can give a short overview of the application, before the hunt will start. Each team starts with some empty bug-report sheets, either on paper or of a digital variety. When they find a bug they need to fill out a bug-report and call one of the team members organising the bughunt to verify the bug.
The organising team is not participating in the hunt itself but is observing the hunters using the app. At the end, the bughunting team that has found most bugs, will win! All in all an ideal way to close the day and maybe plan a colleagues get together afterwards.
Why do a bughunt?
A bughunt is a good informal way to get a feel for the readiness of the application. When you have a wide variety of different people to attend you will get way more feedback in a short amount of time than you could do as a team yourself. In my experience, team members, myself included, wont see some bugs because they are there so long they adapted their workflow around them.
Usability bugs will come up as well, while some of the people attending probably have not seen the application before. A bughunt is therefor not only to find programatic bugs but also to see other people work with the app. To be able to see how the hunters use the app to solve the problem it was designed for will give the team valuable insight in the flow of the app. When you need to help a lot of teams along at some point in the flow of the application is critical information as well.
The team will get insight in the overall performance and usability of the app. While it is shortly before a release you can tank some confidence in people trying to find bugs while there are not many to find anymore. It is also a good way to pick up on any red flags concerning the flow of the application. In spite of the fact that there should have been user tests before in an ideal world.
Then again organising a bughunt for a project that should go live in a couple of week and is still failing is not so much fun for the team. Although it might be a good way to proof the failing readiness of the product to the people making decisions about the scope and release dates.
After the hunt the organising team should plan a get together to review the bugs found and the behaviour observed during the hunt. In collaboration with the product owner the priorities for the last sprint(s) can be set. With the information of the bughunt in the pocket the team can then start confidently on the last tasks before the actual release.
Doing a bughunt before every major release is a good tradition to start.