QA Process
Definition of Ready & Done.
A Definition of Ready stops half-baked stories entering a sprint; a Definition of Done stops half-tested ones leaving it. This guide covers both from a QA lens, with checklists you can adopt as quality gates.
When to use it
Use this when stories keep arriving untestable or leaving the sprint with testing unfinished — when "done" means different things to different people and quality is leaking through the gaps.
Who uses it
QA leads and managers who set the gates, QA engineers who apply them story by story, and the product and engineering partners who have to agree what "ready" and "done" mean.
On this page10 sections
WHAT THESE ARE
A Definition of Ready (DoR) is the agreed bar a story must clear before the team commits to it in a sprint. A Definition of Done (DoD) is the agreed bar a story must clear before it can be called complete. Both are shared, written checklists — not one person's opinion.
From a QA point of view they're the two gates that protect quality at the edges of a sprint: the DoR keeps untestable work out, and the DoD keeps under-tested work in until it's genuinely finished. Together they make "ready" and "done" mean the same thing to everyone.
WHY THEY MATTER
Without a DoR, stories enter the sprint with vague acceptance criteria, missing designs, or unprovisioned data — and QA discovers it mid-sprint, when there's no time to fix it. Without a DoD, "done" quietly shrinks to "the developer thinks it works", and testing gaps surface in production.
The gates turn quality from a late-stage scramble into a shared, up-front agreement. They also end the most tiring argument in software — "is this done?" — by making the answer a checklist anyone can read, rather than a negotiation every time.
QA DEFINITION OF READY
From QA's seat, a story is ready when it can actually be tested. That means testable acceptance criteria, known dependencies, available test data, and a clear picture of the edge cases — not just the happy path. If QA can't say how they'd verify the story, it isn't ready, however polished it looks.
The DoR is a gate, not a wish list. A story that fails it doesn't enter the sprint; it goes back to refinement. That feels strict, but it's far cheaper to fix a vague story before the sprint than to discover mid-cycle that nobody knows what "correct" means.
STORY READINESS CHECKLIST
- Acceptance criteria are written, testable, and unambiguous.
- The story is small enough to build and test within one sprint.
- Dependencies (APIs, services, designs, data) are identified and available.
- Test data needs are known and can be provisioned for the story.
- Non-functional expectations (performance, accessibility, security) are stated where relevant.
- Edge cases and error scenarios are noted, not just the happy path.
- Designs or a spec exist that QA can test the behaviour against.
- QA has reviewed the story and has no blocking questions.
QA DEFINITION OF DONE
A story is done, from QA's seat, when it's been verified — not merely written. Every acceptance criterion checked, the planned cases run, automation in place and green, and no open Critical or High defects unless they've been explicitly accepted. "It compiles" and "it demoed" are not done.
Keeping the DoD honest is what stops technical debt and quality debt piling up invisibly. A consistent bar means every story that leaves the sprint has been held to the same standard, so "done" columns actually mean done.
TESTING COMPLETION CHECKLIST
- All acceptance criteria are verified.
- Planned functional and negative test cases have been executed.
- No open Critical or High defects — or each is documented and accepted.
- Automated tests for the story are written and passing in CI.
- The feature works across the agreed browsers and devices.
- Accessibility checks for the story are complete or marked N/A.
- The story has been tested on an environment that matches production.
- Test cases and their results are recorded where the team can find them.
AUTOMATION & ACCESSIBILITY READINESS
Decide up front whether automation and accessibility are part of your DoD, because if they're optional they'll be skipped under pressure. For most teams the right bar is: automated coverage exists for the story's core paths and runs in CI, and the story meets the agreed accessibility standard (commonly WCAG 2.1 AA) or is explicitly marked not applicable.
Be realistic about scope. "Automate everything" as a DoD item just gets ignored; "the happy path and key negative cases are automated" is achievable and meaningful. The same goes for accessibility — name the specific checks (keyboard, contrast, labels) so "accessible" isn't left to interpretation.
RELEASE READINESS
Story-level done isn't the same as release-level ready. A release adds gates that only make sense across the whole increment: regression has passed, exit criteria from the test plan are met, known issues are documented with workarounds, and a rollback plan exists. Think of it as a DoD for the release rather than the story.
This is where the per-story DoD pays off: if every story genuinely met its bar, release readiness is a short confirmation rather than a frantic catch-up. The formal version of that confirmation is the release sign-off, linked below.
COMMON MISTAKES
Treating the DoR/DoD as documentation, not gates.
If a story can fail the checklist and still proceed, it isn't a gate. Hold the line — a failed DoR goes back to refinement.
Letting "done" mean "dev-complete".
Done includes tested. A story that's coded but unverified is in progress, not done, however good the demo looked.
Writing criteria too vague to check.
"Works well" can't be verified. Make every item a yes/no check — testable acceptance criteria, no open High defects, automation green.
Setting the bar once and never revisiting it.
Review the DoR/DoD periodically. As the product and team mature, the gates should too — drop what's stale, add what keeps biting you.
Imposing them top-down.
Gates the team didn't agree to get gamed or ignored. Define them together so everyone owns the standard.