>_ UAT Entry and Exit Criteria Checklist

Short answer

A UAT Entry and Exit Criteria Checklist is a readiness and closure checklist that helps a team decide when User Acceptance Testing can start and when User Acceptance Testing can be signed off.

This is not a full UAT execution checklist. It is a readiness and closure checklist for deciding when UAT can start, when UAT can be closed, and when stakeholders can make a UAT sign-off or go/no-go decision.

UAT entry criteria define the conditions that must be true before business users, client stakeholders, or product owners begin acceptance testing.

UAT exit criteria define the conditions that must be true before UAT can be considered complete, accepted, and ready for release, go-live, or client handoff.

The main idea is: UAT should not start just because development is "mostly done," and it should not close just because "people tested something." UAT needs clear entry gates, exit gates, sign-off criteria, and a documented go/no-go decision.

---

What this checklist is and is not

This checklist is focused on UAT readiness and UAT closure.

Use it to answer:

• Are we ready to start UAT?
• Are requirements and acceptance criteria clear enough?
• Is the UAT environment ready?
• Are test users, roles, and data ready?
• Are blocker and critical bugs under control?
• Has UAT been completed enough to close?
• Are known issues accepted?
• Are change requests separated from bugs?
• Has stakeholder sign-off been received?
• Is the team ready for a go/no-go decision?

This checklist is not a full guide for executing every UAT scenario. For that, use the broader User Acceptance Testing Checklist, which covers business scenarios, workflows, roles, approvals, reports, usability, integrations, feedback, and sign-off in more detail.

In simple terms:

User Acceptance Testing Checklist = what to test during UAT. UAT Entry and Exit Criteria Checklist = when UAT can start and when UAT can close.

---

UAT Entry Criteria vs UAT Exit Criteria

UAT entry criteria are the conditions that must be met before UAT starts.

They help prevent UAT from starting too early, before the product is stable enough for business users or stakeholders to review.

Entry criteria usually cover:

• agreed UAT scope;
• clear business goal;
• available requirements;
• approved acceptance criteria;
• completed QA pass;
• stable UAT environment;
• correct build/version;
• prepared users and roles;
• realistic test data;
• prepared UAT scenarios;
• ready integrations, emails, reports, and approvals;
• clear issue tracking process;
• identified stakeholders and approvers.

UAT exit criteria are the conditions that must be met before UAT can be closed.

They help prevent the team from accepting a release too early, before business workflows are verified and risks are understood.

Exit criteria usually cover:

• critical UAT scenarios executed;
• acceptance criteria checked;
• business workflows accepted;
• blocker issues closed;
• critical issues fixed or formally accepted;
• major issues fixed, accepted, or deferred with approval;
• known issues documented;
• change requests separated from bugs;
• fixes retested;
• UAT summary prepared;
• stakeholder sign-off received;
• UAT go/no-go decision made.

In simple terms: entry criteria protect UAT from a premature start, while exit criteria protect the release from premature acceptance.

---

When to use UAT Entry and Exit Criteria

Use this checklist before starting UAT and before closing UAT.

For example:

• before a major release;
• before launching a new feature;
• before client handoff;
• before enterprise go-live;
• before releasing an internal tool;
• before accepting a CRM, ERP, dashboard, admin panel, or customer portal;
• before approving a new workflow;
• before accepting migrated data;
• before launching a checkout or payment flow;
• before completing UAT for a SaaS product;
• before asking stakeholders for UAT sign-off;
• before making a UAT go/no-go decision.

For a small feature, entry and exit criteria can be short. For enterprise rollouts, client projects, internal systems, or complex SaaS releases, UAT entry and exit criteria should be documented explicitly in a ticket, release checklist, project document, or project management system.

---

Short UAT Entry Criteria Checklist

Before starting UAT, check that:

