Spec-Driven Development for Testers: A Practical Guide

Last updated 30 October 2026.

Spec-driven development (SDD) is one of the most talked-about ideas in AI-assisted software development. Instead of asking a coding agent to “build a login page” and hoping for the best, you write a structured specification first, then let the agent turn it into a plan, tasks and code. The spec becomes the shared source of truth.

For testers, this is a big opportunity. A good specification is, in large part, a test plan waiting to happen. If testers help shape specs, they can influence quality before a line of code exists, and they can turn requirements into tests far more directly than before.

This guide explains what SDD is, how two popular tools implement it, how testers can turn specs into tests, and where the approach falls short.

What is spec-driven development?

There’s no single agreed definition yet. Thoughtworks put spec-driven development in the “Assess” ring of its Technology Radar in November 2025, describing it as “an emerging approach to AI-assisted coding workflows” which “generally refers to workflows that begin with a structured functional specification, then proceed through multiple steps to break it down into smaller pieces, solutions and tasks.”

In its April 2026 Radar (Volume 34), Thoughtworks went further, noting that terms such as spec-driven development “are sometimes used inconsistently or overlap in meaning”, an example of what it called semantic diffusion.

In practice, most SDD workflows share four stages:

1. Specify what to build and why, often as user stories with acceptance criteria.
2. Design how it will work, including architecture and data flow.
3. Break down the design into small, ordered tasks.
4. Implement the tasks with a coding agent, checking results against the spec.

That sounds a lot like classic requirements engineering, and it is. The difference is that the spec is written to be consumed by an AI agent, and it lives alongside the code in the repository.

How GitHub Spec Kit works

GitHub Spec Kit is an open-source, MIT-licensed toolkit that, in its own words, “gives AI coding agents structured processes, reusable templates, and documented outcomes.” It works with several coding agents, including GitHub Copilot. On 30 October 2026, the repository had more than 140,000 GitHub stars, and the latest release was v1.2.5, published on 28 October 2026.

You install the specify CLI, initialise a project, then run a series of commands in your agent’s chat. The README’s minimal SDD flow is:

/speckit-constitution Create principles focused on code quality, testing, and maintainability.
/speckit-specify Build a photo organizer with albums grouped by date and a tile preview of each album.
/speckit-plan Use Vite with vanilla JavaScript. Keep images local and store metadata in SQLite.
/speckit-tasks
/speckit-implement
/speckit-converge

A few ideas matter for testers:

• The constitution. A project-wide set of principles that the agent must follow. Thoughtworks described it as defining “immutable principles that must always be followed”. This is a natural place to put testing standards, such as “every user-facing change has an automated acceptance test”.
• Review between steps. Spec Kit’s README says to run the steps one at a time, “reviewing each result before continuing.” Each review is a checkpoint where a tester can ask “how will we know this works?”
• Convergence. You repeat implement and converge until convergence reports “Converged”. This is the point where the code is checked against the plan.
• Extensions and presets. Spec Kit supports extensions that add commands or quality gates, and presets that enforce organisational or regulatory standards.

Spec Kit also ships bug fixing and idea assessment processes as bundled extensions, so it’s no longer only about new features.

How Kiro specs work

Kiro is Amazon’s agentic development environment. According to its documentation, every spec generates three files:

• requirements.md (or bugfix.md for bugs) with user stories and acceptance criteria,
• design.md with architecture, sequence diagrams and implementation considerations, including error handling and testing strategy, and
• tasks.md with discrete, trackable implementation tasks.

Kiro offers two feature-spec workflows, Requirements-First and Design-First, plus a Quick Spec option that generates all three files without approval gates.

EARS notation

Kiro’s requirements.md uses EARS (Easy Approach to Requirements Syntax). Each requirement follows a pattern:

WHEN [condition/event] THE SYSTEM SHALL [expected behavior]

Kiro’s example is: “WHEN a user submits a form with invalid data THE SYSTEM SHALL display validation errors next to the relevant fields.”

Kiro lists testability as one of EARS’s benefits: “Each requirement can be directly translated into test cases.” For testers, that’s the key point. A well-written EARS requirement is close to a test already.

Analyse Requirements

Kiro can analyse requirements before design to find “logical inconsistencies, ambiguities, conflicting constraints, and gaps.” That’s a classic tester task, now partly assisted by AI. It doesn’t replace a tester’s review, but it can catch obvious problems early.

Correctness and property-based testing

