A plan from yesterday tells you what to test; today the model helps you find the inputs that break it.
If I could only use AI for one QA task, this would be it. A model that has read the internet knows more about weird names, weird addresses, and weird payment amounts than any single tester ever will. But the prompt shape decides whether you get a useful set or a pile of trivia, and the shape has two load-bearing parts: scope it to one feature, and ask for the expected result with every input. A per-project edge-case list comes back as mush. A per-feature one comes back sharp.
The prompt, on a real rule
My practice store, Tumble Kitchen, makes a promise: the code IRIE20 gives 20% off orders of 10,000 JMD or more. Here is the prompt I would hand a model, and the shape carries to any rule you test:
Here is the discount rule I am testing: the code IRIE20
gives 20% off orders of 10,000 JMD or more.
Give me cart totals that stress the boundary: just below,
exactly at, and just above 10,000. For each total, state
the expected discount and the expected final amount, and
say why that value is worth testing. Then list the rule
interactions I should check if a second promotion or a
threshold-based delivery fee is ever added, including the
case where one discount pushes the total below another
rule's threshold.
Copy it, with your own rule in place of mine. The model comes back with 9,999, 10,000, and 10,001, each with an expected discount, plus interaction cases like a discount pushing a cart below a second threshold. That interaction class is exactly the kind of case humans forget and models are good at enumerating, once you hand them the real rules instead of a vague description.
Why the expected result is the whole point
Asking for input and expected output turns a list of data into a test oracle, which is the plain name for anything that tells you what the right answer is. Now you can argue with it. When the model’s expected answer disagrees with yours, chase it: one of you is wrong, and either way you learn something, a bug, a gap in the requirements, or a gap in your own model of the feature. A list of inputs with no expected results is homework you assigned yourself.
And here is the payoff on the store. Run the three boundary values against the real cart: the Full Jerk Combo at 8,200 plus the Baked Cheese Patty at 1,800 lands you at exactly 10,000. Apply IRIE20 and hold what the promise says should happen against what does happen. The middle value is the reason boundary testing exists.
Check the model’s set against a generator
Models are creative but not exhaustive, and the classic boundary technique is deterministic. After the model hands you its set, run the same rule through the boundary value generator and compare. The generator will not miss a boundary. The model will sometimes offer an interaction case the generator cannot know about. Together they are better than either alone.
Two hard rules
- Never paste real customer data into a prompt. Not a name, not an email, not an order. Generate fictional data instead; the model is excellent at that. If your team has not written this rule down, write it down this week.
- Verify regulatory and legal edge cases with primary sources. Ask a model for compliance cases and it will happily invent citations. Use it for creativity. Confirm against the actual regulation before anything rides on it.
The prompt that pays off asks for both the input and the expected result. That is what turns a list into a test.
Try this today
Pick one rule in the product you test: a discount, a limit, a validation. Run the prompt above with the real rule. Then execute the three boundary values, by hand or in your suite. Boundary bugs are among the most common bugs that reach production, and this loop finds them in minutes.
Tomorrow: the other side of the desk. The agent starts writing tests, and your review decides what they are worth.