What is it?

🐞 🔍 Bug hunting is a different way of calling Exploratory Testing, a session to explore a certain feature or the whole app to find bugs, unexpected behaviors, or missing requirements.

Essentially, finding new behavior that isn’t in the test specifications or issues not caught by the automated tests like glitches. It works best if it’s unscripted, giving people the freedom to dig into the app and hunt for bugs.

💡 This kind of test must be a complement to automation, not a replacement.

Remember that automation plays a big role in catching any issues, confirming your code doesn’t break the current functionalities while moving fast with high confidence minimizing human errors, and having constant feedback on code changes. Whereas bug hunting is very late in the development lifecycle when everything is “finished” meaning deployed in a testing environment, Dogfooding, or even on production, and consequently very expensive to fix any issues. So, make sure to test the feature and create proper automation before this session!

Who should be involved?

Ideally involving the whole team or as many team members as possible. It can also be extended to other teams that were involved in delivering a certain feature.

With more people hunting more chances to catch issues, people who didn’t have the opportunity to work on this feature will have dedicated time to comprehend it better. Meaning that everyone on the team will have a whole picture of what was developed and how it works.

If you extended to other teams is also an opportunity for everyone to look at and understand the whole user journey expanding their scope.

What is the value?

But, what’s the value behind it? For sure no one wants your final customers to find the bugs before your team and this session is an opportunity to catch any issues before it reaches your customers.

Besides encountering bugs another advantage is to develop ownership and responsibility, making the whole team care and be responsible for a feature, even if they didn’t develop or got involved directly with it before. This increases the general knowledge about the product/feature and extends the engineer’s ownership of delivery.

Furthermore, it’s also a learning time when people with less experience with testing have exposure to manual testing, and use the time to give them some tips on what to do. Hence, they will learn and apply it before bug hunting or during day-by-day development.

Likewise, it’s a social fun moment! Since everyone will be together. I encourage trying to separate some budget for sweets for everyone or a prize for the person that finds more bugs. Donuts are always a nice idea, giving energy and enjoyment to the participants 🍩

How to facilitate?

Even though there isn’t a formal script, I like to give some structure, such as creating a drive document, Notion page, or Confluence page whatever your team is used to, my template is usually like this:

Besides the structure above I also facilitate and organized this session as follows:

• Team: Usually, I split the team(s) into pairs or trios to explore a specific area. You should share this document before the session and ask people to read it earlier, to reduce time with any configuration.
• Environment: I strongly recommend using an environment close to production for instance if you use Dogfooding this is the perfect moment for that. Make sure the right version is available! And if the feature is behind a feature toggle turn it on before the session for the specific users. 🚨 Be careful here not to turn it on for real users. 🚨
• Timing: this is usually 1h30min-2h when it’s the first or second time, after that, it will be more natural for your team, so 1 hour is ok.
• Bug Management: Always create a label or something to make it easier to filter those bugs later and separate other times to filter, map and prioritize the bugs, this session it’s only for hunting! Otherwise will be time-consuming and not use your team's time effectively.
• Context: depending on the public attending it’s also nice to explain the functionality, something quick like 10 minutes description.

What to do next?

The following steps are to filter any duplicated bugs, clarify any doubts that you may have, prioritize, and take action items, for example, add the bugs to the current sprint or the following ones.

Essentially, find time to sit together or have an async time to filter the issues with your PM, designer, and/or Engineer Manager to identify their bugs' priority and ensure there aren’t any critical blockers for your release.

Discuss with them also when the bugs will be fixed and ensure all of them were addressed and the repeated ones were marked as duplicated or removed from your team’s board.

Final Considerations

📝 Don’t forget to collect feedback from your team. Every team works differently and has its dynamics, so it’s nice to gather how your team felt during the session, what was good, and what should be improved for the next time.

References

Book: Explore It!: Reduce Risk and Increase Confidence with Exploratory Testing by Elisabeth Hendrickson

https://martinfowler.com/bliki/ExploratoryTesting.html