AI-generated test plans
Writing a test plan from scratch is half an hour of structural overhead before any thinking happens — headings, scope statements, entry and exit criteria, risk sections. An LLM nails ninety percent of the structure in thirty seconds. The remaining ten percent — what is actually in scope for this release, what risks your team owns, and what your exit criteria look like given your actual test pyramid — is what the human review is for. That review step is not optional overhead; it is the act that converts a probabilistic draft into a deterministic artefact your team can be held to.
The drafting flow
Four stages from acceptance criteria to reviewed test plan — structure first, judgement second.
The AI-augmented test plan flow has four stages: structured input (acceptance criteria, ticket context, and one previous test plan as an anchor), a prompt template that divides the plan into its seven standard sections, a populated draft that covers structure and scope mechanically, and a human review that adds the judgement the model cannot supply.
The four-stage structure matters because it makes the human review step targeted. Without it, reviewers read the whole document looking for anything wrong. With it, reviewers know exactly where to focus: sections 5-7 (exit criteria, risks, approach) require domain knowledge the model does not have; sections 1-4 are structural work the model handles reliably.
The historical arc
From Word templates to AI-generated-with-review — each transition reduced structural overhead, not content judgement.
Test plan tooling has gone through five distinct phases in the past twenty-five years. Each transition reduced the mechanical overhead of producing a document without changing the fundamental requirement: a human with domain knowledge must own the content. The current AI-generated-with-review phase is the latest expression of that pattern, not a departure from it.
The 2026 phase is notable because the transition happened faster than the previous ones. LLM-assisted drafting went from experimental to default in under two years at teams that adopted it early. ISO/IEC/IEEE 29119, the current standard for software testing documentation (which superseded the withdrawn IEEE 829-2008 in 2014), provides the documentation structure that AI-generated plans are increasingly aligned against.
A section template that works
Seven sections — four that AI handles reliably and three that require human authorship with AI editorial support.
A test plan structured against ISO/IEC/IEEE 29119 has seven core sections: scope, in-scope features, out-of-scope, entry criteria, exit criteria, risks, and test approach. The first four are structural and largely derivable from acceptance criteria; the last three require team-specific knowledge the model cannot supply.
The most common prompt anti-pattern is asking the model to generate the entire plan without distinguishing which sections it can handle from which it cannot. Risk sections hallucinated by models sound plausible — "risk: test environment unavailability", "risk: third-party API instability" — but are generic rather than specific to your programme. Exit criteria generated without knowledge of your test pyramid are equally generic: "all tests pass" is not an exit criterion.
Best results come from providing the acceptance criteria, flagging which sections require human input, and anchoring the generation with one example from a previous test plan in the same domain. The prompt below shows the pattern. The ISTQB Foundation Level syllabus references 29119 for documentation structure — aligning your template to it signals intent to reviewers in regulated contexts.
# Test plan drafting prompt — ISO/IEC/IEEE 29119 aligned # Provide: ticket/AC, release name, and one section from a previous plan as anchor You are a senior QA lead writing a test plan. Use the inputs below to populate each section. Where inputs are incomplete, flag the gap — do not invent content. Inputs: Ticket AC: [paste acceptance criteria here] Release: [sprint name or release label] Anchor: [paste one section from a prior test plan as style reference] Sections to generate: 1. Scope — one paragraph, grounded in the AC only 2. In-scope — bullet list from AC; do not add unlisted features 3. Out-of-scope — explicitly list what is NOT being tested this release 4. Entry criteria — conditions that must be met before testing begins 5. Exit criteria — [FLAG: requires human input — do not generate] 6. Risks — [FLAG: requires human input — team-specific only] 7. Test approach — [FLAG: requires human input — aligned to your pyramid] Return each section under its numbered heading. Do not add sections not listed above.
On standards
IEEE 829-2008 was withdrawn in 2014 — ISO/IEC/IEEE 29119 is what current ISTQB syllabi and modern QA programmes follow.
IEEE 829-2008, the long-standing standard for test documentation, was officially withdrawn in 2014. Its replacement is the ISO/IEC/IEEE 29119 series, which covers testing concepts, processes, documentation, and techniques across all four parts. The ISTQB Foundation Level syllabus now references 29119 for documentation structure, and modern QA programmes should align to it.
In practice, teams in regulated industries and government contracts frequently inherit IEEE 829-style templates — these are still valid for compliance purposes in legacy contexts. If you are working from a 829-based template, it is worth noting the withdrawal date in the document header and flagging the migration to 29119 at the next documentation audit.
The practitioner takeaway is simple: name the standard you are aligning to in your test plan header. It is a five-second cue that tells reviewers which structural conventions to expect and saves discussion when the document goes to a compliance team.
Why the human review is the contract
The review converts a probabilistic draft into a deterministic artefact — it is not optional polish.
An AI-generated test plan carries the same epistemic status as any probabilistic output: it is the most likely document given the inputs, not a document that a human has committed to. Three things happen in the review that the model cannot do: scope drift is caught (the model may include features not in this release by pattern-matching to similar past releases), risk ownership is validated (the model generates plausible risks, not your team's actual risks), and the team commits to the exit criteria.
That last point matters most. Exit criteria are not a description of what "done" looks like in the abstract — they are a contract between the QA lead and the stakeholders about what the team will accept before sign-off. An AI can suggest them; only humans can sign off on them. A test plan with AI-generated exit criteria that no human has reviewed is a plan that nobody has actually agreed to.
An AI-drafted test plan with no human review attached is a hallucination dressed in section headings. The review is the contract — it converts a probabilistic draft into a deterministic artefact your team can be held to.
What AI handles badly in test plans
Organisation-specific risks, pyramid-aware exit criteria, and cross-team dependencies are the three sections to own.
Risks that are specific to your organisation — regulatory pressure on a particular product line, customer base sensitivity to certain failure modes, fragility in a specific part of your infrastructure — do not exist in the model's training data. The model generates risks that are commonly associated with software of your type, not risks that are specific to your programme.
Exit criteria require knowledge of your actual test pyramid. "All automated tests pass" is not useful if your suite has forty percent test debt and known flaky tests. "All P0 tests pass, P1 failure rate below 2%" is a real exit criterion — and the model cannot write it without knowing your pyramid.
// PRODUCTION