UAT (User Acceptance Testing)

UAT is the moment of truth in every software engagement: the business — not the vendor, not QA — tests the delivered system against its own requirements and decides whether to accept it. It is the last gate before payment, and too often the first time anyone checks whether the software actually serves the work.

What It Is

User Acceptance Testing is the formal phase in which intended users exercise a completed system against agreed acceptance criteria, in conditions resembling real operation, before sign-off. It is distinct from the vendor's own testing: system testing proves the software matches its specification; UAT proves it works for the business that paid for it. A UAT round is organised around test cases derived from requirements (ideally the BRD/SRS), executed by named business users, with every result — pass, fail, or blocked — recorded. Defects found in UAT are triaged by severity, and the decision to 'go live with known issues' is a business decision made in writing, not a technical default.

Why It Matters to You

UAT is where the commercial leverage of the entire requirements family (BRD, SRS, SOW) either pays off or evaporates. Sign-off is usually the trigger for the final milestone payment — which means the quality of your UAT determines the quality of your negotiating position. The executive failure modes are familiar: UAT compressed into three days at the end because the schedule slipped; test cases written by the vendor (marking their own homework); users clicking through happy paths only; and signature treated as a formality. A serious UAT plans for it in the SOW — duration, participants, defect severity definitions, and what happens to payment when critical defects block acceptance.

When You'll Meet It

At the end of every delivery phase before milestone payment. Insist the UAT plan is agreed when the SOW is signed, not improvised at delivery — and that your own users, with real data volumes, execute it.