Kiro’s Correctness feature links specs to property-based testing. Its documentation describes translating natural-language specifications into executable properties and generating many test inputs to try to break them. Kiro’s example compares a traditional test, “User adds Car #5 to favorites, Car #5 appears in their list”, with a property: “For any user and any car, WHEN the user adds the car to favorites, THE System SHALL display it in their list.”

The docs list Correctness as an IDE capability. Check the current documentation for availability in other Kiro surfaces.

Spec Kit vs Kiro: what testers should know

Both tools follow a similar flow, but the details that matter for testing differ. This table is based on each tool’s public documentation as of 30 October 2026.

Aspect	GitHub Spec Kit	Kiro
Type	Open-source toolkit and CLI used with your coding agent	Amazon’s agentic IDE, CLI and web product
Spec artefacts	Constitution, specification, plan and tasks	requirements.md or bugfix.md, design.md, tasks.md
Requirements format	Natural language, shaped by templates	EARS notation
Project-wide rules	Constitution, presets	Steering files
Review points	Run steps one at a time and review each result	Approval between phases, unless you use Quick Spec
Built-in test link	Convergence checks implementation against the plan	Correctness feature with property-based testing
Bug workflow	Bug fixing extension	Bugfix specs

Neither tool guarantees good tests. They give you better places to define and check them.

Using specs for bug fixes

SDD isn’t only for new features. Both tools now have bug workflows, and they line up well with how good testers already report bugs.

Kiro’s bugfix specs capture bug analysis with current, expected and unchanged behaviour. That last part is easy to forget. Stating what must not change gives you an explicit list of regression tests to run after the fix.

Spec Kit describes its bug fixing process as producing “an assessed cause, scoped fix, and recorded verification.” For testers, the recorded verification is the important part. It’s evidence that the fix was checked, not just written.

A simple rule works with either tool: every bug fix spec should include a failing test that reproduces the bug before the fix and passes after it. If the agent can’t write that test, the bug probably isn’t understood yet.

Why spec-driven development matters for testers

Testers can shape quality earlier

In many teams, testers see a feature only once it’s built. With SDD, the spec exists before the code. Reviewing it is the cheapest point to catch missing cases, unclear rules and untestable requirements.

Specs make test design more direct

If acceptance criteria are written as precise conditions and outcomes, mapping them to tests is mechanical. Testers can spend their time on what’s missing rather than translating vague prose.

Traceability comes for free

Because specs, tasks and tests live in the repository, you can trace each requirement to the tests that cover it. This helps with audits and regulated work, and with simple questions like “which tests cover the refund rule?”

AI agents need a definition of done

Coding agents are good at producing code that looks right. Without a precise spec and tests, “looks right” becomes the standard. SDD gives agents, and reviewers, a concrete target.

Turning a spec into tests: a worked example

Take a simple requirement written in EARS:

WHEN a signed-in user applies a valid discount code at checkout
THE SYSTEM SHALL reduce the order total by the code's percentage, rounded to 2 decimal places.

WHEN a user applies an expired discount code
THE SYSTEM SHALL keep the order total unchanged AND display "This code has expired".

A tester reviewing this would ask:

• What if the code is applied twice?
• Can codes be combined?
• What happens when the discount would take the total below zero?
• Is the percentage applied before or after tax and shipping?
• What about a guest user?
• How is rounding done: half-up, or banker’s rounding?

Each question either becomes a new requirement or a documented assumption. That’s the real value testers add to SDD: finding the cases the spec doesn’t mention.

Then the requirements map to tests. An example-based end-to-end check with Playwright:

test('expired discount code leaves total unchanged', async ({ page }) => {
  await page.goto('/checkout');
  const total = await page.getByTestId('order-total').textContent();
  await page.getByLabel('Discount code').fill('EXPIRED10');
  await page.getByRole('button', { name: 'Apply' }).click();
  await expect(page.getByText('This code has expired')).toBeVisible();
  await expect(page.getByTestId('order-total')).toHaveText(total!);
});

And a property-based unit test for the calculation, using fast-check in TypeScript:

import fc from 'fast-check';
import { applyDiscount } from './pricing';

test('discount never increases the total or makes it negative', () => {
  fc.assert(
    fc.property(
      fc.integer({ min: 0, max: 1_000_000 }), // total in cents
      fc.integer({ min: 0, max: 100 }),       // percentage
      (totalCents, pct) => {
        const result = applyDiscount(totalCents, pct);
        return result <= totalCents && result >= 0;
      },
    ),
  );
});

