The TORCH technique for exploratory testing

Shine a light. The TORCH technique for exploratory testing helps quality professionals bring structure and freedom to their exploratory testing sessions.

So what? Exploratory testing appears to have become a bit of a lost art in the world of AI. We must remind ourselves what’s at stake if we hand over our exploratory testing skills to the AI overlords.

And yet. It seems we’ve forgotten how to talk about and demonstrate exploratory testing skills. The Software Testing Live sessions are a great example of countering this. And essential exploratory testing techniques are taught and demonstrated in the Software Testing Essentials Certificate (STEC).

The upshot. We need to start sharing techniques to inspire each other to talk more about the art of exploratory testing.

The bright path. So here’s where the TORCH technique can help. Just one of many techniques out there to support exploratory testing. And this one is handy just before you run an exploratory testing session.

Define a charter before taking any action.

Then type, mind map, scribble or draw the following:

Timer: Set a timer for your exploratory testing session. Any time between 30 and 90 minutes is good. Much longer and you’ll overwhelm your audience during a debrief. You can always create another charter once the timer stops and run another session. Fast feedback loops are key, and that’s why the timer is so important.

Oracles: List a set of oracles that will support this exploratory testing session. These are things that you can refer to as you explore to make informed decisions about your session discoveries. Oracles can also spark test ideas before and during the session. An oracle is most commonly a requirements document or set of acceptance criteria. Yet equally important are conversations with team members and customers, previous experience and knowledge of similar apps in different industries.

Risks: Capture a list of risks. These are things that might threaten the value of the thing you’re exploring. They aren’t requirements yet are arguably more important. A risk is something that could go wrong. Make assumptions about what might go wrong or what potential issues you might want to explore as part of this session. The more risks, the better, yet be aware that those risks might helpfully spark more charters for later.

Considered Questions: What questions can you ask that you would like answers to during this exploratory testing session? Use the list of risks to turn them into questions. Example question starters: “What happens when…”, “What if a user does …”, “When happens, what else happens?”, “Who is notified of…” Considered Questions are your secret skill to keeping things open during an exploratory testing session. It avoids the trap of just checking if something is a pass or a fail. Questions help you make more informed observations and encourage note-taking.

Heuristics: List a set of heuristics that you can refer to during your exploratory testing session. Heuristics are shortcuts that spark test ideas and help guide our testing efforts. They are fallible so we can’t solely rely on them, yet they are super helpful to refer to when deciding what to test next during a session. CRUD (Create, Read, Update, Delete) is a popular heuristic. The combination of oracles and heuristics is powerful.

You’re now ready to start your timer and go exploring!

Interconnected: All five items of the TORCH are intertwined. They support each other in providing a more holistic approach to exploratory testing. Like a superpowered torch with an adjustable beam, they light up parts of your exploration which wouldn’t seem possible with scripted testing.

What’s the verdict? Give the TORCH technique a go and comment to let us know how you get on.