Igor Yussupov
UAT exit criteria are the conditions that must be true before a round can end and the release can proceed. They exist so that the go or no-go decision is made against rules agreed earlier, not against the pressure of the last day. A useful set is short: the scenarios that must pass, a limit on open defects by severity, a decision recorded for every defect that stays open, and a named approver. Below are examples, a go or no-go table you can adapt and a way to handle the awkward cases.
What exit criteria are for
Without exit criteria, a UAT round ends when the deadline arrives or when the loudest voice wins. With them, it ends when the evidence meets a standard the approver agreed before anyone had a favourite bug to defend. They also protect testers: a bug that meets the "must fix" definition is fixed, and does not depend on who reported it.
They belong in the plan (section 8 of the UAT test plan template), next to the entry criteria that say when the round may start. The final decision is recorded in the sign-off.
Example criteria
These are examples. Replace the thresholds with ones your approver agrees to.
- Coverage. All must-have scenarios have been run at least once by a business tester. Nice-to-have scenarios are run or consciously deferred.
- Pass rate on the critical path. Every scenario on the critical business path has passed. For secondary scenarios, failures have a recorded decision.
- Defect limits. No open Critical defects. No open Major defects without an accepted workaround.
- Every open defect has a decision. Fix before release, accept with a workaround, or defer with an owner and a date. Nothing is open and undiscussed.
- Retest. Every defect marked fixed has been retested, ideally by the person who reported it.
- Stable build. The build tested is the build going live, or each change after the round has been assessed.
- Approver available. The named approver, or the stand-in, has reviewed the record and signed.
A go or no-go table by severity
A table makes the rules concrete. This one uses four severity levels; severity vs priority explains the scale and who sets it.
| Open defect | Default decision | Exception needs |
|---|---|---|
| Critical: system unusable, data loss, security | No-go | Written agreement from the approver and the technical owner, with a mitigation |
| Major: main function broken | No-go, unless a workaround exists | The workaround is documented and users are told |
| Minor: easy workaround | Go | Listed, with an owner and a target date |
| Trivial: cosmetic | Go | Listed in the backlog |
The default column is what happens when nobody argues. The exception column is what you must produce to override it, and it should take effort. If an override is easy, it will be used every time.
A critical defect on the last day
This is the case the criteria are for. A tester finds a Critical defect with two days to go and the release date fixed. The criteria say no-go. Pressure says otherwise. What helps:
- Check it is real. Can a second person reproduce it? A report with the steps, the error and the failing request settles this in minutes. A one-line report takes a day, and the day is what you do not have.
- Check the severity against the scale. Is it really Critical by the definition, or is it a Major with a bad day behind it?
- List the options. Fix and retest, ship with the feature switched off, ship with a workaround, or move the date. Each has a cost; write them down.
- Let the approver decide, in writing. They own the outcome. The record says which option was chosen and why.
The quality of the defect report decides how fast this goes. A report with the element, the console error with file and line, the failing request and the steps can be handed straight to a developer. That is the job of the reporting tool in the round; SnagRelay attaches those to the report, and sends it to your tracker, so the question "is it real?" is answered when the ticket arrives. It does not decide go or no-go, and it does not manage the criteria. That stays with your approver and your plan.
Be careful with percentages
"95% of scenarios passed" sounds like a standard, and often is not. Ask what the 5% is. If the five failing scenarios are the five that matter most, the number is misleading. Better rules are:
- Name the scenarios that must pass, not a percentage of all of them.
- Use a percentage only for secondary scenarios, and say which.
- Count defects by severity, not in total. Twenty trivial defects and one critical defect are not the same situation.
Recording the decision
For each criterion, write "met" or "not met". For each open defect, record the severity, the decision, the owner and the date. If the round ends with a criterion not met, the record should say so and say who accepted it. That sentence, signed, is what separates a managed risk from a surprise. The UAT checklist is a good companion for the last day.
FAQ
What are UAT exit criteria?
The agreed conditions that must be met before a UAT round can end and the release can proceed: scenarios run and passed, limits on open defects by severity, a decision recorded for each open defect, and an approver's sign-off.
What is the difference between entry and exit criteria?
Entry criteria say when UAT may start, for example QA complete and the environment ready. Exit criteria say when it may finish. Both are agreed before the round begins.
Can we go live with open defects?
Yes, if each open defect is listed, rated, accepted by the approver and has an owner and a date. A short list of known minor issues is normal. An open Critical defect should block the release unless the approver accepts the risk in writing.
Who decides go or no-go?
The business owner or product owner who is accountable for the outcome. QA and the project team provide the evidence and a recommendation.