UAT Execution and Sign-Off

Why it matters

Well-planned scenarios still fail in badly run sessions: users follow the tester instead of doing their own work, issues get lost or mixed up with wishes, and the decision rests on impressions. The product then goes live with gaps the business never knowingly accepted.

A sign-off record protects everyone. It tells the business exactly what it accepted and which risks remain, gives the delivery team a clear end to UAT, and gives the tester a factual answer when someone later asks who decided the release was ready.

Running UAT sessions

A UAT session is a time-boxed block, often half a day, in which a group of users executes a planned set of scenarios. Before the first one, confirm the entry criteria from the UAT plan: system testing has met its exit criteria, and the environment, accounts and data are ready. An unstable build wastes the scarcest resource in UAT, the users’ time.

Every session follows the same rhythm. A short briefing covers the day’s scope, how to record results and raise issues, and who answers questions. The users then do the work themselves while the team observes and helps. A debrief confirms the results, reviews new issues and plans the next session. If a blocking defect or an environment failure stops most scenarios, suspend the session instead of letting users wait, and resume when the agreed resumption criteria are met, for example a fixed build that has passed a smoke test; the lesson on entry and exit criteria shows how to write both.

• Business users: execute the scenarios and judge whether the result supports their work.
• UAT coordinator, often the test lead: runs the schedule, the results log and the debrief.
• Tester as facilitator: observes, helps users record what they saw and reproduces issues, without taking over the keyboard.
• Product owner or business analyst, with a developer on call: answer questions on intended behaviour and fix environment problems quickly.

Logging and triaging what users find

Log every observation as an issue, in the user’s words, before deciding what it is. ISTQB calls a condition that deviates from expectation an anomaly, and the Foundation syllabus notes that a reported anomaly may turn out to be a real defect or something else, such as a change request. Record the scenario, the user, the build, what they did, expected and saw, the evidence (a screenshot or a record number) and the business impact in their words. The tester then turns each confirmed defect into a full bug report.

Triage new issues at least daily with the product owner and a business representative: in UAT, severity and priority depend on business impact, so the business must take part. Each issue gets one classification:

• Defect: the system does not meet an agreed acceptance criterion or requirement; it enters the defect lifecycle.
• Change request: the system works as agreed, but users now want something different; it goes to the backlog or change control, and the scenario is not marked failed because of it.
• Training or documentation issue: the system is right, but users could not find or understand something; it goes to the user guide or training.
• Environment or test data problem: the UAT set-up is wrong, not the product; fix it and rerun the scenario, which was blocked, not failed.
• Duplicate or question: link it to the original or close it with the answer, so the user sees what happened to it.

The decision: accepted, conditionally accepted or rejected

UAT ends with a decision by the business owner named in the UAT plan, made against the exit criteria agreed there: for example, every planned scenario executed, no open Blocker or Critical defect, and every acceptance criterion met or covered by an agreed condition. The tester supplies the evidence and a recommendation; the decision belongs to the business.

Conditional acceptance means the business accepts now, but the acceptance depends on things that must still happen. It suits open defects with a workaround and limited impact. It usually does not suit a broken critical business rule, a legal requirement, data integrity or security: those normally mean rejection until fixed.

• Accepted: every acceptance criterion is met; remaining issues are minor, recorded and planned.
• Conditionally accepted: each condition names the issue, the workaround meanwhile, the owner, the due date or target release, and who verifies closure and how.
• Rejected: the record states the criteria not met and what must happen before UAT resumes, usually a new build with the fixes, confirmation and regression testing, then the failed scenarios again.
• A conditional acceptance never becomes full acceptance by default: record when every condition is verified, and if one is missed, the business owner decides again: agree a new date or withdraw the acceptance.

Sign-off evidence: what the record contains

The sign-off record, a document or an approval in a tool, keeps the decision and the facts behind it. It contains the main items the ISTQB Foundation syllabus lists for a test completion report (a summary, an evaluation against the exit criteria, deviations from the plan, unfixed defects and remaining risks) and adds the decision. Write it so that someone who was not there understands, months later, what was accepted and why.

