Spec-driven development: what it changes for QA

Every major AI coding tool shipped some version of the same idea this year. GitHub has Spec Kit, AWS has Kiro, and OpenSpec covers the open-source end. The pitch is the same in each: write a specification first, derive a plan from it, break the plan into tasks, and only then let the agent generate code.

Which, from a QA seat, is a slightly strange thing to watch become exciting. Writing down what the system should do before building it is not a new methodology. It's requirements engineering with a different logo.

The part that is new, and worth paying attention to, is why it came back. And it hands QA something the discipline has wanted for a long time.

What problem it's actually solving

Spec-driven development showed up as a response to drift. Not to bad code, to code that's plausible and confident and solves a slightly different problem than the one you had. An agent given a loose prompt fills the gaps with reasonable assumptions, and reasonable assumptions are the ones you don't notice are wrong.

Every gap in a prompt gets filled by something. The question is whether it gets filled by a decision someone made or by a plausible guess. SDD is the industry noticing that the second option scales badly once you're generating a lot of code, which is the same conclusion that shows up in the research on what AI-assisted code does to defect rates.

Why QA should care specifically

The oldest argument in test case authoring is with the requirement, not the code. You read the ticket, it says "users can reset their password," and you have to decide on your own whether an expired token shows an error or redirects, whether the old session survives, what happens on a second reset request, and whether the email can be requested five times a minute.

You write test cases for those, someone disputes one, and you find out three days later that the behavior was never decided by anyone. It was decided by whoever wrote the code, at the moment they wrote it.

A real spec forces those decisions up front. That's not a small change in how test design feels. It moves the argument from "is this a bug" to "does this match the spec," and the second question has an answer.

EARS, and why the format matters

Most SDD tooling leans on EARS, the Easy Approach to Requirements Syntax. It constrains requirements into a few sentence templates, the most common being:

WHEN <trigger>
THE <system> SHALL <response>

WHILE <state>
THE <system> SHALL <response>

IF <condition> THEN
THE <system> SHALL <response>

Constrained syntax feels bureaucratic for about a day, and then you notice what it does. A requirement in this shape has an explicit trigger, an explicit actor, and an explicit expected outcome. That maps onto a test case almost mechanically: precondition, action, assertion.

Which is the interesting bit for agents. An agent can read an EARS requirement and generate a test that checks it without inferring what you meant, because the requirement already said. Compare that to generating a test from "users can reset their password," where the agent has to invent the acceptance criteria and will sound just as confident doing it.

Where the trap is

If the spec becomes the single source of truth, then a test derived from the spec verifies conformance to the spec. It does not verify that the spec was right.

That distinction matters more when both the code and the tests come from the same document. A requirement that's wrong, or that quietly omits a case, produces code that implements the omission and tests that confirm it. Green board, missing behavior, nobody notices until a customer does.

This is why spec-driven development doesn't retire exploratory testing. Scripted verification tells you the system matches the specification. Somebody still has to poke at the running product and ask whether the specification described the right thing. If anything, a workflow where specs generate both implementation and tests raises the value of the one activity that isn't downstream of the spec.

How to plug into it without much drama

You don't need to roll out a methodology. Three practical moves cover most of the value:

1. Get into spec review. If the team is writing specs before code, the spec review is where QA has more influence than at any later point. The missing edge case costs a comment at that stage. It costs a sprint after the code exists.
2. Keep test cases traceable to requirement IDs. If requirements are structured and identified, your coverage can point at them. "Which requirements have no test" becomes a query instead of a workshop.
3. Generate the first draft, review it like a PR. Let an agent produce candidate cases from each requirement, then review and edit. First drafts from a structured requirement are decent. Shipping them unreviewed reproduces the acceptance-without-modification problem one layer up.

The honest assessment

Spec-driven development is old practice in new packaging, and that's fine. Practices come back when the conditions that made them useful come back, and generating large volumes of code from ambiguous instructions is a very good reason to be precise about instructions.

For QA the useful reframe is this: the specification is a test artifact as much as a development one. Teams that treat it that way get coverage that maps to something. Teams that treat the spec as a prompt and delete it after the code ships get the old situation back, with faster code generation on top.

qtrl keeps test cases as structured, managed records rather than files scattered through a repo, which is what makes requirement-level traceability possible when the requirements themselves are structured. You can see which behaviors are covered and which were never checked.

Agent-driven runs then execute those cases in real browsers, with each run logged against what it was meant to verify. The spec says what should happen, the coverage record says what was checked, and the gap between them is visible instead of assumed. See how it works.