User acceptance testing is where requirements, real workflows, accessibility, security, migration, integrations, training, support, continuity, and vendor promises either become usable evidence—or become production defects. This guide gives public-sector teams a disciplined way to plan UAT and decide whether a system is actually ready to launch.
UAT should answer whether the delivered system supports the organization’s actual work under the conditions that matter. It should not become a late-stage substitute for requirements, security engineering, accessibility conformance, data reconciliation, or disaster recovery.
Create a short UAT charter before testing begins. Identify scope, environments, test data, participant roles, entry criteria, acceptance criteria, defect severity rules, retest expectations, decision authority, and the evidence required for sign-off. Separate business acceptance from technical release approval so one signature does not silently represent every discipline.
A screen can work while the service fails. Build scenarios around what a real user is trying to accomplish and the dependencies that must cooperate.
Verify the expected end-to-end workflow with realistic roles, data, approvals, records, notifications, exports, and integrations.
Test missing data, duplicates, invalid formats, denied permissions, failed integrations, timeout behavior, rejected approvals, and interrupted work.
Test what users do after failure: resume, reconcile, retry safely, restore state, identify incomplete work, and avoid double-processing.
Capture objective, preconditions, user role, steps, expected result, observed result, evidence, defect link, tester, date, and final disposition. Where the workflow changes records or money, include reconciliation evidence rather than relying on the UI message that says “success.”
Section508.gov’s ICT Testing Baseline Portfolio describes standardized test components for evaluating Section 508 conformance and notes that the baseline is tool-agnostic. Federal procurement guidance also emphasizes validating contractor compliance after award and re-testing when products or software change.
For public-facing or employee-facing digital systems, include keyboard operation, focus order, visible focus, names and labels, error identification, forms, tables, modal behavior, zoom/reflow, color dependence, document outputs, and representative screen-reader workflows where applicable. Test the tasks users must actually complete, not only isolated pages.
Use the Accessibility Procurement Checklist to connect vendor claims, accessibility evidence, testing, remediation, and acceptance.
NIST’s SSDF provides secure-development practices for software producers, while CISA’s Secure by Demand guidance helps buyers ask for security outcomes. UAT should confirm the buyer-side configuration and operational controls that matter at launch.
Do not ask ordinary business UAT participants to perform penetration testing. Instead, make security assessment evidence a release input and use focused UAT checks to confirm the configured controls that users and administrators can observe.
A migration can copy the expected number of rows and still fail operationally. Validate identifiers, relationships, attachments, metadata, timestamps, status values, permissions, retention flags, searchable fields, historical context, and reports that depend on transformed data.
Build a reconciliation set before cutover. Include known edge cases and records important enough to inspect manually. Define acceptable variance and who can approve it. If legacy and new systems must coexist, test the synchronization or handoff rules and define the source of truth during transition.
The Public-Sector Software Migration Readiness checklist expands this into data, file, relationship, access, integration, cutover, rollback, and recovery checks.
A production cutover is a coordinated operational event, not merely a deployment command. Rehearse the sequence with the same roles that will participate in the actual launch: business owner, technical lead, vendor, identity administrator, integration owner, service desk, communications owner, data or migration lead, and the person authorized to stop or roll back the release. The rehearsal should expose unclear handoffs, missing credentials, unavailable approvers, unrealistic timing, and dependencies that UAT did not reveal.
Write the cutover runbook around decisions as well as actions. Each major step should identify the expected evidence, the time or condition at which the team proceeds, the condition that requires escalation, and the point beyond which rollback becomes more complex. For a migration-heavy release, include reconciliation checkpoints before users are allowed to create new production records. For integrated services, include explicit confirmation that upstream and downstream systems are processing the new traffic correctly.
Define rollback before launch begins. A useful rollback criterion is observable and tied to impact: unresolved data corruption, authentication failure for a critical user population, duplicate financial or case transactions, inability to complete a mission-essential workflow, failed migration reconciliation beyond the accepted threshold, or an integration failure that creates unsafe manual work. “We will decide if it looks bad” is not a rollback plan because it forces the highest-pressure decision to be invented during the incident.
Plan the first production hours as part of readiness. Establish heightened monitoring, named support coverage, vendor escalation contacts, a defect triage channel, rapid access to logs and audit events, and a cadence for reviewing user-impact signals. Capture production findings against the exact release version and feed them back into future UAT cases. A strong launch process does not assume testing eliminated defects; it assumes the organization can detect, contain, explain, and recover from the defects that remain.
NIST SP 800-34 Rev. 1 remains useful for contingency-planning fundamentals: recovery requirements should connect to business impact and the system lifecycle. Even when a modern cloud service changes the technical recovery mechanism, the organization still needs to know what it will do if the launch fails.
The release record should identify the production version, approval date, decision authority, completed evidence, unresolved defects, accepted risks, migration reconciliation, rollback criteria, heightened monitoring period, and owners for post-launch issues. This creates a useful baseline for audit, vendor management, later upgrades, incident response, and lessons learned.
After launch, review actual defects and support demand against UAT results. If an issue reached production because the scenario was never tested, add that class of failure to future acceptance packs. If it was tested but accepted, revisit the severity and decision rule. The goal is a testing system that gets better with each release.
Use the source-backed research to pressure-test assumptions, then build a reusable evaluation brief before you compare products, scope implementation, or request a fit review.