• UAT scope is agreed;
• business goal is clear;
• requirements are available and current;
• acceptance criteria are documented;
• critical business scenarios are prepared;
• QA functional testing is completed;
• smoke testing has passed;
• blocker bugs are closed;
• critical bugs are closed or explicitly accepted for UAT entry;
• UAT environment is available and stable;
• correct build/version is deployed;
• feature flags are configured;
• test users and roles are ready;
• realistic UAT data is prepared;
• required integrations are ready;
• emails, notifications, approvals, reports, or exports are ready if they are in scope;
• stakeholders and approvers are identified;
• UAT schedule is agreed;
• issue tracking process is clear;
• bug vs change request rules are agreed;
• UAT entry decision is documented.

If these conditions are not met, UAT may turn into a chaotic review of an unfinished product instead of a structured acceptance process.

---

Short UAT Exit Criteria Checklist

Before closing UAT, check that:

• all critical UAT scenarios were executed;
• acceptance criteria were checked;
• business workflows were accepted;
• blocker issues are closed;
• critical issues are closed or formally accepted;
• major issues are fixed, accepted, or deferred with approval;
• known issues list is documented and approved;
• change requests are separated from bugs;
• deferred items are agreed;
• fixes were retested;
• regression smoke after fixes was completed if needed;
• reports, exports, data, integrations, and permissions were accepted if they are in scope;
• remaining risks are documented;
• UAT summary is prepared;
• stakeholders reviewed the result;
• UAT sign-off is received;
• UAT go/no-go decision is made;
• next steps are clear.

UAT can be considered complete only when the result is clear, documented, and accepted by the responsible stakeholders.

---

UAT Entry Criteria Checklist

1. UAT scope is agreed

UAT should not start until the team knows exactly what is being accepted.

Check that:

• the feature, release, system, or workflow going into UAT is clear;
• modules included in UAT are listed;
• modules outside UAT are listed;
• user roles included in UAT are known;
• business workflows included in UAT are defined;
• reports, dashboards, exports, emails, approvals, and integrations in scope are listed;
• important devices or browsers are known;
• critical scenarios are identified;
• known limitations are documented;
• scope owner is known;
• stakeholders agree on what UAT covers.

This is an entry gate, not a testing activity. The goal is to prevent UAT from expanding into "test everything we can think of."

---

2. Business goal is clear

UAT should be tied to a business outcome, not just a set of screens.

Check that:

• the business problem is clear;
• the target user is defined;
• expected business outcome is documented;
• stakeholders understand why UAT is being performed;
• success definition is agreed;
• UAT scenarios reflect real work;
• business owner agrees with the goal;
• UAT is not reduced to UI review only.

Weak goal: "Test the dashboard." Better goal: "Sales manager can view leads by status, owner, region, and date range, then export the filtered list for weekly reporting."

---

3. Requirements are available and current

Before UAT starts, requirements should be clear enough to support an acceptance decision.

Check that:

• requirements are available to participants;
• requirements are current;
• business rules are described;
• user roles are described;
• workflow steps are described;
• expected results are clear;
• dependencies are listed;
• limitations are documented;
• open questions are closed or explicitly out of scope;
• stakeholders agree that these requirements can be used for acceptance.

If requirements are unclear, UAT becomes subjective. Each participant tests against their own expectations.

---

4. Acceptance criteria are documented

Acceptance criteria are the foundation for both UAT execution and UAT exit.

Check that:

• acceptance criteria exist;
• criteria are testable;
• criteria are connected to business scenarios;
• criteria cover critical workflows;
• criteria cover relevant roles;
• expected results are clear;
• criteria are not vague;
• stakeholders have approved the criteria;
• QA and PM understand how to verify them;
• criteria will not change during UAT without a scope decision.

Weak criterion: "User can use the report." Better criterion: "Finance user can filter invoice report by month, customer, and status, then export the filtered result as CSV."

---

5. QA functional testing is completed

UAT should not be the first serious test pass.

Check that:

• core functional QA is completed;
• release QA is completed if applicable;
• smoke testing has passed;
• sanity testing after latest fixes is completed;
• regression testing is completed for affected areas;
• critical user flows were checked by QA;
• known QA issues are documented;
• QA agrees that the build is ready for UAT;
• business users are not expected to discover basic functional bugs.

