What a PRD Test Plan Actually Covers

A PRD does not contain a test plan. It determines whether one can be written.

That distinction is worth being precise about, because the two get conflated constantly and the result is a worse version of both — a spec cluttered with test cases, and a test plan quietly inventing the requirements nobody wrote. The spec's obligation is testability. The plan's obligation is verification. Different documents, different owners, one handoff.

Here is where the line sits, and what has to be on your side of it.

Where the spec ends

The PRD states	The test plan states
What must be true for this to be correct	How that will be checked
Every state, including failure and empty	Which cases exercise each state
Thresholds and boundaries, with numbers	Environments, data setup, tooling
What the user sees in each condition	Coverage, priority, regression scope

The handoff test is blunt: can QA write a plan from your spec without a meeting? If the answer is no, the gap is in the PRD, not in QA's process. Every clarification meeting after handoff is a requirement that was decided verbally and never written down — which means it also never got reviewed.

The four things a PRD must supply

1 · Observable outcomes

Every requirement needs an outcome someone outside your head can see. "The user understands the change" is not observable. "The banner appears on first load after the update and does not appear again once dismissed" is.

The tell is whether verification requires reading the user's mind. If it does, either find the observable proxy or admit the requirement is a goal rather than a spec line.

2 · Named states

Testing means walking states. A requirement describing only the success path gives QA one state to check and silently delegates the rest.

Empty, loading, error, partial, permission-denied, expired. If the PRD names them, they get tested. If it does not, they get discovered — usually in staging, occasionally in production. This is downstream of specifying error states properly, and it is the most common reason a "tested" feature still breaks.

3 · Data conditions

Every test needs a starting state, and the spec is where that gets decided.

A workspace with zero members behaves differently from one with two hundred. A user mid-trial differs from one whose card expired last night. If your requirement is only true for a particular data shape, say which — otherwise QA tests against whatever the seed script happens to produce, and the interesting conditions go unexercised.

4 · Boundaries with numbers

"Large files are rejected" cannot be tested. Rejected at what size? What happens at exactly that size? What about one byte under?

This is where the boundary lens pays for itself twice — once by finding the edge, once by making it checkable.

The testability test

One question, applied to any line in your spec:

Could a competent stranger write a pass/fail case from this sentence alone?

Not "does this sound reasonable." Not "would the team understand it." Could someone with no context turn it into a case that unambiguously passes or fails.

Common failures and their repairs:

Untestable	Testable
The list loads quickly	p95 render under 400ms with 500 rows
Handle errors appropriately	On 5xx, retain form input, show retry, log with request ID
Support large teams	Up to 500 members without pagination degradation
The flow should feel intuitive	Task completion above 80% in unmoderated testing, 8 participants
Notify relevant users	Notify workspace owners and admins within 60s; members are not notified

Notice what the repairs have in common. None of them is longer by much. The fix is almost never more words — it is a number, a named actor, or a stated condition replacing an adjective.

The lines that hide

Two categories slip through review most often.

Non-functional requirements without thresholds. Performance, availability, capacity, security posture. They read like requirements and behave like opinions, because nobody attached a number. A non-functional requirement without a threshold cannot fail, which means it will not be tested and will not be built for.

Requirements about absence. "The admin panel is not visible to members" is a real requirement and an easy one to skip, because nothing appears on screen when it works. Negative requirements need stating explicitly or they get verified by nobody — and a permission leak is exactly the failure that produces a security incident rather than a bug report.

QA as a review signal

The most useful thing about handing a spec to QA is not the testing. It is the questions.

Every question QA asks before they can write a case is a requirement you did not finish. Not a process failure on their side — a gap in yours, surfaced by the first person obliged to read your document literally rather than sympathetically.

Worth tracking for a couple of releases. If QA consistently asks about error handling, your specs have a systemic error-state gap. If they ask about data setup, you are under-specifying starting conditions. The pattern in their questions is a free audit of your writing, and it is more honest than any self-review, because you cannot ask yourself the question you did not think of.

The best outcome is boring: QA reads the spec, writes the plan, asks nothing. That is what a testable PRD looks like from the outside.

FAQ

Does a PRD contain a test plan? No. The PRD states what must be true; the plan states how it gets verified. The spec's obligation is testability.

What makes a requirement untestable? An unobservable outcome, an unnamed state, or a missing number. All three let two people disagree about whether it was met.

Who writes the plan? QA owns the plan; the PM owns the conditions it is written against.

How do NFRs get tested? Only with a number and a condition attached. "Fast" is an opinion. "p95 under 400ms at 200 concurrent users" is a test.