Building a Whole Test Plan With AI: From Requirements to Traceability

Do not ask AI for a test plan. Ask for seven artifacts in sequence: risk register, scope, test conditions, test cases, test data, environments with entry and exit criteria, then the traceability matrix. Each grounds the next, identifiers thread through all of them, and the matrix at the end proves coverage instead of asserting it.

Ask a model to “write a test plan for the refund feature” and you get four pages of headings from a template, a list of test types, and eleven test cases that all check the happy path in slightly different words. It looks like a test plan. It has no coverage argument, no risk basis, and no way to tell what is missing.

This is part nine of The AI Analyst, and it is the largest artifact in the series. Everything before it was preparation: the context pack supplies the grounding, the codebase supplies the rules the specification forgot, and the Jira connection supplies the requirement identifiers. Now you point all of it at the thing that decides whether a release is safe.

Why does a single prompt produce a bad test plan?

Because a test plan is not a document, it is a chain of derivations, and each link has to be reviewed before the next one is built on it.

Risks come from requirements and architecture. Scope comes from risks and constraints. Conditions come from scope and rules. Cases come from conditions. Data comes from cases and the schema. The matrix comes from identifiers threaded through all of it.

Ask for the end of that chain in one shot and the model skips the derivation and pattern-matches a template. Ask for it in seven steps and you get something you can defend, because at every step you can see what was derived from what and correct it before the error propagates.

Budget roughly a day for a feature of moderate size. That is against perhaps a week by hand, and the day is mostly review, which is the part that was always the job.

Step 1: the risk register

Start here, not with scope. Scope without risk is just a list of what exists.

Attached: the functional specification for partial refunds, the
OpenAPI contract, the event schema, and the system context diagram.

Produce a risk register for testing this feature.

For each risk:
- id (RISK-nn)
- what could go wrong, stated as a failure, not a feature
- the mechanism: which component, which rule, which integration
- business impact if it happens in production
- likelihood, with your reasoning from the attached material
- which requirement ids it relates to

Include specifically:
- data integrity risks (wrong amount, wrong account, double action)
- integration risks (each system boundary in the context diagram)
- state risks (transitions the state machine allows that the
  business should not)
- timing risks (cut-offs, batch windows, race conditions)
- reversal and exception risks

Do not include generic risks such as "poor performance" unless the
attached material gives a specific mechanism.

That last constraint removes the template padding. The categories force the model to walk the architecture rather than recite a risk taxonomy, and the “stated as a failure” instruction is what turns “refund processing” into “a refund is issued twice because the retry does not check idempotency,” which is a testable risk. Idempotency testing is the reference for that specific one, and it is the risk that shows up on every payments programme.

Then you rank them. That part is yours. The model can tell you a double refund is possible; only you know that your regulator has asked about duplicate customer credits twice this year, which moves it to the top of the plan.

Step 2: scope

Given the ranked risk register and these constraints:
- 3 sprints
- 2 testers
- one shared integration environment, available 3 days a week
- the settlement simulator is not available until sprint 3

Produce: IN SCOPE, OUT OF SCOPE, and DEFERRED WITH REASON.

Every in-scope item must cite the RISK id that justifies it.
Every out-of-scope item must state the risk being accepted and
who needs to accept it.

The second rule is the one that protects you. Out of scope with an explicit accepted risk and a named acceptor is a professional decision. Out of scope with no reason is a gap that becomes your fault in the post-incident review. Getting a model to write the accepted-risk sentence for each exclusion costs nothing and produces the document you will want to be holding later.

Step 3: test conditions

This is the step everyone skips and it is where coverage is actually decided.

For each in-scope requirement, derive TEST CONDITIONS: statements
of what must be proven.

Format: COND-nn | requirement id | condition | why it matters

Derive conditions from all six sources:
1. the requirement statement itself
2. the API contract (every field, every constraint, every error)
3. the state machine (every transition, and every transition that
   must be refused)
4. the business rules register (each BR by number)
5. the data model (nullability, length, type, enumerated values)
6. the risk register (each RISK must be covered by a condition)

A condition is what must be true, not how to test it.

Then list any requirement with no condition, and any RISK with no
condition.

The six sources are the method from how to write API test cases, and they are what produce coverage rather than imagination. The two gap lists at the end are the output you actually read first: a requirement with no condition is either untestable as written or was misread, and both are findings you want before build finishes.

Expect two to four conditions per requirement, and expect the model to find conditions you would not have, particularly around refused transitions. Expect also to delete some, because a model does not know that the currency field is enumerated in the contract but constrained to two values by the payment scheme.

Step 4: test cases

Now the enumeration, which is the part AI is genuinely, boringly excellent at.

For each test condition, write test cases.

Format: TC-nnn | COND id | requirement id | preconditions | test data
| steps | expected result | type (positive/negative/boundary) | priority

Rules:
- The expected result must be observable: a status value, a response
  code, a field value, an event on a named topic, a log entry, or a
  database state. Never "the refund is processed correctly".
- Use only field names and enumerated values from the attached
  contract and data dictionary.
- Boundary cases: at the limit, one either side.
- Negative cases: exactly one rule violated per case.
- Match the format of the two examples attached.
- Anything you cannot ground, list under UNGROUNDED and do not write
  a case for it.

Two rules do the heavy lifting. “Observable” is what makes a case executable by someone who is not you, and it is the single most common defect in hand-written test suites. “One rule violated per case” is what makes a failure diagnosable: a payload that breaks three rules tells you nothing about which validation fired. Negative test design is the full treatment, and it is worth reading before you review a hundred generated negative cases, because reviewing them well requires knowing what good looks like.