UAT should validate business acceptance. It should not be the first place where the team discovers that login, save, submit, or navigation does not work.

---

6. Blocker and critical bugs are controlled before UAT

UAT usually should not start if blocker issues prevent key workflows.

Check that:

• blocker bugs are closed;
• critical bugs are closed;
• bugs blocking login or access are closed;
• bugs blocking critical workflows are closed;
• bugs blocking test data are closed;
• bugs blocking reports, integrations, or approvals are closed if those are in scope;
• unresolved critical bugs have explicit stakeholder acceptance if UAT still starts;
• known issues list is shared;
• stakeholders understand remaining issues before entry approval.

Minor known issues may be acceptable at UAT entry. Blockers that prevent business users from completing critical scenarios usually are not.

---

7. UAT environment is ready

UAT environment should be stable enough for business users and stakeholders.

Check that:

• UAT environment is available;
• environment is stable;
• latest approved build is deployed;
• correct version is visible or documented;
• environment is not being used for uncontrolled development testing;
• feature flags are configured;
• test email sending works if needed;
• integrations are configured in safe mode;
• payment or billing test mode is enabled if needed;
• URLs are clear to participants;
• downtime or maintenance windows are known;
• stakeholders know where to perform UAT.

If the UAT environment is unstable, participants will test environment problems instead of product readiness.

---

8. Build/version is ready for UAT

UAT should be performed on a specific build or release candidate.

Check that:

• build version is known;
• release candidate is approved for UAT;
• latest fixes are included;
• deployment is completed;
• deployment notes are available if needed;
• migration scripts were executed if needed;
• feature flags are in the expected state;
• no critical deployment tasks are pending;
• team understands exactly what was handed to UAT.

"Test whatever is currently on staging" is not a reliable UAT entry strategy.

---

9. UAT users and roles are ready

UAT should be performed under realistic roles, not only under admin.

Check that:

• test users are created;
• users have correct roles;
• admin role is ready;
• manager role is ready if needed;
• regular user role is ready;
• viewer or approver role is ready if applicable;
• external/client user is ready if applicable;
• guest scenario is ready if in scope;
• permissions match real workflows;
• users do not have unnecessary access;
• credentials are available;
• password reset works if participants need to log in themselves.

If UAT is performed only as admin, the team may miss blockers that affect real users.

---

10. Realistic UAT data is prepared

UAT data should look close enough to real business data.

Check that:

• test data is prepared;
• data matches UAT scenarios;
• records exist in different statuses;
• data exists for different roles;
• filled states are available;
• empty states are available;
• exception cases are available;
• data exists for reports and exports;
• data exists for approvals;
• migrated data is available if migration is in scope;
• sensitive production data is anonymized if used;
• stakeholders can understand the data without developer help.

Unrealistic data weakens UAT because business users cannot judge whether the system supports real work.

---

11. UAT scenarios are prepared

Participants need scenarios before UAT starts.

Check that:

• UAT scenarios are documented;
• scenarios are based on real business workflows;
• each scenario has a starting point;
• each scenario has an expected result;
• scenarios cover critical flows;
• scenarios cover relevant roles;
• scenarios include positive cases;
• scenarios include realistic exception cases;
• scenarios are understandable to non-technical users;
• stakeholders agree with the scenarios.

This is an entry criterion: business users should not be asked to "just look around and tell us what you think."

---

12. Integrations, emails, notifications, reports, and approvals are ready

If these items are part of acceptance, they must be ready before UAT.

Check that:

• CRM integration is ready if in scope;
• ERP or fulfillment integration is ready if in scope;
• payment test mode is ready if in scope;
• email notifications are working;
• approval notifications are working;
• links in emails are correct;
• reports open;
• dashboards have data;
• exports work;
• external sandbox systems are available;
• stakeholders know which integrations are real and which are mocked.

