User Acceptance Testing (UAT) Checklist Template

What the User Acceptance Testing (UAT) Checklist Covers

1. 1
   Phase 1

   Phase 1: Scope, Roles & Entry Criteria

   6 tasks

   The first task records the system, the planned go-live date, who signs off and who delivered the system. Choosing a vendor or supplier adds the contract tasks in Phases 1 and 6.

   • Record the system, the planned go-live date and who signs off — the business owner accepts or rejects the system; the UAT lead runs the round day to day
   • Define what this UAT round covers — the business processes, user roles, interfaces and reports in scope, and what is out of scope
   • Vendor-delivered: check the contract’s acceptance terms — the acceptance criteria, the testing period, how defects are classed and what happens if the business does not respond in time
   • Check where system testing stands — the delivery team’s progress, open defects by severity and known issues, so the UAT dates are realistic
   • Agree the UAT entry criteria — the conditions that must be true before business testers start, each with the evidence that will show it
   • Set the UAT timetable — kickoff, the execution window, the retest window, the sign-off date and go-live
2. 2
   Phase 2

   Phase 2: Business Testers & Acceptance Criteria

   6 tasks

   UAT is run by the people who will use the system. The acceptance criteria come from the requirements or user stories, and the business owner approves them before any script is written.

   • Choose the business testers for each role — people who do the work today, from every team and role that will use the system
   • Agree the testers’ time with their managers — testing days blocked out in diaries, with cover arranged for their normal work
   • Collect the requirements or user stories to test against — signed-off requirements, user stories with their acceptance criteria, process maps and any policy rules the system must follow
   • Write the acceptance criteria in business terms — one or more per requirement, each one testable as pass or fail
   • Agree the defect severity levels and what blocks acceptance — which severities stop the sign-off and which can be accepted with a workaround and a fix date
   • Approve the acceptance criteria with the business owner — before scripts are written, so the target does not move during testing
3. 3
   Phase 3

   Phase 3: Scenarios, Scripts & UAT Environment

   6 tasks

   Scripts are written in the language of the business, by or with the people who will run them. The environment and data should look like the work the testers know.

   • Write test scenarios from real business processes — end-to-end journeys from the first step to the last, including exceptions and period-end work
   • Write step-by-step scripts in business language — what to do, the data to use and the expected result for each step, with no technical jargon
   • Map every acceptance criterion to at least one scenario — a criterion with no scenario is a criterion nobody will test
   • Prepare test data that looks like real work — realistic records for each scenario, masked or synthetic, never raw personal data copied from production
   • Set up the UAT environment and check it works — a stable build separate from development, with interfaces, reports and emails behaving as they will in production
   • Give every tester access with their real role — test each login and each role’s permissions before kickoff, not on the first morning
4. 4
   Phase 4

   Phase 4: Tester Training & Kickoff

   4 tasks

   A short kickoff saves days of questions. Testers learn the system, the scripts and how to raise a defect, and the entry criteria are checked before execution starts.

   • Train testers on the system and on how to test — the screens they will use, how to follow a script, record evidence and raise a defect
   • Hold the UAT kickoff — scope, timetable, roles, the daily stand-up time and where to ask questions
   • Confirm the entry criteria are met before execution starts — each criterion met, or a written decision by the business owner to start anyway
   • Assign scenarios to testers — each scenario has one tester and a target date inside the execution window
5. 5
   Phase 5

   Phase 5: Execution, Defects & Daily Status

   7 tasks

   Every script run is recorded with its result and evidence. Defects go to the delivery team the same day, and the UAT lead reports status every day of the execution window.

   • Run the scripts and record pass or fail for each step — with screenshots or documents as evidence for every failed step and the key results
   • Log each defect with the steps to reproduce — the scenario, expected and actual result, screenshots and the tester’s view of severity
   • Triage defects daily with the delivery team — confirm severity, separate defects from change requests and training issues, and agree a fix date
   • Record change requests separately — a request for something the requirements did not ask for is a change, not a defect, and goes to the change process
   • Retest each fix with the original script — by the tester who found the defect where possible, on the build that contains the fix
   • Re-run the scenarios around each fix — a fix in one step can break the next step of the same process
   • Send a daily status report — scripts passed, failed and not yet run, open defects by severity and any risk to the sign-off date
6. 6
   Phase 6

   Phase 6: Exit Criteria & Business Sign-Off

   5 tasks

   The business owner records Accepted, Accepted with conditions or Rejected on the fourth task, and the checklist halts there until they do. A rejected sign-off adds the fix and retest round in Phase 7.

   • Assess the results against the exit criteria — every script run, every acceptance criterion passed or covered by an agreed workaround, and no open defect that blocks sign-off
   • List the open defects and workarounds the business is asked to accept — each with its severity, the workaround users will follow and a fix date
   • Write the UAT summary report — scope, testers, scripts run and passed, defects by severity, open issues and the UAT lead’s recommendation
   • Record the business sign-off — Accepted, Accepted with conditions or Rejected, with the reason and any conditions
   • Vendor-delivered: send the vendor the written decision — acceptance, acceptance with conditions, or rejection with the defect list, within the period the contract sets
7. 7
   Phase 7 — If Rejected

   Phase 7: Fix & Retest Round

   5 tasks

   Shown only when the business owner rejects the system. Move the planned go-live date on the first task to the new date, and these due dates count back from it.

   • Agree the defects to fix and a new sign-off date — with the business owner and the delivery lead; every defect that blocked sign-off is on the list
   • Confirm the fixes are delivered and tested by the delivery team — a new build in UAT with release notes that list each fix
   • Retest every failed scenario on the new build — with the original scripts, recording the result and evidence again
   • Re-run the critical end-to-end scenarios — so the fixes have not broken the main business processes
   • Record the second business sign-off — Accepted, Accepted with conditions or Rejected; a second rejection goes to the project sponsor
8. 8
   Phase 8

   Phase 8: Handover & Lessons Learned

   6 tasks

   Acceptance is handed to the people who release and support the system, with its conditions and known issues attached. The round ends by improving the next one.

   • Hand the sign-off to the release manager — the decision, the conditions and the known issues go into the go-live decision and the release notes
   • Brief support and trainers on known issues and workarounds — so the service desk and end-user training match what was accepted
   • Archive the UAT evidence — scripts, results, the defect log, the summary report and the sign-off, kept with the project record
   • Hold a lessons-learned review with testers and the delivery team — what slowed testing, which defects should have been found earlier and what to change next round
   • Keep the scripts for the next release — update them for what changed, so the next UAT round or the regression pack starts from them
   • Track each condition of acceptance to closure — every condition and accepted defect has an owner and a date, and is checked after go-live