Exploratory testing: checking a product that has no documentation

Most products that arrive for testing either have no requirements or have requirements three releases out of date. Exploratory testing is a way to work in that reality: the tester studies the product, designs checks and runs them at the same time, and the session's result becomes a checklist that did not exist before.

What it is and what it is not

Exploratory testing is not "poking around at random". It is structured sessions with a time limit and a goal set in advance: check checkout with a promo code, go through account recovery by every path, break the sign-up form with unexpected data. Within the session the tester is free to choose steps but must record what was checked, what was found and which questions remain. Without notes it is not testing but a walk through the product.

How a session is structured

1. Charter: one sentence about what and why we explore — "Check what happens to the cart when language and currency change during checkout".
2. Timebox: forty minutes to an hour and a half; longer and attention scatters, shorter and there is no time to go deep.
3. Notes along the way: what was done, what was seen, what looked odd, which data was used. Screenshots and screen recordings are mandatory.
4. Debrief after the session: findings become defects with reproduction, oddities become questions for the team, covered paths become checklist items.

Techniques that yield more findings

• Boundary values: zero, negatives, maximum, empty string, a very long string, special characters and emoji in every field.
• Interruptions: background the app mid-payment, lose the network while submitting a form, press back on the confirmation screen.
• Repeats: press a button twice, submit a form twice, open the same operation in two tabs.
• Context switches: change language, currency, time zone, account — and return to the unfinished action.
• Other people's data: try to open another user's order by changing the identifier in the link.
• Stale states: pay for an item that just ran out; apply a promo code that expired a minute ago.

How the result becomes regression

After three to five sessions on the main flows there are enough covered paths to assemble the first version of a regression suite: every covered path with an expected result is a test case. That is how a product without documentation gets it in the most useful form — as verifiable statements about how it should work. This version is agreed with the product owner: they confirm what counts as normal, and at that moment oddities finally split into defects and features.

When exploratory testing is not enough

It does not replace pre-release regression: exploration looks for the new, regression confirms the old. It does not replace load tests and security checks — they have their own methods. And it works poorly without a debrief: findings not turned into tickets and cases are forgotten by the next release.