UAT may pass visually while the business process fails if integrations, emails, reports, or approvals are not ready.

---

13. Issue tracking and triage process is ready

UAT feedback should have a defined path.

Check that:

• issue tracking tool is selected;
• participants know where to submit feedback;
• issue template is ready;
• severity definitions are clear;
• priority definitions are clear;
• triage owner is assigned;
• review cadence is known;
• screenshots/videos are accepted;
• reproduction steps are expected;
• bugs, questions, and change requests will be separated;
• communication channel is ready.

Without a clear issue process, UAT feedback becomes scattered across chats, calls, and informal comments.

---

14. Bug vs change request rules are agreed

This should be agreed before UAT starts.

Check that:

• bug definition is clear;
• change request definition is clear;
• out-of-scope feedback process is clear;
• product owner will decide disputed items;
• stakeholders understand that new wishes do not automatically block UAT;
• timeline or budget impact is considered;
• change requests will not automatically block exit criteria;
• blockers are tied to acceptance criteria or critical workflows.

A bug means the system does not meet an agreed requirement or acceptance criterion.

A change request means a stakeholder wants new or changed behavior that was not agreed before.

---

15. Stakeholders and approvers are ready

UAT needs the right people, not just "someone from the business."

Check that:

• stakeholders are identified;
• business users know their role;
• final approver is known;
• UAT schedule is agreed;
• participants have access to the environment;
• participants have credentials;
• scenarios were shared;
• instructions are clear;
• support/contact person is known;
• participants know how to report issues;
• participants understand the bug vs change request rule.

If the approver is not defined before UAT starts, sign-off can become slow, unclear, or disputed.

---

16. UAT entry approval is documented

UAT should start with an explicit entry decision.

Check that:

• entry criteria were reviewed;
• open risks are documented;
• known issues are shared;
• QA is ready to hand over the build;
• product owner agrees to start;
• business owner or client stakeholder agrees to start;
• stakeholders are informed;
• environment is ready;
• scenarios are ready;
• UAT entry decision is documented.

This can be a ticket comment, release checklist item, project management status, or short written approval. The important part is that UAT starts intentionally.

---

UAT Exit Criteria Checklist

17. Critical UAT scenarios were executed

Before UAT can close, the planned critical scenarios should be completed or explicitly waived.

Check that:

• all critical scenarios were executed;
• all planned scenarios were executed or skipped with a documented reason;
• scenarios were tested by the correct roles;
• positive workflows were checked;
• realistic exception workflows were checked;
• results were documented;
• failed scenarios have linked issues;
• skipped scenarios are documented;
• stakeholders confirmed results in their areas.

UAT does not pass just because the planned testing window ended.

---

18. Acceptance criteria were verified

UAT exit should be tied to acceptance criteria.

Check that:

• each acceptance criterion was reviewed;
• passed criteria are marked;
• failed criteria have linked issues;
• partially passed criteria have decisions;
• criteria did not change without a scope decision;
• stakeholders agree with the interpretation;
• product owner reviewed results;
• business owner reviewed results.

Without verified acceptance criteria, UAT sign-off is weak and subjective.

---

19. Business workflows were accepted

UAT closure should confirm that real business work can be done.

Check that:

• primary workflow is accepted;
• secondary workflows are accepted if important;
• user can complete tasks end-to-end;
• handoff between roles works;
• statuses change correctly;
• approvals work;
• notifications work;
• data appears in the next step;
• reports reflect workflow results;
• users do not rely on unapproved manual workarounds;
• stakeholders consider the workflow usable for real work.

The main exit question is: can the business actually use this after go-live?

---

20. Blocker issues are closed

Blocker issues should be closed before UAT exit.

Check that:

• no blocker issues remain open;
• found blockers were fixed;
• fixes were retested;
• affected workflow was rechecked;
• no unresolved blocker was silently accepted;
• blocker severity was not downgraded just to release;
• business owner understands impact;
• release does not proceed with a blocker without explicit no-go exception.

A blocker means a critical workflow cannot be completed. It is normally incompatible with UAT closure.

