AI-assisted exploratory testing

You have ninety minutes booked to explore the new team invite flow. You know roughly what you will do: invite someone, accept the invite, remove them, try a few bad email addresses. Twenty minutes in, you have found nothing, and you are already repeating yourself.

The problem is not your skill. It is that your charter was too narrow before you started, and you had nobody to argue with about it.

That is the job an AI model can do well: not testing the app, but widening the plan and questioning your assumptions before and during the session.

Short version

Exploratory testing means learning the product and designing tests while you test, in one session.
A language model cannot run your session. It cannot see the screen, feel a slow page, or judge whether something looks wrong.
It is very good at listing what you forgot: variations, personas, states, and failure modes.
Use it in three places: before the session to widen the charter, mid-session when you stall, and after to sharpen your notes.
Keep a timebox. The model will happily suggest 60 ideas for a 60-minute session.
Every idea it gives you is a hypothesis, not a finding. You still have to go and look.

What exploratory testing is, in one paragraph

Exploratory testing is testing where design, execution, and learning happen at the same time. You do not follow a written script. You start with a charter — a one-sentence mission such as "Explore the invite flow with expired invites to discover permission errors" — set a timebox, take notes as you go, and let what you find steer where you go next.

The quality of a session depends heavily on one thing: how many good ideas you have about where the bugs might be. That is where a model helps.

Where the model helps and where it does not

Task	Model	You
List variations of an input	Strong	Slow
Suggest personas and roles to try	Strong	Easy to forget some
Recall standard heuristics	Strong	Patchy under time pressure
Notice a layout that "feels off"	Cannot	Immediate
Judge whether a bug matters	Weak	Strong
Follow a hunch	Cannot	This is the whole skill
Notice a 4-second delay	Cannot	Immediate
Read a console error and connect it to what you clicked	Partial	Strong

The honest summary: the model expands the search space, you search it.

Step 1: Widen the charter before you start

Give the model your charter and ask it to attack it. This prompt takes thirty seconds and usually adds three or four directions you had not considered.

I am about to run a 90-minute exploratory testing session on https://staging.example.com.

My charter: "Explore the team invite flow to discover bugs in permissions and invite states."

Do three things:

List 8 variations of this charter that would find different bug classes.

List every state an invite can be in, including states I have probably forgotten.

List 6 user roles or personas whose experience of this flow differs, and why.

Be specific. Do not give general testing advice.

For an invite flow, the state list alone is worth the prompt. You will get back things like: invited, accepted, expired, revoked, resent, invited to a workspace that was since deleted, invited with an email that already has an account, invited twice by different admins.

Half of those you had. The other half are where the bugs live.

Step 2: Turn heuristics into concrete prompts

Testing heuristics are short rules of thumb that remind you what to try. Models know the classic ones, and they can apply them to your specific feature rather than leaving them abstract.

Three that pay off consistently:

Interruption

For each step of the invite flow, list what happens if the user is interrupted: closes the tab, loses network, presses browser back, opens the same page in a second tab, or leaves it open for two hours.

Boundaries and bad data

Give me 15 email addresses that are technically valid, unusual, or likely to break naive validation. Include very long addresses, plus-addressing, unicode domains, and trailing whitespace. For each, say what the correct behaviour is.

Time and sequence

List 10 sequences involving timing that could break this flow, such as accepting an invite after it expired by one second, or an admin revoking an invite while the recipient is on the accept page.

That last category is where I most often see real bugs escape to production, and it is almost never in a written test plan.

Step 3: Use it mid-session when you stall

Twenty minutes in, you run dry. Instead of clicking randomly, paste your notes so far and ask one question:

Here are my session notes so far: [paste raw notes]

Based on what I have already tried, what are 5 areas of this feature I have clearly not touched? Do not repeat anything in my notes.

This works because you are not asking for creativity. You are asking for coverage arithmetic — comparing what you did against the space of what exists. Models do that quickly and without ego.

Keep the timebox. If the model gives you 12 ideas and you have 25 minutes left, pick the two riskiest and drop the rest into the backlog for next session.

Step 4: Sharpen the notes afterwards

Exploratory sessions produce messy notes. A typical line reads:

tried resending invite twice, second one 500'd, console had a red error about undefined

That is enough for you today and useless to anyone in three weeks. Ask the model to turn each observation into a proper report skeleton:

Turn each line of these session notes into a bug report skeleton with: title, steps to reproduce, expected, actual, and open questions. Mark anything where my notes are too vague to reproduce.

The "too vague to reproduce" flag is the useful part. It tells you which bugs to go back and re-check while the app state is still fresh.

Evidence still has to come from the real session, not the model. Screenshots, the exact console message such as TypeError: Cannot read properties of undefined (reading 'invitee'), and the failing network call are what make the report actionable. A browser-based capture tool like Crosscheck collects those from the page as you file the report, which keeps you inside the session instead of hunting through DevTools afterwards.

The failure mode to avoid

The tempting mistake is to turn the model's list into a script and work through it top to bottom. That kills the thing that makes exploratory testing work.

Bad: Model gives 30 ideas. You execute all 30 in order, tick each one off, and follow up on none of them.

Good: Model gives 30 ideas. You pick 5. Idea 3 produces something odd, so you spend 40 minutes on that one thread and ignore the other 27.

The moment something surprises you, stop consulting the list. Surprise is a signal. Follow it. The remaining ideas will still be there next session.

Two more small rules that keep sessions honest:

Never let the model write your findings. It did not see the screen, so anything it "reports" is invented.
Never let it estimate severity alone. It has no idea how many users hit that path or what your support load looks like.

A 90-minute session, structured

Here is a shape that works in practice.

0-5 min: Run the charter-widening prompt. Pick your angle.
5-10 min: Set up test data and accounts, such as [email protected] and a second admin account.
10-40 min: Explore freely against the widened charter. Take rough notes with timestamps.
40-45 min: Stall check. Run the coverage prompt if you are repeating yourself.
45-75 min: Follow the most interesting thread you found. Ignore the list.
75-85 min: Reproduce and capture evidence for anything you plan to report.
85-90 min: Run the notes prompt, then write the debrief in your own words.

The model appears twice, for about seven minutes total. That ratio is roughly right.

Frequently asked questions

Can an AI agent run the exploratory session for me? Browser-driving agents can click through an app and report errors, and they are useful for shallow crawls. They do not do exploratory testing, because they cannot form a hunch, notice that a page feels wrong, or decide that a small oddity is worth an hour of digging.

Does this work without giving the model access to our app? Yes, and that is the normal case. You describe the feature in text and the model reasons about it. No screenshots, code, or credentials need to leave your machine.

How do I stop the suggestions being generic? Give it specifics: the actual field names, the roles in your permission model, the real error codes. Generic input produces generic output. A prompt that names invite_status and workspace_role gets far better results than one that says "the invite feature".

Will this replace my test charter templates? No. Keep your templates. Use the model to fill them in faster and to challenge the charter once it is written.

How do I show the value of this to my manager? Track where your bugs came from for a month. Tag each one as "planned case", "exploratory", or "exploratory, idea from prompt". The third bucket is usually small in count and high in severity, which is exactly the argument you need.