Volume is the point here. A single endpoint honestly yields around forty cases. Doing that by hand takes half a day and you stop at twenty-five because you are tired. The model does not get tired at case thirty, which is where the interesting failures live.

The deeper reference on deriving, structuring, and automating all of this, with worked banking examples, is API Testing and QA Mastery for BAs.

Step 5: test data

Generate from the schema. Never from production. This is a rule, not a preference, and the guardrails explain why masking an extract is the harder and worse option.

Attached: the database schema, the message schema, the business
rules register.

Produce a test data set:

A. VALID records covering each realistic combination of the
   dimensions that matter (currency, channel, amount band,
   customer type).
B. BOUNDARY records: for every numeric, length, and date constraint,
   one at the limit, one just inside, one just outside.
C. INVALID records: one per rule, each violating exactly that rule,
   with the expected rejection code named.
D. AWKWARD records: valid but troublesome. Maximum-length names with
   non-ASCII characters, amounts with trailing zeros, timezone
   boundaries, leap day, a value that is valid in the schema but
   refused by a business rule.

Output as CSV plus a JSON payload example for each category.
All values synthetic. No real names, accounts, or references.

Category D is where the production defects come from. Nobody writes those by hand because nobody thinks of them at four in the afternoon, and every one of them has caused an incident somewhere. A model given “valid but troublesome” as a category produces them readily, because it has seen a great many bug reports.

For ISO 20022 work, this step is transformative. Generating a set of structurally valid pacs.008 messages that each violate exactly one usage guideline rule used to be days of XML work. See pacs.008 test cases and the ISO 20022 XML traps for what those rules actually are, because you must know them to review the output.

Step 6: environments, entry and exit criteria

Given the test cases and these environment constraints: [describe]

Produce:
1. Which cases can run in which environment, and which need the
   settlement simulator.
2. Dependencies and stubs required, per case group.
3. Entry criteria: what must be true before execution starts.
4. Exit criteria: measurable, including coverage of high risks,
   defect thresholds by severity, and what constitutes a blocker.
5. A suggested execution order that surfaces the highest-risk
   failures first.

Flag any test case that cannot be executed in any available
environment.

The flag at the end is the useful part. Every plan contains a handful of cases that quietly cannot run anywhere, and finding them in planning rather than in week three of execution is worth the whole exercise. Exit criteria being measurable is what makes your go/no-go call an argument rather than an opinion.

Step 7: the traceability matrix

This is the deliverable that makes everything above defensible, and because identifiers have threaded through every step, generating it is mechanical.

From the requirements, conditions, and cases produced above,
generate a traceability matrix.

Columns: requirement id | requirement summary | RISK ids | COND ids
| TC ids | count of cases | highest priority case

Then produce three gap lists:
1. Requirements with no test condition.
2. Test conditions with no test case.
3. Test cases tracing to no requirement.

Those three lists are the entire value. List one is a coverage gap. List two is a condition somebody gave up on. List three is either scope creep or an undocumented requirement that exists in the code but not in the specification, which is the most interesting finding of the three and is exactly what part four tends to surface.

The requirements traceability matrix covers what the artifact is for and how to keep it alive once execution starts. Keeping it alive is where these normally die: the matrix is accurate on day one and fiction by week three. Regenerating it from Jira links is one of the good automations in part six.

Then it goes into the tools

The plan is not finished until it is executable and linked.

• Test cases into Jira, as issues of your test type (Xray, Zephyr, or plain issues), linked to their requirement, created through the draft-approve-write pattern and labelled ai-drafted.
• API cases into a collection, which is part ten: the same cases become Bruno or Postman requests with assertions, runnable in CI.
• Event cases into a validation harness, per how to test Kafka.
• The matrix into Confluence, as a generated section regenerated from Jira links rather than maintained by hand.

At that point the chain is complete: a requirement in Jira, a condition, a case, an automated assertion, and a result, all connected by identifiers. That chain is the thing auditors ask for and almost nobody has.

What AI cannot do here

Be precise about this, because the gap is where your value sits.

It cannot rank risk. It does not know which failure reaches a regulator, which customer segment complains loudly, or that the operations team has a manual workaround that makes one failure survivable and another catastrophic.

It cannot know the undocumented system. The integration that has been held together by a 2019 workaround, the batch that silently skips null currencies, the downstream system that ignores the status field entirely. That knowledge is in the code, in the incidents, and in your vault.

It cannot decide what is worth testing. Given three days of a scarce environment, which twelve cases run? That is a trade of risk against cost and it is the judgment you are paid for.

It cannot own the release. Somebody signs. Somebody is accountable. That has never been a tool.

What it does is remove the enumeration, which was consuming the time meant for judgment. The QA analysts who get stronger here are the ones who spend the reclaimed hours on risk and on the tests nobody predicted, which is what what a QA analyst is was always supposed to mean.

The takeaway

Build a test plan with AI in seven grounded steps: risk register, scope with accepted risks named, test conditions from six sources, test cases with observable results and one violation each, synthetic test data including the awkward category, environments with measurable exit criteria, and a traceability matrix with three gap lists.

Thread identifiers through every step, review each artifact before building the next on it, and rank the risks yourself. A day of that produces a plan with a coverage argument, which is a different object from four pages of headings that happen to contain the word “regression.”

Next: part ten, where the cases become a runnable Bruno or Postman collection with assertions and a CI gate. The full path is on The AI Analyst.

Ahmed is a Senior Technical Business Analyst with 10+ years in banking and payments. He builds practical guides and tools for analysts at The Tech BA Toolkit.

Tags: QA, Artificial Intelligence, Test Planning, Traceability, Payments