---

21. Critical issues are fixed or formally accepted

Critical issues should either be fixed or explicitly accepted as risk.

Check that:

• all critical issues are listed;
• fixed critical issues were retested;
• unresolved critical issues have a decision;
• business impact is described;
• workaround is documented if available;
• business acceptance is recorded if the issue remains;
• owner is assigned;
• target fix date is defined if deferred;
• stakeholders agree with the risk.

UAT can sometimes close with a critical known issue, but only when the business owner explicitly accepts the risk.

---

22. Major issues have a decision

Major issues may or may not block UAT closure, but they cannot be ignored.

Check that:

• major issues were reviewed;
• severity and priority are agreed;
• each issue has an owner;
• each issue has a status;
• issues affecting go-live are identified;
• deferred issues are documented;
• workarounds are documented;
• no duplicate unresolved issues remain;
• no hidden "we'll check later" list exists.

UAT exit does not always require zero bugs. It requires clear decisions about bugs.

---

23. Known issues list is approved

If UAT closes with known issues, they should be transparent and accepted.

Check that known issues include:

• title;
• description;
• impact;
• affected users;
• severity;
• workaround;
• owner;
• planned fix date or backlog status;
• business acceptance;
• whether the issue blocks go-live.

A known issues list should be understandable to business stakeholders, not only QA.

---

24. Change requests are separated from bugs

Before sign-off, new requests should be separated from defects.

Check that:

• all feedback items are classified;
• bugs are connected to requirements or acceptance criteria;
• change requests are separated;
• out-of-scope feedback is documented;
• product owner reviewed classification;
• stakeholders understand what will be fixed now;
• stakeholders understand what moves to backlog;
• change requests do not block UAT closure without a decision;
• scope creep is controlled.

This is one of the most important UAT closure criteria. Without it, UAT can expand forever.

---

25. Deferred items are agreed

Deferred items are items that will not be completed before release or go-live.

Check that:

• deferred bugs are documented;
• deferred change requests are documented;
• reason for deferral is clear;
• impact is clear;
• owner is assigned;
• next release or backlog target is defined;
• business owner accepts deferral;
• deferred item does not contradict acceptance criteria;
• user communication is prepared if needed.

Deferred does not mean forgotten. It means consciously moved to a later stage.

---

26. Fixes were retested

If issues were fixed during UAT, the fixes should be verified.

Check that:

• UAT bugs were fixed;
• fixes were deployed to the correct environment;
• fixed issues were retested;
• affected workflows were rechecked;
• no obvious new regression appeared;
• QA confirmed fixes;
• stakeholders confirmed critical fixes if needed;
• issue statuses were updated;
• regression smoke was completed if changes were risky.

A fix is not complete just because a developer marked it "done."

---

27. Reports, exports, data, and integrations were accepted if in scope

For many business systems, outputs and integrations are part of acceptance.

Check that:

• reports were validated by business users;
• dashboard metrics were accepted;
• exports were accepted;
• CSV/XLSX/PDF files open correctly;
• calculations were accepted;
• filters and date ranges were accepted;
• migrated data was accepted if applicable;
• CRM/ERP/payment/email/fulfillment integrations were accepted if in scope;
• integration limitations are documented;
• remaining data discrepancies are documented and accepted.

If the UI works but reports, exports, or integrations fail, UAT may not be ready to close.

---

28. Role and permission model was accepted

For internal tools, SaaS, and enterprise products, role acceptance is often critical.

Check that:

• each key role was tested;
• role access was accepted;
• admin access was accepted;
• manager access was accepted;
• regular user access was accepted;
• approver access was accepted;
• external/client user access was accepted if applicable;
• users do not see unnecessary data;
• users can perform their tasks;
• direct access concerns are documented;
• business owner accepted the permission model.

Permission issues can become release blockers even when functionality works.

---

29. Remaining risks are documented

UAT exit does not mean there are no risks. It means risks are known and accepted or resolved.

Check that:

