User acceptance testing before a government system goes live

Reference article · 5 min read

When a vendor delivers a configured system, someone at the agency has to decide whether it is fit to run the program. That decision is user acceptance testing, and it is not the vendor's job. The vendor tests that the software works the way it was designed. The agency tests whether that design does the work the agency actually has to do, using the records and exceptions that appear in a normal week at the counter.

UAT is also the last point at which the agency holds real leverage. After go-live and final payment, defects become change requests with a price attached.

What UAT covers, and what it does not

Vendors run unit, system, integration, performance, and security testing before handover. UAT answers a different question: can this office do its job in this system. Several things get folded into UAT without being planned for. Give each its own track and its own testers:

• Functional acceptance. Business processes start to finish, performed in the roles that perform them.
• Data conversion review. Sampled records and control totals compared against the legacy source.
• Interfaces. Traffic in both directions with every connected system, including failure handling.
• Roles and permissions. Each role sees and edits only what policy allows.
• Notices, forms, and reports. Anything residents, courts, or oversight bodies receive, checked against the current template.
• Accessibility. Screens checked against the standard the agency must meet. Requirements vary by jurisdiction and change, so confirm the applicable standard with counsel.

Write test scripts from business scenarios, not feature lists

A script derived from the requirements matrix confirms that a button exists. A script derived from a real case exercises the system the way work arrives. Pull scenarios from files the office handled last quarter: an application submitted incomplete, withdrawn, and resubmitted; a payment reversed after the period closed; an inspection failed twice and appealed.

Each script should state the starting condition, the role performing it, the steps, and the expected result, including what should exist afterward: the notice generated, the ledger entry posted, the audit record retained. Use de-identified historical records where policy permits, and cover month-end close and renewals, not only intake.

Staff it with the people who do the work

Recruit the clerks, inspectors, dispatchers, permit technicians, and accounting staff who will live in the system. Supervisors know the process as documented; front-line staff know it as performed.

• Name testers in writing and protect their time. Testing days are not also normal production days. Arrange backfill.
• Train before testing starts. A tester who cannot navigate the software reports confusion as defects.
• Give testers a stable environment and their own data. Shared environments produce results nobody can reproduce.
• Include the awkward roles. Part-time, field, and counter staff, and anyone using assistive technology.
• Appoint one coordinator. One person schedules sessions, reviews defect write-ups, and is the single channel to the vendor.

Track defects by severity and decide what blocks go-live

Agree on a severity scale before the first cycle and put it in the test plan:

• Critical. A statutory or core function cannot be completed and has no workaround. Always a blocker.
• High. A core function produces an incorrect result, or works only through a manual workaround that will not scale. Normally a blocker.
• Medium. Real but tolerable for a defined period. Deferred only with a named owner and a fix date.
• Low. Cosmetic or convenience issues that go to the backlog.

Expect argument over whether an item is a defect or a change request. Name a triage group with agency and vendor representation, meet on a fixed cadence, and log everything in one tracker both parties can see. Retest fixes inside a full cycle rather than in isolation, because a fix in one module often disturbs another.

Write exit criteria into the plan: no open critical defects, every high defect resolved or covered by a workaround the business owner accepted in writing, every script executed with a pass, conversion accepted, and interfaces verified both ways.

Allow enough calendar time

Plan cycles rather than a single pass. A first cycle surfaces most defects, the vendor fixes and redeploys, a second retests those fixes and the scripts around them, and a third confirms a stable build. Leave working time between cycles, and schedule around fiscal year close, elections, and seasonal peaks. If the go-live date is fixed by statute or a contract expiration, work backwards and protect the test window. Time removed from UAT reappears as post-go-live support.

Sign-off, contract terms, and what to ask the vendor

Acceptance should be a signed document, not an email thread. It should list the scripts executed and their results, open defects with severity and disposition, accepted workarounds and who accepted them, and dated signatures from the business owner and the project sponsor.

• Define acceptance in the contract. The criteria, the length of the test period, the retest cycles included, and the remedy if the system does not pass.
• Tie a payment milestone to written acceptance. A milestone or retainage that survives until sign-off keeps attention on defect resolution.
• Require a test environment refreshed with converted data. Sample data proves little.
• Set response times by severity. Critical and high defects should carry a defined turnaround.
• Read any deemed acceptance clause. Vendors often propose that a system is accepted automatically if the agency does not object within a set period. Negotiate that window and pause it while critical defects are open.
• Ask what happens after go-live. Confirm the warranty period, who fixes production defects, and at what cost.

HQT works with state and local agencies on software delivery and system implementation, including test planning and acceptance support.

Frequently asked questions