Acceptance & Test Support for State and Local Government

What this covers

Acceptance testing is where the agency confirms that a system works for its staff and residents before paying for it. HQT plans and runs acceptance testing, builds automated regression suites, and helps agencies define objective acceptance criteria.

Typical activities

Acceptance criteria tied to requirements
Test plans, cases, and data
Test execution with agency staff, including usability sessions
Automated regression testing for systems that will change over time
Performance and load testing for public-facing services
Defect tracking and retest management

What you receive

Test plans and cases, execution records, automated suites, and an acceptance report.

Why it matters

Testing is often compressed at the end of a project when schedules slip. Planning it early protects the agency's leverage and its go-live date.

Signals that acceptance will be contested

The terms that govern acceptance are usually fixed long before anyone writes a test case. These signs show up early:

The contract says the system will be accepted when it performs in accordance with the specifications, and no test cases are attached.
The vendor's test plan is a bar on the schedule rather than a document with cases, data, and expected results.
The staff who know the work carry full caseloads, and no backfill is arranged for the weeks they will be testing.
The test environment is an old copy of production, or someone has proposed testing in production.
A legacy data conversion is planned and nobody has written down how converted records will be reconciled against the source.
Each vendor release fixes one thing and breaks another, and nobody can show which.

Where several of these hold, acceptance will rest on the vendor's assurance rather than on evidence.

What makes an acceptance criterion objective

A criterion is usable when it names the condition to be met, the method of verification, the evidence to be retained, and who decides. Severity definitions and cure periods belong in writing before execution starts, so an argument about whether a defect blocks go-live is settled by the contract instead of negotiated under schedule pressure. The people exercising the system should be the ones who will use it daily, including staff who work with assistive technology.

The failure modes are recognizable:

Results are reported as a single pass rate, with no view of which requirements the failures touch.
Testers work from the vendor's demonstration script, which exercises the paths the vendor already knows work.
Defects are closed as working as designed, or moved to a post go-live list that never gets shorter.
Load behavior is first observed by the public on the first busy morning after launch.
Accessibility is checked with an automated scanner alone. Scanners find some issues. They do not show that a screen reader user can finish an application.

Terms to settle before award

Acceptance criteria attached to each deliverable, with a statement that accepting one deliverable is not acceptance of the system.
Severity definitions, a cure period for each severity, and the defect thresholds that must be met before go-live and before final acceptance.
A payment structure that leaves a meaningful share unearned until acceptance and releases it against test evidence.
Vendor obligations for the test environment: configuration that mirrors production, a refresh cadence, and named support during test windows.
Test scripts, test data, and automated assets delivered in a form the agency can keep and rerun, under license terms that survive the contract.
The agency's right to retest after any fix and to rerun regression after any release, including releases on the vendor's own cadence.
Performance criteria the agency sets: concurrent users and response times for named transactions, verified before go-live.
Accessibility evidence tied to the standard that applies to the agency, commonly a version of WCAG at Level AA, and produced with assistive technology rather than a scanner report alone.
Interface testing with each named third party, since those partners usually sit outside the vendor's contract.

Where a test environment would hold copies of real records, state how the data will be masked or synthesized. Handling obligations follow the data into test, including the FBI CJIS Security Policy for criminal justice information, IRS Publication 1075 for federal tax information, HIPAA for protected health information, and FERPA for student education records.

Reading the result after go-live

Escaped defects. Problems that surfaced in the first weeks that a test case should have caught, grouped by the function they came from.
Unplanned work. Help desk volume by transaction type, and fixes pushed outside the normal release process.
Time to accept the next release. A regression run and a decision in days rather than weeks means the suite is worth maintaining.
Workarounds. Shadow spreadsheets still in use months later mean a requirement was accepted on paper and not in practice.

Working with HQT on this

HQT scopes this kind of work as a fixed-price or time-and-materials engagement with a written statement of work, named staff, and a defined acceptance process. We are candid about what we can take on and prefer a well-run project to an oversized one. Contact us to discuss a requirement, a draft scope, or an upcoming solicitation.

Frequently asked questions

What is the difference between user acceptance testing and independent verification and validation?

User acceptance testing is the agency deciding whether the system supports its work before it accepts and pays. Independent verification and validation is a separate assessment of both the product and the process that runs alongside the project and reports to the agency rather than to the project team. Some federally funded programs require independent verification and validation as a condition of funding, and acceptance testing alone does not satisfy that requirement. Keeping the two in different hands preserves the independence that makes the assessment useful.

Should the system vendor run acceptance testing, or should the agency?

The vendor should test its own product, and the agency should verify separately using its own cases. A vendor's plan covers the paths the vendor designed, while agency testing exercises real workloads, the exceptions that come out of actual casework, and the handoffs to other systems. Keeping the execution records under agency control also matters if a payment or go-live decision is later contested.

How much agency staff time does user acceptance testing require?

It varies with the size of the system, but plan on named staff for full days across several weeks rather than hours squeezed around a caseload. Budget backfill or overtime, and name alternates so one absence does not stall a test window. Testing that depends on staff volunteering after hours tends to produce shallow coverage and late defect reports, which is a common reason schedules slip at the end.

Can we use production data in a test environment?

Usually not without treatment first. Copies of criminal justice, tax, health, student, or benefits records carry their handling obligations into the test environment, including the FBI CJIS Security Policy, IRS Publication 1075, HIPAA, and FERPA where each applies. The common approach is masked or synthetic data that preserves the volume and shape of the real caseload, with a documented process and the data owner's approval before any refresh.

Is automated regression testing worth it for a system we buy rather than build?

It usually is when the product will keep changing, which is the norm for cloud and software as a service systems that release on the vendor's schedule. A suite covering the transactions the agency depends on turns each release from a scramble into a routine check with evidence behind it. Settle before award who owns the automated assets and where they run, since scripts that live only in a vendor tenant are hard to retain at the end of a contract.

Acceptance & Test Support