What an AI Literate Test Plan Actually Looks Like

Open ten teams' "AI testing checklists" and you will find ten different skill lists. Prompt engineering, evaluation metrics, red teaming, a paragraph on ethics. None of them show what actually changes on the page of a test plan, the document a tester writes before testing starts. Skills are what a person knows. A test plan is what gets handed to the team, and that artifact looks different for an AI feature in specific, checkable ways.

Most of a test plan does not need to change at all

Start with what stays the same, because it is most of the document. ISO/IEC/IEEE 29119 3, the international standard for test documentation, defines a test plan around scope, test items, features to be tested, approach, entry and exit criteria, resourcing, schedule, and risk. None of that framework becomes obsolete because the feature under test happens to call an LLM. You still need to know what you are testing, why, with what resources, and when you are done. A test plan for an AI feature is still a planning document driven by risk, not a new invention.

Where it changes is inside a handful of specific sections, and those changes are concrete enough to check for, not just talk about in the abstract.

Five additions that actually show up on the page

Model and version identification. A traditional test plan names the build or release under test. An AI literate one also names the model, the version, and the configuration, temperature, system prompt version, retrieval index version, because a model update can change behavior without any code in your own repository changing at all. Without this line, a bug report from three weeks ago cannot be reproduced.

Data provenance and governance. The ISTQB's CT-GenAI syllabus lists incorporating data governance, covering PII handling, intellectual property and copyright issues, user consent, and data provenance, as a named skill for testers working on generative AI features. That belongs in the plan itself, not just in someone's head: where does test data and retrieval content come from, what is licensed or synthetic, and what personal data needs to be scrubbed before it reaches a prompt log.

Evaluation criteria beyond pass or fail. A traditional test case has one expected result. An AI literate test plan defines evaluation criteria instead, semantic similarity thresholds, faithfulness or groundedness scores, and which categories of question get a human review rather than an automated verdict. The plan should state which metric gates a release and which one is monitored only, because treating every metric as a hard gate stalls a team that will start ignoring the gate instead.

Human review checkpoints. The plan should name the specific decision points that require sign off before an AI generated test, plan, or repair ships, not just say "human in the loop" as a general principle. Who approves a generated test plan before code exists. Who reviews a healer's patch before it merges. Vague oversight language is not a checkpoint a team can actually follow.

Reevaluation triggers. A traditional test plan assumes the system under test is mostly stable between test cycles. An AI feature is not: a model version bump, a change to the embedding model, or knowledge base content going stale can shift behavior with no code change to trigger a rerun. The plan should list what events force a reevaluation, not just when the next planned test cycle happens to fall.

Why this belongs in the plan and not just in a wiki page

Regulatory documentation requirements are heading the same direction as good testing practice here, for what it is worth. The EU AI Act's Article 11 requires technical documentation for high risk AI systems that includes testing procedures and a post market monitoring plan, kept up to date as the system changes, not written once and filed away. NIST's AI Risk Management Framework treats documentation the same way, as part of an ongoing governance process rather than a one time deliverable. Neither of these was written for test plans specifically, but the underlying expectation matches: a document that gets written once before launch and never touched again is not documentation, it is an artifact of the day it was written.

A test plan that lives in a shared drive and gets updated when the model version changes does the same job for a team internally that these frameworks describe for regulators. It just needs to actually get updated, which is the part most teams skip.

Frequently asked questions

Do I need a completely separate test plan template for AI features?

Not necessarily a separate template, but a separate section or appendix that covers the five additions above works for most teams. Bolting them onto the existing plan format keeps the document familiar while covering what is actually different.

How often should the model and version section get updated?

Every time the underlying model, prompt template, or retrieval index changes, not on a fixed calendar. A quarterly review misses a model provider's mid quarter update entirely.

Who owns writing the evaluation criteria section if the team has no data science background?

The tester still owns it, but usually in collaboration with whoever picked the model or built the prompt. The tester's job is to make sure the criteria are specific and checkable, not to design the underlying evaluation metric from scratch.

Does a small team really need all five additions, or is this overkill for a low stakes feature?

Scale the depth to the risk, the same principle that governs any test plan. A low stakes internal tool might need one line on model version and one on reevaluation triggers. A customer facing feature handling personal data needs all five written out in detail.

If you want a structured way to build these sections into your own test plans rather than improvising them project by project, the ISTQB CT-GenAI certification course covers the evaluation and governance content this post draws from, in enough depth to actually write the document yourself.