The same feature can be checked in different ways: strictly following pre-written test cases, freely exploring the product, or entirely at random. This is called the degree of formalization of testing, and it matters because each degree has its own domain. The main character of this article is exploratory testing — an approach where you think and check at the same time, and one many consider the most interesting part of the profession.

Three degrees of formalization

Scripted testing (test-case based) is the most formalized approach: the checks are described in advance and you execute them step by step. Its strengths are completeness and repeatability: nothing gets forgotten, any team member can execute the run, and metrics are easy to compute. Its weakness: cases only verify what's written in them — a bug living one step off the scripted path goes unnoticed.

Exploratory testing is a partially formalized approach: you study the product and invent checks as you go, building on what you've just seen. Each result suggests the next step: you notice something odd when entering a long name — you dig deeper; you find a pattern — you check it in the neighboring places. The key point: this is not aimless poking but guided investigation — you have a goal and you're moving toward it; only the route is built as you go.

Ad hoc testing is a fully unformalized approach: no cases, no checklists, no scenario goal — only intuition and experience. It's used rarely and only as a supplement: for instance, a ten-minute "fresh eyes" pass over a new build before any cases exist.

A frequent mistake is confusing exploratory and ad hoc testing. The difference is fundamental: exploratory testing has a goal, boundaries, and recorded results; ad hoc has none of that. The first is a method; the second is a warm-up.

How to run exploratory testing: sessions and charters

To keep the investigation from sprawling, it's packaged into sessions — time-boxed passes (usually 60-120 minutes) with an explicit goal. The goal is written down in advance in a sentence or two — that note is called a charter: "explore order checkout with promo codes: discounts, combinations, expired codes." This approach is called session-based testing.

During the session you keep short notes: what you checked, what looked odd, which bugs you filed. Afterwards the notes show what's covered and what remains — so you can report honestly instead of "well, I clicked around."

A lighter variant is testing against a checklist: a list of what to check without spelling out how. Halfway between cases and free exploration: the direction is set, the route is yours.

Error guessing

An experienced tester often goes straight to where things "usually break" — that's the error guessing technique. It relies on knowing the typical weak spots: value boundaries, empty and overly long inputs, special characters, actions in an unexpected order, double clicks, a dropped connection mid-operation.

A beginner doesn't have that collection yet — but it accumulates quickly if, after every bug you find, you ask yourself: "where else could the same mistake live?" A found bug is not just a tracker entry — it's a hint for your next checks.

What order to check in: from simple positive to complex negative

A practical principle that saves a lot of time. Start with simple positive checks: enter everything correctly, follow the main path. Then simple negative: obviously invalid data, empty fields. Then complex positive: correct but intricate scenarios. And only at the end — complex negative: exotic combinations of errors.

Why this order: if you dive into the exotic right away, you can end up with a product that heroically survives clever attacks but doesn't work in the elementary everyday scenario. First make sure the essentials work — then escalate. It's not dogma, but deviate from it deliberately.

What to combine with what

The approaches don't compete — they complement each other:

  • Cases — for regression, critical scenarios, and everything that must be re-checked repeatably from release to release.
  • Exploratory sessions — for new features (no cases exist yet), areas after big reworks, and "suspicious" spots. And as a regular addition to cases: what the scripts don't cover is exactly what sessions find.
  • Ad hoc — a short reconnaissance when you need a first impression of a build quickly.

Where this applies

In a regular sprint it looks like this: for a new task you first run an exploratory session (collecting ideas for future cases along the way), then formalize the stable checks into regression cases. The ability to run a guided investigation — rather than just "poke around" — is what separates a tester from a random person with a mouse.

Where beginners stumble:

  • They substitute chaos for investigation. Without a charter and notes, a session turns into aimless wandering with nothing to tell the team about.
  • They consider cases "boring" and exploration "the real thing" — or the reverse. You need both: cases hold the foundation, exploration finds the unexpected.
  • They start with the exotic. Half an hour on emoji input in the name field — while the ordinary form save hasn't been checked even once.

What to learn next. Ideas for exploratory sessions come from test design techniques — boundaries and equivalence classes work without formal cases too. And how to record what you find — in the article about bug reports.