Unscripted Discovery

## The loop, not the absence of a plan Scripted execution separates three activities in time. Someone studies the product and designs cases, the cases are written down, and later — possibly by someone else, possibly months on — a run executes them as written. The value of that separation is repeatability: the same steps produce the same evidence every time. Exploratory testing collapses the three into a single loop. You learn something about the product, that learning suggests a test, you run it, and what you observe changes what you believe and therefore what you try next. Design happens continuously, at the keyboard, informed by everything seen so far. The classic phrasing is that test design and test execution are simultaneous, with learning as the thing that connects them. The most common misreading is that unscripted means unplanned. It does not. It means the plan is written at the speed of the work rather than in advance, and that the tester is trusted to redirect. A candidate who says "exploratory means just clicking around" has described the thing exploratory testing is defined against. ## Three things that separate it from ad-hoc poking **A mission.** Before starting you say what you are exploring and what you are looking for — an area, a risk, a recent change, a user role. The mission is the thing you can be held to and the thing that lets two testers split a product without both hunting the same screen. Ad-hoc work has no stated target, so it drifts to whatever is most visible, which is usually the happy path someone already covered. **A bound.** The work is given a finite block of attention rather than running until interest fades. A bound turns exploration into something a plan can contain: it can be scheduled, estimated, and stopped without guilt when the block ends. **A record and a hand-back.** Notes taken while working, plus a short spoken account afterwards of what was covered, what got in the way and what is still unexplored. This is what makes exploration reportable — without it, the only artefact is the bugs found, and an area that was tested thoroughly and found clean is indistinguishable from an area nobody opened. Strip those three away and you are left with ad-hoc testing: unrepeatable, unassignable, and invisible in any coverage discussion. That is why ad-hoc is generally treated as a description of what happened rather than as a technique anyone plans. ## What the loop looks like in practice Take a grant-application review queue. You start knowing only that reviewers pull applications off a queue, score them, and submit. You learn that a submission writes to several places at once — a score, a decision record, an audit row. That learning immediately suggests a test the specification never mentioned: what happens when the write half-succeeds? You force a partial-failure rollback mid-submission and find that a batch of 37 applications comes back with 11 marked withdrawn instead of pending. Nothing about that test existed before you learned how submission was wired. A scripted pass written from the same specification would not have contained it, because the specification did not describe the wiring. That is the argument for the technique in one paragraph: exploration finds the tests that could only be designed after seeing the product, including entire categories of failure — partial failure, unexpected sequencing, surprising data — that nobody thought to specify. ## What it is not, and where the evidence stands Exploration is not a replacement for having any documented tests, and it is not a licence to skip preparation. Experienced practitioners prepare heavily: they read what exists, list risks, and arrive with a mission. It is also not a beginner activity, though it is often handed to beginners; the quality of the output tracks the tester's product knowledge and their stock of ideas about how software fails. On effectiveness, be careful in an interview. There is published research comparing exploratory and case-based approaches, and it tends to report that exploratory work finds a comparable or larger number of defects for the same effort while producing fewer documented artefacts — but the studies are small, the populations are narrow, and the results are genuinely contested. Say that it trades documentation for adaptability and that the balance is context-dependent; do not quote a multiplier as if it were settled. ## How to answer this in an interview Lead with the loop — learning, design and execution at once — then name the three things that make it disciplined rather than random, then give one concrete example of a test you could only have designed after seeing the product. If the interviewer pushes on rigour, the strongest move is to volunteer the weakness yourself: exploration is only as accountable as its mission and its notes, and a team that treats it as unmanaged time will get unmanaged results.