Entry criteria, exit criteria and the definition of done

Entry criteria are the conditions that must be true before testing starts. Exit criteria are the conditions that must be true before testing can be called finished.

Both are agreed in advance, usually in the test plan, and both are short. A typical set is four or five lines each.

Two related terms turn up in the same conversation. Suspension criteria say when you stop testing because continuing is pointless, for example when the environment is broken. Resumption criteria say what must be fixed before you start again.

The value is entirely in the timing. Agreed before the release, these are protection for everybody. Invented on the final afternoon, they are an argument you will lose.

The terms you will hear

• Entry criteria. Conditions for starting. Feature complete, pipeline green, data seeded.
• Exit criteria. Conditions for stopping. All criteria checked, no open critical defects, pack run.
• Suspension criteria. When to stop early, such as a blocker that makes further testing meaningless.
• Resumption criteria. What must be true to restart after a suspension.
• Definition of done. The team-wide version, applied per story rather than per release.
• Quality gate. Any automated version of the same idea, usually enforced by the pipeline.

Why it matters

Because without them, "is testing finished" is answered by whoever is most senior and most impatient.

For example, testing starts on a build that is not feature complete. Half the cases are blocked, the tester re-runs them three times as code lands piecemeal, and two days vanish. An entry criterion saying "all stories marked feature complete" would have turned that into a short conversation on Monday.

Exit criteria do the same job at the other end. They convert "we think it is fine" into a checkable list, and they let you say yes with evidence rather than with a feeling.

How to write a set that holds

1. Keep each list to four or five lines. Long lists get waived, and a waived criterion is worse than none.
2. Make every line checkable today. "Pipeline green on the release branch" is checkable. "Code quality is good" is not. The same test as a testable acceptance criterion.
3. Write exit criteria you would genuinely hold. If you would ship with two open medium defects, write that, and say who accepts them.
4. Include a stop rule. For example: if the environment is unusable for more than two hours, testing suspends and the release date is reviewed.
5. Name who accepts an exception. Almost every release has one. A named person turns it into a decision with a paper trail.
6. Report against them at the end. The summary report exists to answer these lines one by one, which makes writing it quick.
7. Review them once a quarter. A criterion nobody has met for six months is either wrong or being ignored, and both need saying out loud.

A worked set

For example, here is the set for one release, taken from the plan and then reported against.

The entry section is the interesting one. One criterion was not met, so the decision was explicit and recorded rather than absorbed silently. That is the whole point of writing them down.

How to show you know it

• A set of five and five for a real release, in the plan rather than invented afterwards.
• A criterion that was not met, with the decision. It proves the list is real and not decorative.
• A suspension rule. Most teams have never written one, and it is the line that protects a wasted week.
• A report answering each line. Being able to say "criterion four was met with two accepted defects" is what senior sign-off sounds like. It also makes the regression cycle log worth keeping.