From PRD to QA Test Scenarios with AI

Why QA ends up reverse-engineering the PRD instead of testing it

A PRD is written for engineers first — requirements, scope, acceptance criteria. By the time it reaches QA, often as a linked ticket rather than the full document, most of the nuance has been compressed into a one-line summary: "test the new export feature." What's lost in that compression is exactly what makes testing valuable: the specific non-goals, the edge cases the PM already thought about, the boundary conditions buried in a sentence nobody bolded.

So the tester does what any reasonable person does with incomplete information — they test what's obviously true (the happy path) and guess at the rest. The happy path gets tested three times over by three different people at three different stages, and the edge case that actually breaks in production was never written down as a scenario at all, because nobody reread the full PRD closely enough to catch it.

A test suite that only covers what's obvious isn't testing the PRD — it's testing the summary of the PRD, which is a different, thinner document.

None of this is a QA failure. It's a handoff failure — the full document with all its nuance existed, it just never reached the person doing the testing in a form they had time to fully absorb. Every PM has watched a bug get reported that was, technically, described in the PRD the whole time, three paragraphs past where anyone reading a linked ticket would naturally stop.

Step 0 — What a good test scenario table actually needs

Five things per scenario, no more: an ID, the specific requirement or acceptance criterion it verifies, preconditions, the steps, and the expected result. The requirement citation is the part most hand-written scenario lists skip, and it's the one that matters most — a scenario with no traceable requirement behind it is either testing an assumption nobody wrote down, or a sign the PRD itself has a gap.

Step 1 — Ground the agent in the full PRD, not the ticket summary

Feed the agent the complete PRD — requirements, non-goals, edge cases, and all — not a one-line description of the feature. The compression that happens between "PRD" and "Jira ticket" is exactly what causes scenarios to miss things; skip it here. If you have them, also include:

• Any known constraints or prior incidents in this area of the product
• The epic's stated risk, if one exists — a feasibility-risk epic deserves heavier edge-case coverage than a low-risk one

This is the same grounding discipline behind every other artifact in an agentic PM workflow: the output is only as complete as what it was given to read.

Step 2 — Ask for scenarios traced to requirements, not "test the feature"

Here's a starting prompt. The instruction that matters most is the traceability requirement, plus an explicit instruction to cover non-goals and edge cases as their own category, not an afterthought:

Read the full PRD below first, including non-goals and edge cases,
not just the primary requirements.

Generate a test scenario table. For each scenario:
1. ID and short name.
2. The specific requirement, acceptance criterion, or non-goal it
   verifies — cite it directly. If a scenario doesn't trace to
   something explicitly stated in the PRD, don't include it; flag
   it as a gap in the PRD instead.
3. Preconditions, steps, and expected result.
4. Priority: high if this covers the primary flow or a stated risk,
   low if it's a minor edge case.

Cover three categories explicitly, not just the primary flow:
- Happy path scenarios for the core requirements.
- Boundary and error conditions mentioned or implied in the PRD.
- Scenarios verifying each stated non-goal actually stays out of
  scope — if the PRD says X is not supported, write a scenario
  confirming X genuinely doesn't work or doesn't break something
  else.

PRD: [paste it, non-goals and edge cases included]

The non-goals category is the one worth pausing on — it's the most commonly skipped, because "test that something doesn't happen" feels less urgent than "test that something does." But an unenforced non-goal is exactly how scope creeps back in silently: the PRD said "no bulk delete in v1," nobody wrote a scenario confirming that, and six months later someone discovers a workaround path that does it anyway.

What good output looks like: not "Scenario 7: test export," but something with a real citation — "Scenario 7: Export with >50k rows. Verifies non-goal stated in PRD section 3: 'exports above 50,000 rows are not supported in v1 and should show a clear error, not a silent truncation.' Precondition: a report with 60,000 rows exists. Steps: trigger export, observe result. Expected: user sees the stated error message, not a partial file with no warning. Priority: high — a silent truncation would corrupt downstream reports without anyone noticing." That's a scenario a tester can run without asking anyone what it means, and a failure that points straight back at the requirement it violated.

Step 3 — Don't let the agent stop at the obvious happy path

Left to a generic instruction, most models default to the scenarios that are easiest to imagine — which are almost always the primary flow. Push explicitly: "what's the least obvious way a user could hit this feature, and does the PRD say what should happen?" If the PRD doesn't say, that's useful information too — flag it as an open question for the PM to resolve, rather than letting the agent guess at expected behavior that was never actually specified.

This is also a good moment to ask for scenarios that combine two conditions the PRD only addressed separately — what happens when the boundary case and the error state happen at the same time, or when two features interact in a way neither spec anticipated. Those combination scenarios are exactly the ones a solo human reviewer tends to run out of time for, and exactly the ones that produce the strangest bug reports months later.

Step 4 — From scenarios to actual QA execution

The scenario table is the starting point for execution, not the finish line — a human or automated suite still needs to run each one and record what actually happened. Keeping the table traced to requirements makes that handoff cleaner: when a scenario fails, it points directly at which specific requirement broke, instead of a vague bug report someone has to triangulate back to the spec. If the feature also has event tracking specced, QA can verify both in the same pass — does the feature behave correctly, and does it actually emit the event it's supposed to.

Keep the table itself somewhere the whole team can see the traceability, not buried in a personal doc — a shared table where every row visibly cites its requirement also makes PRD gaps obvious to everyone, not just whoever generated the scenarios. That visibility is often what finally gets an ambiguous requirement clarified before launch instead of after.

Common mistakes to avoid

• Testing from the ticket summary, not the full PRD. The compression between the two is exactly where edge cases get lost.
• Skipping non-goal verification. An untested non-goal is scope creep waiting to happen, discovered by a user instead of a tester.
• Letting scenarios float free of requirements. A scenario with no traceable requirement is testing someone's assumption, not the spec.
• Over-indexing on the happy path. It's the easiest to imagine and the least likely to be where the real bug lives.
• Guessing at unspecified behavior. If the PRD doesn't say what should happen in an edge case, that's a question for the PM, not something to invent silently.

FAQ