Exploratory testing
Written test cases check what you already expected. Exploratory testing finds what nobody expected: the photo that vanishes, the receipt sent twice, the count that drifts when the signal drops. This lesson shows you how to explore with a clear aim, a time box and notes that other people can use, on the Store app's new receiving flow.
By the end you can
- Explain exploratory testing as learning, test design and execution at the same time, and say when it beats a script
- Write a focused charter with a target, resources and the information you want
- Run a time-boxed session, keep a session sheet and lead a debrief
- Use heuristics such as SFDIPOT, Goldilocks, CRUD and interruptions to choose what to try next
- Name the oracle that tells you a behaviour is wrong, and decide when to stop
The everyday picture
You are looking at a flat to rent. The agent hands you a checklist: kitchen fine, bathroom fine, two bedrooms. A careful renter does more. You turn on the shower and flush the toilet at the same time to see if the water pressure drops. You check the phone signal in the bedroom. You open the cupboard under the sink and find a damp patch, so now you look at every wall behind a pipe. Each thing you notice tells you where to look next.
You still have a plan. You have 30 minutes, and one question in mind: is this safe and comfortable for a family with a baby? You write down what you find, so you can compare flats tonight and ask the landlord about the damp. That is exploratory testing: a clear aim, a time limit, free choice of the next step, and notes.
What exploratory testing is
Exploratory testing means you learn about the product, design tests and run them at the same time. Each result shapes the next test. The ISTQB Foundation Level syllabus (version 4.0, 2023) lists it among the experience-based techniques, next to error guessing and checklist-based testing.
Compare it with scripted testing, which you designed in Designing tests that find bugs. A script is written before you touch the build. It is repeatable and easy to review, and it checks the rules you already know: the boundaries, the decision table, the states. Its weakness is that it only asks the questions you thought of in advance. Exploration asks the questions the product suggests while you use it.
Exploring is a discipline, and random clicking is its opposite. Random clicking has no aim, no record and no way to tell anyone what was covered. An exploratory tester has a written aim, a fixed time, a set of ideas for what to try, and notes that show what was tested and what was found. The freedom is in choosing the next step, based on what you just saw.
Here is the flow you will explore in this lesson. Mangrove Market is replacing paper and chat-group photos with a new receiving flow in the Store app, on about 1,000 handheld scanners. A receiver scans the barcode on the supplier's delivery note, and the app loads the matching purchase order (PO). The receiver counts the cases on each line by scanning them, marks lines short, over or damaged, takes photos of damage, and submits the goods received note (GRN). The stock room often has no signal, so the app must keep working offline and sync later. Each store gets about 4 deliveries a day, two people receive them, a receipt takes about 51 minutes, and about 1 GRN in 12 is corrected later. That last number is the reason for the project.
Exploration earns its time in a few clear situations: a new feature with thin requirements, a risky area where the written cases all pass but people are still nervous, a bug fix whose side effects you cannot list, and any time you have hours, not days. It also feeds scripted testing. A bug you find by exploring often becomes a new written test case, or an automated check, so it stays found.
Quick check
Which of these is exploratory testing?
The second tester learns from a result and designs the next tests on the spot, with notes. Tapping everything has no aim and leaves no record of what was covered. Running written cases is scripted testing: useful, but the questions were fixed in advance.