AI for exploratory testing and test ideas

Exploratory testing is investigation: you design, run and learn at the same time. A model cannot do that, because it cannot see your screen, use your product or notice that something felt wrong.

What it can do is widen the search space before you start. Given a feature, it will produce edge cases, unusual sequences, hostile inputs and personas you had not considered.

So the split is clean. The model is a second brain for what to try. You remain the one who tries it, notices the odd behaviour and decides what it means.

Treat it as a colleague who has read every testing book and never seen your product.

The terms you will hear

• Charter. The one-sentence mission for a session. Yours to write.
• Test idea. A candidate thing to try. Cheap, unvalidated, and what a model is good at producing.
• Persona. A user type with different behaviour, such as a screen reader user or an impatient one on 3G.
• Heuristic. A rule of thumb for where bugs hide: boundaries, interruptions, repeats, reversals.
• Hit rate. The share of generated ideas that were worth trying. Two or three in twenty is a good result.

What to ask it for

1. Sequences, not inputs. "What orders of operations might break a basket with a discount and a gift card?" Order-of-operations bugs are where models earn their place, because humans test the forward path.
2. Interruptions. Back button, refresh mid-flow, two tabs, session expiry, closing the laptop. Ask explicitly, because these are systematically under-tested.
3. Hostile but plausible inputs. Not injection strings. A name with an apostrophe, a 400-character address, an amount with three decimals, an emoji in a code field.
4. Personas with different constraints. Keyboard only, screen reader, slow connection, an account with 400 orders, a customer in a different timezone.
5. The oracle question. "For each of these, how would I know whether the behaviour is correct?" This turns an idea list into something testable, per test oracles.
6. What it would not test. A useful prompt in reverse, and it surfaces its own blind spots.

Why it matters

Because the limit on exploratory testing is imagination under time pressure, and that is precisely what a generated list relieves.

For example, a tester with ninety minutes on a gift-card feature will reliably think of partial redemption, an invalid code and a spent card. They will less reliably think of applying the card, removing an item, then reapplying, or spending the same card from two tabs at once. Those two are where the real defects were.

A model produces both in seconds, along with eighteen ideas you will discard. The discarding is fast, and the two survivors change the session.

A worked session

For example, here is one real list, filtered, and what came of it.

Three out of twenty looks poor until you notice that idea two was the critical money defect, and no written case covered it. Ten minutes of filtering bought that.

How to show you know it

• A filtered list with reasons. Showing what you discarded and why is the skill, not the generating.
• A hit rate. "Three of twenty, one critical." Honest, and it stops the conversation drifting into hype.
• A defect from a generated idea. Name it and say where the idea came from.
• A charter you still wrote yourself. It demonstrates you know the tool widens the search and does not run the session.