• technical risks are documented;
• business risks are documented;
• operational risks are documented;
• data risks are documented;
• integration risks are documented;
• support risks are documented;
• workaround is documented;
• owner for each risk is assigned;
• risk is accepted or requires action;
• go-live impact is clear.

No release is risk-free. Hidden risk is the real problem.

---

30. UAT summary is prepared

A UAT summary should give a clear picture of the result.

Include:

• UAT scope;
• tested scenarios;
• tested roles;
• tested environment;
• build/version;
• participants;
• passed scenarios;
• failed scenarios;
• skipped scenarios;
• issues found;
• issues fixed;
• known issues;
• deferred items;
• change requests;
• remaining risks;
• recommendation;
• final status.

A good UAT summary helps stakeholders make a decision without relying on "seems fine."

---

31. Stakeholder review is completed

Before sign-off, stakeholders should review the result.

Check that:

• product owner reviewed the summary;
• business owner reviewed the summary;
• client stakeholder reviewed the summary if this is a client project;
• key user representatives reviewed results;
• QA reviewed open issues;
• support/operations were informed if needed;
• finance/legal/security reviewed results if they are in scope;
• no stakeholder has an unresolved blocker objection.

If a key approver has not reviewed the result, sign-off can be challenged later.

---

32. UAT sign-off is received

UAT should close with explicit approval or a no-go decision.

Check that:

• approver is identified;
• sign-off is received;
• sign-off is written;
• sign-off is stored in the agreed place;
• scope of sign-off is clear;
• build/version is clear;
• known issues are included;
• deferred items are included;
• risks are accepted;
• release/go-live recommendation is included;
• date and approver are recorded.

This is the core of UAT sign-off criteria: the right person accepts the right scope on the right version with known issues and risks visible.

---

33. UAT go/no-go decision is made

UAT sign-off and release decision are related, but they are not always identical.

Check that:

• go/no-go discussion was held if needed;
• UAT result was reviewed;
• QA result was reviewed;
• release readiness was reviewed;
• deployment readiness was reviewed;
• support readiness was reviewed;
• rollback/fallback plan was reviewed if relevant;
• known issues were reviewed;
• final decision was documented;
• decision owner is identified;
• next steps are communicated.

Sometimes UAT passes, but release is delayed because of deployment, legal, support, business timing, or operational readiness. That is fine if the decision is documented.

---

34. Post-UAT actions are documented

After UAT closure, follow-up should not be lost.

Check that:

• bugs were moved to the correct status;
• change requests were moved to backlog;
• deferred items were assigned;
• known issues were shared;
• release notes were updated if needed;
• support notes were updated;
• training was updated if needed;
• documentation was updated;
• monitoring/support plan is ready;
• next iteration items are planned;
• stakeholders are informed of next steps.

UAT closure is not the end of the work. It is the point where acceptance is decided and follow-up becomes managed.

---

Common mistakes

1. Starting UAT before QA is ready

If QA has not checked the core functionality, business users will find basic bugs instead of validating business readiness.

2. Running UAT without acceptance criteria

Without acceptance criteria, the team cannot objectively say whether UAT passed or failed.

3. Treating UAT as another general QA pass

UAT is not just more testing. It is business acceptance. Entry and exit criteria should reflect readiness, acceptance, and sign-off.

4. Not defining the approver

Many people can give feedback, but sign-off should come from someone with authority to accept the result.

5. Using unrealistic test data

If test data does not look like real business data, stakeholders cannot judge whether the product is usable in real work.

6. Not separating bugs from change requests

Without separation, UAT becomes an endless list of new requirements instead of an acceptance process.

7. Closing UAT without a known issues list

If remaining issues are not documented, the team may later argue about whether they were accepted.

8. Treating the calendar end date as UAT exit

The end of the scheduled UAT window is not the same as meeting exit criteria.

9. Not recording sign-off in writing

A verbal "yes, looks okay" is weak for release, client handoff, and enterprise rollout.

10. Not making a go/no-go decision

