Manual exploratory testing isn't dead — it's underused

I do both manual and automation testing. The manual half is the half I'd defend hardest.

Two things called "manual testing"

The conflation at the root of this argument: "manual testing" is used to describe two completely different activities.

Regression checking is running through a documented test script to verify that known behaviour still works. "Go to the login page. Enter valid credentials. Click Sign In. Verify you reach the dashboard." This is manually following a script someone wrote when the feature was built. It's the same path, run repeatedly. It's tedious, it scales poorly, and it tests nothing new. This is the activity automation replaced, and automation replaced it correctly. A machine that runs a script 50 times is better at that job than a human.

Exploratory testing is using the software with curiosity and intent to find problems that the documented paths didn't anticipate. No script. A charter (a brief description of a goal: "explore the checkout flow with unusual payment configurations"), a time box (typically 60–90 minutes), and a skilled tester asking: what happens if I do this? What does this error message mean in practice? Does this UI state make sense? What would a confused user try next?

These are categorically different activities. Automation is excellent at the first. Automation cannot do the second. The argument that "automation killed manual testing" is correct about the first and completely wrong about the second — and the mistake is calling both of them "manual testing."

What humans do better than automation

The things a human tester does in an exploratory session that no automated test can replicate:

Curiosity-driven path exploration. A tester who notices "that button looks slightly off-centre" might click around it and discover that the clickable area is misaligned with the visual target — a bug that would never appear in an automation suite because no assertion checks for it. Automation checks what it was told to check. Humans notice what looks wrong before they know whether it is.

Usability judgement. "This form technically works, but it's confusing" is a finding that no assertion can produce. Whether a UI makes sense to a user, whether an error message explains what happened, whether the sequence of steps feels rational — these require a human with theory-of-mind. Automation verifies correctness; it cannot evaluate comprehensibility.

Edge cases that look weird to a human. A tester trying to find bugs will try things that a script never would: copying text from one field and pasting it into another to see what happens, uploading a file with an unusual extension, entering an address in an unexpected format, switching between tabs mid-flow, using the browser back button in the middle of a multi-step form. These are the cases where production bugs live. Automation doesn't try these unless someone explicitly programmed each one.

Accessibility experience. Running through a flow with a keyboard only — no mouse — and noticing where focus gets lost, where tab order is wrong, where a visual element has no keyboard equivalent. A tester using a screen reader for 15 minutes finds more real accessibility failures than axe-core finds in automated runs. Automated accessibility tools catch 30–40% of WCAG failures. The rest require a human.

The "this feels broken" signal. Sometimes a tester can articulate exactly what's wrong. Sometimes the finding is "something about this page feels off, let me dig in." That intuition — the sense that something is wrong before the formal defect description is complete — is a human capability that generates investigation paths automation can't initiate.

Session-based testing as the modern format

The script-based approach to manual testing — test case IDs, expected results in a spreadsheet, pass/fail checkboxes — is the version of manual testing that automation correctly displaced. It was always a poor model: it confused following instructions with finding problems, and it produced documentation rather than insight.

Session-based test management (SBTM), developed by James Bach and Jonathan Bach, is the structure that makes exploratory testing rigorous without turning it back into scripted testing. The core elements:

Charter: a brief statement of what you're exploring. "Explore the user settings page with a focus on privacy and data export options." Not a script — a direction. One charter per session.

Time box: 60–90 minutes. Short enough to maintain focus. Long enough to find something worth finding. When the time box ends, you debrief.

Debrief: a short discussion (10–15 minutes) capturing what was tested, what was found, what was blocked, and what warrants follow-up. This is the record-keeping that replaces the pass/fail spreadsheet.

Session logs replace test case documentation: what was explored, what tools were used, what defects were filed, what questions arose. They're readable by a human; they document what was learned rather than what was checked off.

Where exploratory testing fits in 2026

The common mistake: treating exploratory testing as the last-week-of-sprint activity, squeezed in after automation finishes running and before the release candidate is cut. This makes exploratory testing a formality — there's not enough time to explore deeply, defects found this late are expensive to fix, and the signal is compressed into a narrow window.

Exploratory testing belongs parallel to development, not after it. A tester exploring a feature while it's being built finds design problems when they're cheap to fix. A tester exploring the integration between two features before the sprint ends finds interaction bugs before they reach the QA environment. The earlier exploratory testing runs in the development cycle, the more valuable its findings.

Ownership is the second mistake: treating exploratory testing as something only QA does. In teams without dedicated QA engineers, exploratory testing often doesn't happen at all — developers test their own code functionally (does it work?) but not curiously (what breaks it?). The activity doesn't require a QA job title; it requires time, intent, and the permission to spend 90 minutes trying to break something rather than build something.

The argument that wins budget for exploratory time

The pushback is usually: "We have automated tests. Why do we need manual sessions?"

The answer: your automated tests verify the paths you thought of when you wrote them. They don't verify the paths you didn't think of. Every bug that ever reached your users was, by definition, not covered by your automated tests — otherwise the tests would have caught it.

Exploratory sessions exist specifically to find those bugs. Pair every automated regression run with an exploratory session on a related area, and you get the complementary coverage: automation verifies the known paths, exploration finds the unknown failures.

The transition into automation doesn't require leaving exploratory testing behind — the two are not alternatives. Automation handles regression efficiently. Exploration handles discovery. Teams that do only automation get fast, stable regression coverage with blind spots in everything they didn't anticipate. Teams that do both get fast regression coverage and a systematic way to find what the regression suite misses.

Manual exploratory testing isn't a legacy activity that teams grow out of as they mature. It's the activity that finds the bugs automation structurally can't find — and it gets more valuable as the automated suite gets larger, because the larger the suite, the more confidence teams place in its coverage, and the more dangerous the blind spots become.