Here applyDiscount stands for your own pricing function. The property test checks a rule across thousands of inputs, which catches rounding and boundary bugs that a handful of examples would miss.

A tester’s checklist for reviewing specs

Use this when reviewing a spec, whatever tool produced it.

Check	Question to ask
Testable	Can each requirement be verified by a test with a clear pass or fail?
Complete	Are error cases, empty states and boundaries covered?
Unambiguous	Would two people write the same test from this requirement?
Consistent	Do any requirements conflict with each other or with existing behaviour?
Non-functional	Are performance, security, accessibility and privacy needs stated?
Observable	Can the outcome be seen in the UI, API or data, not just “internally”?
Scoped	Is it clear what is out of scope?
Regression-aware	Does it say what must not change? Kiro’s bugfix specs, for example, capture unchanged behaviour.

Where spec-driven development goes wrong

SDD isn’t a silver bullet. Thoughtworks’ Radar entry was candid about the problems:

• Workflows “remain elaborate and opinionated”.
• Tools “behave very differently depending on task size and type”.
• Some “generate lengthy spec files that are hard to review”.
• When they produce PRDs or user stories, “it’s sometimes unclear who their intended user is.”
• Thoughtworks also wondered whether the industry “may be relearning a bitter lesson — that handcrafting detailed rules for AI ultimately doesn’t scale.”

From a tester’s point of view, add these risks:

• Specs written by AI, reviewed by nobody. If the agent writes the spec, the plan and the tests, it can encode the same misunderstanding in all three. Tests then pass, but the feature is wrong.
• Spec drift. Code changes after implementation, and the spec is never updated. A stale spec is worse than none, because people trust it.
• Spec theatre. Long documents that look rigorous but contain vague requirements such as “the system should be fast”.
• Over-specification. Specs that dictate implementation details make refactoring hard and tests brittle.
• False confidence from green tests. Generated tests can be weak. Check them with mutation testing.

How SDD relates to BDD

Testers who know behaviour-driven development (BDD) will recognise a lot here. BDD’s Given/When/Then scenarios, often run with Cucumber, and EARS’s WHEN/SHALL statements both aim for precise, testable behaviour.

The differences are mainly in audience and flow. BDD scenarios are written collaboratively by people and executed directly as tests. SDD specs are written for AI agents and break down into design and tasks before code exists. You can combine them: use EARS or Given/When/Then in the spec, then turn each scenario into an executable test.

Getting started as a tester

1. Ask to review specs. If your team uses Spec Kit, Kiro or a home-grown approach, ask to be a required reviewer on specs, not just pull requests.
2. Add testing to the constitution or steering. Put rules like “every requirement maps to at least one automated test” in Spec Kit’s constitution or Kiro’s steering files.
3. Write acceptance criteria in a testable format. EARS or Given/When/Then both work.
4. Map requirements to tests. Keep a simple table, or tag tests with requirement IDs.
5. Add property-based tests for rules with large input spaces, such as pricing, permissions and validation. Hypothesis for Python and fast-check for TypeScript are common choices.
6. Keep specs alive. Make updating the spec part of the definition of done for changes.

Frequently asked questions

What is spec-driven development?

A way of building software, usually with AI coding agents, where you write a structured specification first, then break it down into a design, tasks and code. The spec acts as the source of truth for both the agent and the team.

Is spec-driven development the same as BDD?

No, but they’re related. Both aim for precise, testable behaviour. BDD scenarios are written by people and run directly as tests. SDD specs are written for AI agents and drive design and implementation tasks.

Which tools support spec-driven development?

GitHub Spec Kit and Amazon’s Kiro are two of the best known. Thoughtworks also mentioned Tessl Framework in its November 2025 Radar entry. Many teams also use their own templates with general-purpose coding agents.

What is EARS notation?

EARS stands for Easy Approach to Requirements Syntax. Requirements follow patterns such as “WHEN [condition] THE SYSTEM SHALL [behaviour]”. Kiro uses it in requirements.md because each requirement can be translated directly into tests.

Does spec-driven development replace testers?

No. It moves testing earlier. Testers are needed to review specs for missing cases, ambiguity and testability, and to check that the generated tests actually verify the requirements.

Further reading on CheckOps

• Mutation testing for AI-written tests
• AI coding agents writing tests: Claude Code and Copilot
• How to test AI agents in 2026
• Testing vs checking
• Tools: Playwright, Cucumber, pytest, Jest