uat_acceptance_testing v1.0.0

name: "uat_acceptance_testing" description: "Run user acceptance testing that ends in a defensible sign-off: traceability matrix linking requirements to acceptance criteria and scenarios, a UAT plan with entry and exit criteria, defect triage with business testers, and an evidence-backed close-out. Use when planning or running a UAT round, preparing a release for business acceptance, auditing coverage before sign-off, or recording a go or no-go decision."

UAT Acceptance Testing

Purpose

Run acceptance testing as a business decision, not a bug hunt. The business confirms, in its own workflows and words, that the system satisfies the agreed acceptance criteria, and one named approver accepts or rejects a specific build on recorded evidence. Everything in this skill exists to make that decision defensible six months later to someone who was not in the room.

ISTQB defines acceptance testing as formal testing with respect to user needs, requirements, and business processes, conducted to determine whether a system satisfies the acceptance criteria and to enable the user, customer, or other authorized entity to determine whether to accept the system.

Workflow

1. Lock the basis before anyone tests. Collect the approved requirements, user stories, contracts, and business process docs that the release claims to satisfy. Freeze a build candidate and record its exact version. If the basis is still changing daily, say so and do not open UAT: you would be signing off a moving target.

1. Build the traceability matrix first. Give every requirement a stable ID that never changes when a sheet is sorted. Link each requirement forward to its acceptance criteria, then to one or more UAT scenarios, then to a result and evidence. Link backwards to source. Run the gap checks in references/traceability-matrix.md and clear orphans before the round starts. Use bin/uat_check.py on the exported CSV to get the gap list in seconds.

1. Write acceptance criteria a business tester can judge. Prefer Given-When-Then for workflow behaviour: Given the starting context, When the action happens, Then the observable outcome. Use short rule statements for validations, permissions, calculations, and non-functional requirements. Each criterion gets one pass or fail answer. Cut any criterion a tester cannot judge without asking a developer what it means.

1. Write the UAT plan and agree exit criteria before testing starts. Use templates/uat-plan.md. Name the scope in and out, the environment and data, the roles and testers, the schedule, the defect process, and one sign-off authority with a named stand-in. Entry and exit criteria are checklists, not feelings. If exit criteria are negotiated after results arrive, the round has already failed as a decision process.

1. Brief testers and run scenarios as real work. Testers are people who do the job, testing as the role they hold, on production-like data with personal details masked. Scenarios follow end to end business processes, not screen tours, and include unhappy paths: refused permission, cancellation, wrong entry, empty state, duplicate submission. Testers record pass, fail, or blocked per scenario plus evidence. A pass with no evidence does not count at sign-off.

1. Triage defects daily with the business in the room. Follow references/defect-triage.md. Separate severity (business impact if it happens) from priority (when it gets fixed relative to other work). Every report gets a disposition the same day it is triaged: fix now, fix later with a date, clarify requirement, adjust data or training, accept a workaround, defer with approver agreement, or close as expected behaviour. The reporter retests each fix on the build that will ship, plus the neighbouring scenarios the fix could have broken.

1. Close out against the exit criteria, item by item. Fill templates/sign-off-record.md from the matrix and the defect log, not from memory. Report scenarios planned, run, passed, failed, and blocked, coverage per requirement, and every open defect with its accepted decision, owner, workaround, and due date. The approver records one of three decisions: accepted, accepted with conditions, or not accepted. Store the signed record, the final matrix, and the evidence folder link with the release.

Output Contract

A completed UAT round delivers all six, in this order:

1. UAT plan using templates/uat-plan.md, with entry criteria checked and dated before the first scenario runs.
2. Traceability matrix in the columns defined in references/traceability-matrix.md, with zero unexplained gaps: every in-scope requirement has at least one scenario, every scenario has a result, every failed result links to a defect or an accepted decision.
3. Scenario results sheet with one row per scenario: ID, role, result, tester, date, build, and evidence link.
4. Defect log with triage decisions, each entry carrying severity, priority, disposition, owner, due date, retest result, and the approver for any acceptance or deferral.
5. Exit criteria scorecard: each criterion marked met or not met, with the number or link that proves it.
6. Sign-off record using templates/sign-off-record.md, signed by the one named approver for the exact build tested.

If any item is missing, the round is in progress, not complete. Never describe it as signed off.

Operating Rules

1. One approver, and never the builder. The approver is accountable for the business outcome the system supports. QA and the delivery team present evidence. They do not accept their own work. Committees recommend, one name signs, and a stand-in with the same authority is named before the round starts.

1. Exit criteria are agreed before entry. Common floor: all must-have scenarios executed, no open Critical defects, no open High defects without a workaround the approver has accepted in writing, every fixed defect retested, every open defect listed with owner and date. A team may set a stricter floor. It may not loosen the floor mid-round without recording who agreed and why.

1. UAT is not system testing. Testers judge business outcomes: the invoice total matches the order, the approval is logged, the vendor got the notice. They do not judge status codes or database state. If a scenario needs technical inspection, route it to system testing and keep the business scenario on the outcome the business can see.

1. Severity and priority never collapse into one field. A critical defect in a deprecated flow used by almost nobody may be low priority. A cosmetic defect on a page that will appear in a launch screenshot may be high priority. Record both, with the reason when they disagree.

1. Not every UAT report is a defect. Classify the source first: product defect, configuration, data, permissions, integration, requirement ambiguity, or training. A requirement gap is a change decision with a cost and an owner, not a bug fix promise made in a triage call.

1. Evidence beats recollection. Name evidence files with scenario ID, step, result, and date. Screenshots or short recordings plus the build version and test account role are enough for most steps. A defect report without steps, expected result, actual result, and evidence goes back to the reporter the same day, with help to complete it, not into the backlog as a guess.

1. Fixes reopen the neighbours. Every fix gets a retest of the original scenario and a short risk-based pass over adjacent scenarios that share the changed code, data, or integration. Log the regression rows in the matrix so coverage after fixes is visible, not assumed.

1. Conditional acceptance is a list, not a mood. Accepted with conditions means each condition is written, owned, and dated, and the record states what happens if a condition slips. If a condition blocks safe live use, the honest decision is not accepted.