UAT sign-off does not automatically mean release. The team still needs an explicit release or go-live decision.

---

FAQ

What is a UAT Entry and Exit Criteria Checklist?

A UAT Entry and Exit Criteria Checklist is a readiness and closure checklist for User Acceptance Testing.

It helps define when UAT can start, when UAT can close, what must be true before stakeholder sign-off, and when a UAT go/no-go decision can be made.

What are UAT entry criteria?

UAT entry criteria are the conditions that should be met before UAT starts.

Common UAT entry criteria include:

• agreed scope;
• clear business goal;
• available requirements;
• documented acceptance criteria;
• completed QA testing;
• closed blocker bugs;
• stable UAT environment;
• correct build/version;
• prepared users and roles;
• realistic test data;
• prepared UAT scenarios;
• ready integrations and notifications;
• clear issue tracking process;
• identified stakeholders and approvers.

What are UAT exit criteria?

UAT exit criteria are the conditions that should be met before UAT is closed.

Common UAT exit criteria include:

• critical scenarios executed;
• acceptance criteria verified;
• business workflows accepted;
• blocker issues closed;
• critical issues fixed or accepted;
• major issues reviewed;
• known issues approved;
• change requests separated from bugs;
• fixes retested;
• UAT summary prepared;
• stakeholder sign-off received;
• go/no-go decision made.

What is the difference between UAT entry criteria and UAT exit criteria?

UAT entry criteria answer: can UAT start?

UAT exit criteria answer: can UAT be closed and signed off?

Entry criteria prevent UAT from starting too early. Exit criteria prevent the product from being accepted too early.

What are UAT sign-off criteria?

UAT sign-off criteria are the conditions that must be true before the responsible stakeholder approves UAT completion.

They usually include:

• acceptance criteria verified;
• critical scenarios completed;
• blockers closed;
• critical issues fixed or accepted;
• known issues documented;
• change requests separated;
• UAT summary reviewed;
• remaining risks accepted;
• approver confirms acceptance in writing.

What are UAT closure criteria?

UAT closure criteria are the conditions for formally closing the UAT phase.

They usually include completed UAT scenarios, verified acceptance criteria, closed or accepted issues, approved known issues list, prepared UAT summary, stakeholder sign-off, go/no-go decision, and documented next steps.

Can UAT start with open bugs?

Yes, but only if the open bugs do not block critical business scenarios and stakeholders understand the known issues.

UAT usually should not start with unresolved blockers or critical bugs that prevent the main workflow from being completed.

Can UAT close with known issues?

Yes, if known issues are documented, reviewed, assigned, and accepted by the business owner or client approver.

Known issues should have clear impact, workaround, owner, and decision. They should not secretly violate acceptance criteria.

What bugs block UAT exit?

UAT exit is usually blocked by:

• unresolved blocker issues;
• unresolved critical issues without business acceptance;
• bugs preventing critical workflow completion;
• access or permission issues;
• data corruption issues;
• broken integrations in scope;
• issues that violate acceptance criteria.

How is UAT exit different from release criteria?

UAT exit criteria confirm that business users or stakeholders accepted the product from an acceptance perspective.

Release criteria are broader. They may also include deployment readiness, security, performance, monitoring, rollback plan, support readiness, legal approval, and production smoke testing.

What is a UAT go/no-go decision?

A UAT go/no-go decision is the decision to move forward or stop based on UAT results, known issues, risks, and business readiness.

A "go" means stakeholders accept the result and agree to move forward. A "no-go" means UAT or release cannot proceed until specific issues or risks are resolved.

How do you know UAT is ready to close?

UAT is ready to close when:

• critical scenarios are executed;
• acceptance criteria are verified;
• business workflows are accepted;
• blockers are closed;
• critical issues are fixed or accepted;
• known issues are documented and approved;
• change requests are separated from bugs;
• fixes are retested;
• UAT summary is prepared;
• stakeholders reviewed the result;
• sign-off is received;
• go/no-go decision is documented.