• Identification: system, release, the exact build accepted, the build each result came from, environment and dates.
• Coverage: scenarios planned, executed, passed, failed and blocked, traced to the acceptance criteria, and anything not tested with the reason.
• Participants: the names and roles of the users who executed the scenarios.
• Issues: open defects with severity, priority and workaround, and where change requests and training items went.
• Decision: the outcome, each condition in full, the decision maker’s name and role, the date and the approval itself.
• Evidence: links to session logs, screenshots and the issue log, with personal data redacted before sharing.

Try it: Requirements → Test Cases Try it: Images to PDF Try it: Redact PDF

Worked example: signing off an expense-claims module

This example follows a different company and release from the plan in the lesson on planning UAT. Release 2.3 of its finance system adds expense claims, and its own UAT plan has six acceptance criteria, 18 scenarios and three morning sessions (S1 to S3) with five employees, two line managers, a finance manager and two finance clerks. Its finance director decides.

In S1, UAT-07 and UAT-08 are blocked: the managers’ UAT accounts lack approval rights (ISS-03, a test data problem). With the accounts fixed, both run in S2, where UAT-08 finds ISS-06, a Critical defect: claims over 5,000 SAR skip the finance manager’s approval. Build rc3 fixes it; in S3 the scenario passes confirmation testing, and the approval and payment scenarios, which the fix could affect, pass again as regression on rc3, the build that will go live.

Nine issues in total: two defects, one change request, two training items, one data problem, two duplicates and one answered question. ISS-07 stays open: receipt photos over 5 MB are rejected although AC-2 allows up to 10 MB. Users can compress the photo, so the QA lead recommends conditional acceptance. The record is turned into a PDF and the finance director signs it.

UAT sign-off record (excerpt): expense claims 2.3
Builds: S1-S2 on 2.3.0-rc2; S3 on 2.3.0-rc3 (retest and regression)
Build for go-live: 2.3.0-rc3, UAT environment
Participants: 5 employees, 2 line managers, 1 finance manager, 2 finance clerks
Scenarios: 18 planned, 18 executed, 17 passed, 1 failed, 0 blocked

AC    Scenarios       Result   Evidence
AC-1  UAT-01..UAT-03  Met      session log S1
AC-2  UAT-04..UAT-06  Not met  UAT-06 failed, ISS-07 (Major)
AC-3  UAT-07..UAT-10  Met      ISS-06 (Critical) fixed in rc3, retest S3
AC-4  UAT-11..UAT-13  Met      session log S2
AC-5  UAT-14..UAT-16  Met      bank file totals checked, S2; regression S3
AC-6  UAT-17..UAT-18  Met      report exports, S3

Open: ISS-07 (Major) receipt photos over 5 MB rejected; workaround: compress the photo
Other issues: 1 change request to the backlog, 2 training items in the quick guide
Decision: conditionally accepted on 2026-05-07, at the end of S3
Signed: Khalid Al-Harbi, finance director
Condition: ISS-07 fixed in 2.3.1 within 2 weeks of go-live (owner: dev lead);
           verified by a finance clerk rerunning UAT-06; closure confirmed by the
           finance director

Try it: Markdown to PDF Try it: Sign PDF

Frequently asked questions

References

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
• Certified Tester Acceptance Testing (CT-AcT)ISTQB · 2019ISTQB's specialist syllabus on acceptance testing: user, contractual and regulatory acceptance testing, alpha and beta testing, and how testers work with product owners and business analysts.
• ISTQB GlossaryISTQBThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.
• ISO/IEC/IEEE 29119-3:2021 — Software and systems engineering — Software testing — Part 3: Test documentationISO/IEC/IEEE · 2021Templates and content for test documentation — test policy, strategy, plan, status and completion reports, incident reports.