Yesterday built the machine that writes test plans; today is the judgment inside it, because a plan generator with no risk sense just produces long documents faster.
A test plan is a shared artifact the team tests against, not a chat reply. That one sentence shapes everything about how I generate plans with AI, so hold it while we walk the steps.
Gather context. Do not guess.
The first version of my skill wrote decent cases against whatever the ticket happened to say, so a thin ticket produced a thin plan. The fix: read the spec or ticket in full, and when the ticket is a one-line stub, traverse up. Read the parent epic, the linked design docs, the PRD. If context is still missing, ask before writing. An AI will happily invent cases for a feature it does not understand, and they will look plausible. Plausible is the trap.
Assess risk before you count cases
This is the step that separates a plan from a list. Before writing anything, weigh each functional area across five dimensions:
- Revenue. Does a failure lose money or block a paid flow?
- Security. Auth, access control, data exposure.
- Customer-facing. Does a failure hit end users or the support team directly?
- Data integrity. Could it save or show wrong values, duplicates, or miscalculations?
- Operational. Does it hit on-call load, background jobs, or escalations?
Mark each area high, medium, or low, then let that drive everything. Every high-risk area gets P0 coverage and the most depth. Do not spread cases evenly. A 40-case plan split evenly across ten areas when only four carry real risk is a bad plan.
Data integrity is the dimension AI-generated plans skip most, so make it concrete on the store. Tumble Kitchen now runs on a real REST API at https://juliapottinger.com/api/tk/, which turns a vague worry into a written case: verify that the price on a dish page equals the price the API returns for the same dish, and verify that a delivery total includes the delivery fee. Give an agent the repo and that API and it can draft those cases against the real endpoints, but you are the one who marks the area high and decides it earns P0 coverage.
Three sizes, and the rule that keeps them honest
- Mini, about 10 to 15 cases. P0 only, core areas only. It drops straight into a ticket.
- Medium, about 40 to 60 cases. Balanced coverage of every relevant area.
- Full, 80 cases and up. The comprehensive plan for a big feature, headed to a wiki page.
The rule I had to teach the model: medium and full cover every area and cut depth within each area, never whole areas. Mini is the only size that drops sections by design. Without that rule it kept shrinking plans by deleting the boring-looking sections, which were sometimes the risky ones.
Cases are Verify-that rows
Every case is one row, and it names the condition and the expected result in the same sentence:
| ID | Verify that... | Priority |
| AUTH-01 | Verify that a standard user signs in with | P0 |
| | valid credentials and lands on /dashboard | |
| FLAG-01 | Verify that with the flag off, the new | P0 |
| | panel is not rendered and the old view | |
| | loads | |
| PERM-03 | Verify that a read-only user does not see | P1 |
| | the Delete control on any row | |
“Test email validation” tells you nothing. A Verify-that row tells you what to do and what proves it passed, in one line. And when the spec leaves a label, a field, or an error message undefined, the plan does not guess. It gets an Open Questions section at the end, each question tied to the cases it affects.
Publish it. Never leave it in the chat.
A medium or full plan goes to a Confluence page. A small plan goes into the ticket description, appended under a clear heading, never overwriting what is already there. Never a wall of markdown in the chat window, and never an .md file handed back to one person. If a PM, a developer, and another tester cannot open the plan, read it, and check their work against it, you do not have a plan yet. You have a draft stranded in a transcript. Generate first, then publish. The publish step is part of the job, not an afterthought.
AI produces the breadth fast: the sections, the obvious cases, the structure. It does not decide which risks matter. You bring the risk lens; the AI saves you the typing.
Try this today
Take one feature you know well and run the risk pass on it by hand: five dimensions, high, medium, or low per area, two minutes. Then look at where your existing tests actually sit. Nearly everyone finds at least one high-risk area sitting nearly bare while a low-risk area is covered in depth. The full plan prompt and worked example plans of all three sizes are at the AI test plan generator.
Tomorrow: the inputs. Test data and the edge cases a checklist misses, with the one line that makes the prompt worth running.