# Automated exploratory testing: what agents can explore, and what they can't

> What exploratory testing means, what changes when an AI agent does the exploring, five tools that try it, and the parts of the job no agent does yet.

Source: https://qa.tech/blog/automated-exploratory-testing · Published: 2026-10-30

---
Automated exploratory testing means pointing an agent at a running application and letting it decide what to do next, instead of replaying steps somebody wrote down. It opens the app, reads the screen, picks an action, observes the result, and uses that to choose the next action. No test case file. No recorded script.

That is real and it works. It is also not the thing Cem Kaner named in the 1980s, and the gap matters.

**What it replaces:** the first hour of poking at a new build to see what's there. Coverage discovery. The grind of writing the forty-first regression case for a flow nobody has time to script. Hitting a form with inputs nobody thought to try.

**What it does not replace:** a tester's judgement about whether the thing that happened was the right thing to happen. An agent can tell you the checkout page returned a 500. It cannot tell you the checkout page is confusing. Those are different jobs and only one of them is automatable today.

## What exploratory testing actually means

Cem Kaner coined the term. The definition he gave in his 2006 QAI keynote is the one to use:

> "Exploratory software testing is a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the value of her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project."
> – Cem Kaner, ["Exploratory Testing", QAI, 17 November 2006](https://kaner.com/pdfs/ETatQAI.pdf)

The load-bearing words are *personal freedom and responsibility of the individual tester*. Kaner put a person's judgement at the centre on purpose. That is not a description of a technique. It describes who is in charge of the technique.

James Bach, who is often credited with the term, says otherwise: ["I didn't coin the term exploratory testing. Cem Kaner did that in the 80's."](https://www.satisfice.com/exploratory-testing) His own compressed version is the one most practitioners carry around: "Exploratory testing means performing tests while learning things that may influence the testing."

That shorter definition is the interesting one for our purposes, because it describes a loop rather than a person, and a loop can be implemented. Learn, test, let what you learned change what you test next.

Session-based test management is the structure teams bolt on to keep exploratory work accountable. The seminal write-up is [Session-Based Test Management](https://www.satisfice.com/download/session-based-test-management), which James Bach describes as written with his brother Jon "based on the process we pioneered at Hewlett-Packard." Time-boxed sessions, a charter, a debrief, notes. Run a bug bash with a two-hour timer and a shared doc and you have run a rough version of it.

ISTQB has its own wording. The ISTQB glossary site returns a page but renders no definition text, so we are citing an intermediary: [imbus](https://www.imbus.de/en/glossar/term/exploratory-testing) reproduces, from a page based on the ISTQB Standard Glossary v3.4 (14 September 2020), a second definition reading "experience-based testing in which the tester spontaneously designs and executes tests based on the tester's existing relevant knowledge, prior exploration of the test item (including the results of previous tests), and heuristic 'rules of thumb' regarding common software behaviours and types of failure." Check the glossary directly before you quote that in a doc of your own.

All three say the same thing: you learn about the system while testing it, and what you learn redirects the testing. Kaner's adds the tester's freedom. ISTQB's adds experience and heuristics. Both additions are exactly where agents are weakest.

## What changes when an agent does the exploring

The loop survives translation. The judgement does not, or not all of it.

An agent exploring an app does something recognisable: it observes the current state, generates candidate actions, picks one, executes it, and feeds the result back into its model of the application. Total Shift Left describes the category plainly: agentic QA tools ["use an LLM agent to explore an application or API, decide what to test"](https://totalshiftleft.ai/blog/agentic-qa-tools). That is Bach's loop with a model in the driver's seat.

Four things change.

**Volume.** A human tester gets two sessions a day if the calendar is kind. An agent gets as many as you pay for. A QA lead at a games company, speaking Swedish and translated here, described what that buys: "If I could get a million agents that tested every build and just clicked in and played a few levels and made a few purchases and used a few boosters – if I could get a million agents, I'd want that."

**Memory.** Human sessions leak. Notes get written, notes get lost, the tester who knew the odd corner of the billing flow changes jobs. An agent that persists what it found carries it forward. On QA.tech this is a knowledge graph, which our docs describe as ["a digital representation of facts and relations. This can be used as an AI agent's understanding and memory of a website"](https://docs.qa.tech/core-concepts/knowledge-graph), built by crawling: "We create a large graph of all the interactions we can perform on your website. If you are familiar with sitemaps, this is like a sitemap on steroids."

**Patience.** Agents do not get bored on the fiftieth permutation of a search filter. A lot of exploratory value sits in the tedious part of the space, which is the part a human session skips when the clock runs short.

**Blindness to intent.** This is the cost. The agent sees what the application did. It does not know what you meant. That is the Kaner gap, and no amount of model capability closes it on its own, because the information is not in the application.

What does not change: someone decides the charter, and someone reads the findings and says which are bugs. Exploration produces candidates. Total Shift Left again, on exploratory agents: ["Useful for finding candidates, not for gating."](https://totalshiftleft.ai/blog/agentic-qa-tools)

A director of engineering at a small B2B software team spelled out the ask: "So I'm looking for an exploratory kind of bug bash where we can set it up, point to a URL. It goes in, we don't necessarily have to give it, test cases, it can go in. Try the different functionality and just, you know, hit the system with, um, you know, different conditions, test the different user permissioning, validate searches." They were explicit that this is not a regression ask. "I'm not looking for regression because I've already got that covered with automation. I'm really looking for just a quick and dirty, pointed at a Url and say, tell me everything you can find."

Their reason for wanting it had nothing to do with coverage metrics: "the biggest risk right now to the software development lifecycle is one Qa tester, right? If he's out, he gets sick, he gets hit by bus, and we have capacity issues, right? ... so we can deliver more code than we can test."

## The tools

Every tool below is sold on roughly the same promise: point it at a running application and get coverage without writing the steps yourself. How close each one gets to that, and how much authoring is actually involved, varies a lot. Every capability below is quoted from a named source and linked, so you can check it yourself. Where a source is the vendor describing its own product, that is said in the entry.

### Momentic

An AI QA agent for end-to-end web testing. Mo is positioned as an agent that tests your app end to end and finds bugs from a prompt, but the main flow is authored: you write the user flows you need to verify. It keeps a graph of screens and flows it has seen during test runs, which is the closest thing here to persistent exploration. The word "crawl" appears nowhere on the pages we read. They concede the hard parts rather than hiding them: permanent healing proposes a test-file repair for a human to review, and triage can quarantine what it cannot fix. [Momentic](https://momentic.ai) states that Mo is in private beta, and lists web, iOS and Android execution, with web running Chromium and Chrome.

**Pick it if** you want authored flows with an agent executing them and you value explicit human review on repairs.
**Skip it if** you want to hand over a URL and get findings back with no authoring.

### mabl

Low-code test automation with an agentic layer. [Their agentic AI testing post](https://www.mabl.com/blog/agentic-ai-testing) never uses the term "exploratory testing" at all. Where it describes exploration it is describing Playwright's Test Agents, not mabl's own: three chained AI agents (Planner, Generator, Healer) that explore an app, write test code, and auto-fix broken selectors. On its own product the claim is that coverage "builds itself, runs itself, and fixes itself", with no mechanism given. That is mabl describing its own product, and the page gives no mechanism behind it.

**Pick it if** you are already a mabl shop and want the agentic additions on top of an existing suite.
**Skip it if** exploratory discovery is the actual requirement; it is not what this product is positioned around.

### TestSprite

A verifier that learns the app before it tests it. On [its own site](https://www.testsprite.com) TestSprite says it "explores and works out how your app actually behaves", and that "that understanding is the spec", with no prompts and no test scripts. It plugs in as a CLI, as an MCP server in your editor, and as "a gate on every merge". The word "exploratory" appears nowhere on that page, so this is discovery sold as coverage generation rather than as a bug hunt.

**Pick it if** you want discovery and coverage generation in one pass, driven from the editor or the CLI your coding agent already uses.
**Skip it if** you want a session that hands you findings to triage; this is positioned as a merge gate.

### Spur

The broadest stated scope of the set. Via [Ry Walker's research on AI QA agents](https://rywalker.com/research/ai-qa-agents), Spur is specialised for e-commerce QA and ships five agents: "functional, exploratory, UI/UX, localization, and AI-feature testing." Exploratory is named as a first-class mode, which is rarer here than you'd expect. Ry Walker is an independent researcher, not a reseller, and his own caveat on the whole category is that "independent validation is nearly absent."

**Pick it if** you want one agent covering several testing types including a named exploratory mode.
**Skip it if** you'd rather have one mode that is deep than five that are stated.

### QA.tech

Ours, listed last for that reason. It will not hand you a bug hunt on an unfamiliar URL in five minutes, and it does not export Playwright or any other test code. What it does instead: an agent crawls your web app and builds a knowledge graph of the interactions in it, and that graph is what later runs reason over. Crawling is started by a person in chat with `/crawl`, not running continuously: the assistant decides where to start, how deep to go and what to skip, and reaches pages behind a login by reusing the browser state from a successful login test, and stays within the domains allowed for your project. Each iteration records a screenshot, the source action, depth, the actions it found, and an Intent Score rating relevance to your goal (0-40% low, 41-70% moderate, 71-100% high).

On a pull request, a change review reads the PR, selects existing tests covering the user-facing change, generates the ones this diff needs that do not exist, runs them, and posts the result on the request. The generated tests persist as Drafts labelled `ephemeral`: they keep running as part of the review while staying outside the scheduled suite. `ephemeral` is a label, not a lifespan, and the tests are not discarded. Our GitLab docs describe that as running exploratory and end-to-end testing against your merge request; the mobile PR page labels the mode "Change review (AI exploratory)". The review needs somewhere to run: a deployment your Git host reports, a preview URL in a `@qa.tech` comment, or the deployed environment after merge. Backend-only changes cannot be reviewed, because the review needs UI access. Web execution is Chromium only. Total Shift Left describes us as a tool that ["explores the app and proposes regression cases from what it finds"](https://totalshiftleft.ai/blog/agentic-qa-tools), and *proposes* is the verb that matches what the product does.

Scheduled regression is a separate decision. If enabled, the opt-in post-merge agent reviews the test cases surfaced during that PR's review and activates only the ones worth keeping, labelling them `regression` and `auto-added`. As the GitHub documentation puts it, "Promoting nothing is a normal outcome." Generating a test does not automatically add it to the scheduled suite; that requires deliberate promotion.

**Pick it if** you want exploration that feeds a persistent model of your app, and a per-PR check that reads the change and tests against it. More on both: [exploratory testing use case](https://qa.tech/use-cases/exploratory-testing), [exploratory testing in pull requests](https://qa.tech/changelog/exploratory-testing-pull-requests).
**Skip it if** you want a continuously running autonomous explorer with no human kickoff, or non-Chromium browser coverage.

| Tool | Exploration without authored steps | Persists what it learned | Runs on a PR |
|---|---|---|---|
| Momentic | Partial; flows are authored | Graph of screens and flows from test runs | Stated |
| mabl | Not positioned for it | Not stated | Yes |
| TestSprite | Stated | Learns the app, persistence not stated | Stated as a merge gate |
| Spur | Stated as a named mode | Not stated | Not stated |
| QA.tech | Yes, human-initiated crawl | Knowledge graph | Yes, change review |

Every "stated" in that table means the vendor or a named researcher said so on a page we have linked. We have not run these tools side by side, so read the column as what each one claims, not as a benchmark.

## Where this breaks down

**An agent needs a running application in a known state.** Total Shift Left puts it flatly: exploratory agents "need a running application in a known state." If your preview environments are flaky, half-seeded, or sharing a database with somebody else's run, the agent spends its session discovering your infrastructure rather than your product. That is the most common reason a trial goes badly.

**Exploration produces candidates, not a gate.** Treat the output "as a bug-hunting session, not a suite", in Total Shift Left's phrasing. Somebody reads it. Somebody decides which findings are real. Pipe unreviewed exploratory findings straight into a merge gate and you will be switching it off inside two weeks. A change review that selects named tests against a diff and runs them is a different artefact, and that one can block.

**The agent cannot know which behaviour is intended.** This is the Kaner judgement gap, and it is not a rough edge that gets sanded down next quarter. An agent observes current behaviour. If that behaviour is a bug, the agent can and will encode the bug as expected. Nothing in the running application tells it which it is looking at. Only the spec, the ticket or a person does.

**Self-healing is not free.** [Total Shift Left](https://totalshiftleft.ai/blog/agentic-qa-tools) names the problem. An assertion quietly rewritten to match new behaviour "has removed the signal you bought it for." Their rule for what acceptable repair looks like is worth copying: "propose the repair, show the diff, and let a human accept it." A suite that heals itself into agreement with whatever the app currently does is not a test suite.

**Demos are not production.** Octomind, an AI testing company, shut down. Via Ry Walker: "we didn't find the market validation we needed to keep going." An ex-Octomind engineer's summary is the sentence we'd put on the wall: "The gap between 'works in a demo' and 'works in production with adversarial input' is massive."

**Our own telemetry is capped.** Per test execution on QA.tech, console logs are capped at 100, network requests at 1000, and accessibility issues at 10. Beyond that, in the docs' words, "further events of that type are not captured or stored." For a noisy single-page app, 100 console entries is one page load. If you are debugging from the trace, know the ceiling before you rely on it.

An agent does not judge usability. It does not know whether something *feels* wrong. It does not experience accessibility; it can flag a missing label, which is not the same as knowing a screen reader user is stuck. It does not do ethical evaluation. The agent cannot tell you an interface is clunky.

A senior QA lead at a travel technology company, speaking Swedish, translated:

> "We don't run the manual tests that way – we have automation in place. ... And exploratory becomes a substitute for... everything that is usability, accessibility, intuition, emotion, everything that is the customer perspective. And that's where I don't know and don't see how AI can right now replace a real persona in that way. With all the cognitive side and the experience."

They are right, and there is no counter to offer. Their team already has regression automation, and what they value in exploratory work is the human perspective. An agent does not supply it.

Total Shift Left's framing is "pointing an agent at an application to find states a scripted suite never reaches." That is the offer, and it is smaller than the marketing in this category usually makes.

The games-company QA lead quoted earlier landed on the same split without being prompted: "The more interesting thing would be to be able to do part of the work the QA specialists do today. So they can focus on other things."

## FAQ

**What is exploratory testing?**
Testing where design, execution and interpretation happen together, and what you learn changes what you test next. Cem Kaner, who coined the term, defines it as a style emphasising "the personal freedom and responsibility of the individual tester", treating learning, test design, execution and result interpretation as parallel, mutually supportive activities.

**Who invented exploratory testing?**
Cem Kaner, in the 1980s. James Bach says so himself, and Bach's own one-line version is "performing tests while learning things that may influence the testing." Session-based test management, the common way of structuring exploratory work, was written up separately by Jonathan Bach.

**Can an AI agent really do exploratory testing without test cases?**
It can run the loop: observe, act, learn, act again, with no test case file. Several tools do this today. What it cannot do is Kaner's version, which is built around a person's judgement. Call it automated exploration and expectations land in the right place.

**Is automated exploratory testing a replacement for a QA engineer?**
The teams buying it are mostly not trying to replace anyone. The ask we hear is capacity. One QA engineer is a single point of failure, and teams ship more code than they can test. An agent covers the mechanical part of a session so the person spends their hours on judgement.

**What is the difference between automated exploratory testing and regression testing?**
Regression testing checks that known behaviour still holds. Exploration goes looking for behaviour nobody has described yet. A lean scheduled regression suite is what you keep for the flows that must never break; exploratory output is a pile of candidates somebody triages. See [regression testing in pull requests](https://qa.tech/blog/regression-testing-in-pull-requests) for the gate half.

**Is exploratory testing the same as dynamic testing?**
No. Dynamic testing is any testing that runs the code, unit tests and scripted end-to-end runs included. Exploratory testing is one style of it, distinguished by the tester designing while executing. The wider category is covered in [what is dynamic testing](https://qa.tech/blog/what-is-dynamic-testing).

**How do I evaluate an exploratory testing tool in a trial?**
Give it a stable, seeded environment; a flaky one tests your infrastructure instead of the tool. Pick an area where you already know three bugs exist and see how many it finds. Read the findings yourself rather than counting them. Then watch the second run. Whether anything it learned the first time survived is the question that separates these products.