beginner30 minby DevFox

Exploratory Testing

Testing without a script, done properly: charters, time-boxing, note-taking and heuristics. The technique that finds the bugs your written cases were never going to.

Testing
QA

Five hundred test cases passed. An hour of unscripted poking found five bugs, and the worst of them was this: a CSV import that failed halfway left the first forty-nine rows in the database while telling the user nothing had been imported. Run the same file again and those forty-nine arrived a second time.

No case covered it, and no case was ever going to. Somebody would have had to imagine a partial failure before the feature existed.

That is the ceiling on a written suite, and exploratory testing is how you get above it: designing and running tests at the same time, letting what you find decide what to try next. It is not "clicking around", and the difference between the two is the whole content of this lesson.

By the end you will know how to run a proper session, how to keep notes that make your findings reproducible, and a set of prompts for when you run out of ideas.

Why a written suite has a ceiling

A test case is a prediction. Writing "the reset link should be rejected the second time" means somebody thought of second uses before the software existed.

So five hundred cases cover five hundred predictions, and the defects that reach production are almost always outside that set — the combination nobody put together, the state nobody imagined, the sequence no requirement described.

Scripted

Repeatable, reportable, automatable.

Anyone can pick it up and get the same answer. It gives you a baseline you can point at.

It can only ever find bugs somebody already imagined.

Exploratory

Finds what the scripts do not know about.

What you find in minute three changes what you try in minute four — something a script structurally cannot do.

It gives no coverage number and no repeatability on its own.

Two different jobs. A team doing only one of them has a hole.

The thing it is not

Undirected clicking is what people picture, and it has three specific problems. No boundary, so you drift and re-cover the same ground. No record, so an interesting finding cannot be reproduced. No accountability, so nobody can say afterwards what was examined.

Three pieces of structure fix all three, and everything inside them is free.

A charter

One sentence naming the mission.

So the session has a subject, and so you can tell whether an interesting thread is on it or not.

A time box

Usually 60 or 90 minutes.

So it has an end, can be planned around, and does not quietly become the whole day.

Notes

Written as you go, not afterwards.

So a finding is reproducible and the session is reportable — including what you did not get to.

The entire difference between a session and an afternoon of clicking

Writing a charter

A charter is one sentence naming what you will explore, and often how. Specific enough to give direction, loose enough to allow discovery.

The pattern is: explore X with Y to discover Z.

Compare that with "test the import feature". The charter says what counts as being on-task, which is what lets you follow an interesting thread without losing the thread you were on.

Where charters come from: an area that has just changed, an area that produced defects before, a feature whose requirements were thin, a part of the product nobody has looked at in months, or a specific worry somebody has voiced.

Running the session

Ninety minutes, one charter, notes as you go.

You will find yourself doing the same three things over and over. That loop is the engine of the whole technique.

A question
Something you do not know about the software yet. "What happens if the file is empty?"
An experiment
The smallest thing that would answer it. Upload an empty file.
A result
Which is interesting whether or not it is a bug — because it is what tells you the next question worth asking.

And then the fourth step is the first one again

While you work, note four kinds of thing:

Real notes from a session, and they look like this rather than like prose:

Two things about those notes. The timestamps make the sequence reproducible, which matters when a bug depends on order — as BUG-2 did. And the last line reports what was not covered, which is what makes the session honest and lets someone decide whether to charter another.

Heuristics, for when you run out of ideas

Twenty minutes in, the obvious things are done. Heuristics are prompts that generate more, and having a list is what separates a productive session from a stalled one.

The input shapes from the earlier lesson are the first resort: empty, zero, negative, enormous, unicode, apostrophes, boundaries.

Interrupt it. Close the tab mid-action. Press back. Refresh during a save. Turn the network off halfway. Open two tabs and act in both.

Do it twice. Submit twice, quickly. Then again after a failure. Then again tomorrow.

Go the wrong way. Skip a step. Reach step three by its URL without doing steps one and two. Use the back button instead of a Cancel link.

Be the wrong person. Log out and try. Log in as someone who should not have access. Use a URL belonging to another user's record. Change an id in the address bar.

CRUD it. For any object: create it, read it, update it, delete it, then try to read it again. Then delete it twice.

Follow the data. Create something, then look for it everywhere it should appear — the list, the search, the export, the report, the email, the audit log. One of those places is usually forgotten.

Change the environment. A narrow window. A phone. Zoom to 200%. Keyboard only, no mouse. Dark mode. A different time zone.

Break the assumption. Whatever the feature assumes is true — that there is data, that the user has one of something, that the file is small, that the request arrives in order — make it false.

The session that cannot be reported

Bad — a session with no charter and no notes:

Good — a charter, a time box, and what came out:

The first report is a real cost, not just a missed opportunity. The issues cannot be fixed because they cannot be reproduced. Nobody can tell what was examined, so the area has to be tested again from nothing. And "mostly around error handling" gives a developer no way to start.

The second is the same afternoon, reported so that five defects are actionable, the biggest risk is named first, and the gap is explicit.

Where it fits

Exploratory testing is at its most valuable in four situations:

A new feature, before writing cases. Explore first, then write cases for what you learned. Cases written from real experience of the software are much better than cases written from a requirement.

When requirements are thin. If nobody can tell you what it should do, you cannot write a case yet — but you can go and find out what it does.

After a fix, around the fix. The sanity-check neighbourhood from the previous lesson is a small exploratory session.

On a schedule, in high-risk areas. A recurring session on payments, permissions or data export finds things the regression suite has stopped being able to see.

It is also worth pairing occasionally: two people at one screen, one driving and one asking questions, find things neither would alone.

Cheat sheet

Where to go next

You have found something. The next lesson is about what happens then — writing a bug report that gets fixed rather than closed, which is a specific skill and the point at which your work either becomes a change in the software or does not.

Before that, run one real session: pick a charter, set a timer for sixty minutes, and keep notes in the format above. The discipline feels constraining for the first ten minutes and then does not, and the difference in what you find is immediate.