# UAT Readiness Checklist

**Release:** _______________  **Business owner:** _______________
**Proposed window:** _______  **Checked by:** _______  **Date:** _______

## 1. Before the window is booked

- [ ] System testing **complete**, with known defects listed and severity agreed
- [ ] The build is stable — not changing daily under the testers
- [ ] Environment available for the whole window, with no other team using it
- [ ] Data volumes realistic, not a clean demo set
- [ ] Integrations connected, or their stubs explicitly agreed and documented
- [ ] Test accounts created **and logged into** at each permission level
- [ ] Participants trained on the new system
- [ ] Defect reporting route takes under a minute to use

🔴 Starting UAT on an unstable build is the most common way the phase fails. Participants spend
their limited time on defects the project already knew about, lose confidence, and stop reporting
anything.

## 2. People — the part that decides everything

- [ ] Participants are **the people who will use the system**, in their own roles
- [ ] Their time is **formally released** — not "fit it around your work"
- [ ] Hours committed per person: ____ per day, for ____ days
- [ ] Their manager has agreed in writing
- [ ] Range covered: experienced **and** new users
- [ ] Awkward regional / departmental variants represented
- [ ] Participants have authority to say the system is not acceptable

**If the release of time did not happen, stop here.** UAT on top of a full workload produces
box-ticking and an uninformed decision to accept.

## 3. Scenarios

- [ ] Written as **end-to-end business scenarios**, not feature checklists
- [ ] Cover the work the system actually exists to do
- [ ] At least two exception cases included
- [ ] At least one period-end / month-end process included
- [ ] Time deliberately reserved for **unscripted exploration**
- [ ] Number of scenarios: ____

Scripted tests confirm what somebody already thought of. The valuable findings come from
participants simply doing their job in the system and reporting what got in the way.

## 4. Acceptance criteria — agreed BEFORE testing starts

- [ ] Written in business language
- [ ] Each answerable yes or no
- [ ] Baselines recorded where a comparison is implied

| # | Criterion | Met? |
|---|---|---|
| 1 | | |
| 2 | | |

## 5. Exit criteria and severity — agreed while the answer is hypothetical

| Severity | Definition | Blocks go-live? |
|---|---|---|
| Critical | | yes |
| High | | |
| Medium | | |
| Low | | no |

- [ ] Maximum open high defects at go-live: ____
- [ ] Key journeys that must pass: ____________
- [ ] **Who signs off:** ____________
- [ ] Who arbitrates severity disagreements: ____________

Agreeing exit criteria under deadline pressure produces criteria shaped to whatever the current
state happens to be.

## 6. During the window

- [ ] Daily triage session scheduled (business lead + tester + developer)
- [ ] Retest cycle planned — enough time to verify fixes, not just find defects
- [ ] Build changes during the window are controlled and announced
- [ ] Accepted defects recorded **with their workaround and an owner**

## 7. Before sign-off

- [ ] Every criterion assessed and recorded
- [ ] Known defects being shipped are listed, with workarounds
- [ ] Workarounds handed to support as day-one operational instructions
- [ ] The signer can state what was tested and what was not

Shipping with known defects is normal. Shipping with known defects that were never written down is
how the same issue is rediscovered by a customer three weeks later.

## Sign-off

| | Name | Date | Decision |
|---|---|---|---|
| Testing complete | | | |
| Known issues accepted by | | | |
| **Go / no-go** | | | |