Acceptance testing is supposed to be the moment an Australian government agency confirms that what a vendor has built actually matches what was agreed. It sits between delivery and go-live, and its outcome determines whether the project moves forward, pauses, or triggers a dispute. In practice, acceptance testing on government IT projects is treated as a formality far more often than a genuine quality gate.
What acceptance testing is meant to do
Formal acceptance testing gives the agency a structured basis for either accepting a system into operations or rejecting it and invoking contractual remedies. It's distinct from user acceptance testing (UAT) as typically run in commercial software projects. In government, acceptance testing often has contractual weight. A signed acceptance certificate can limit the agency's ability to claim defects later, making the quality of the testing itself a significant legal consideration.
The Commonwealth Procurement Rules and most state equivalents require that contracts specify acceptance criteria before work begins. The theory is that both parties enter the engagement with a shared, measurable definition of done. Reality is more complicated. Acceptance criteria in government IT contracts are frequently written at a level of abstraction that makes them nearly impossible to test objectively. "The system shall support concurrent users" is a criteria. "The system shall support 1,500 concurrent users with a median response time under two seconds at the 95th percentile" is a testable one. Government contracts contain far more of the former than the latter.
Where the problems start: criteria written after the contract
One of the most consistent failure patterns is that detailed acceptance criteria get negotiated during the project rather than embedded in the original contract. By the time acceptance testing arrives, both the agency and the vendor have invested heavily in the engagement. Neither side wants a failed acceptance to trigger formal dispute mechanisms. The result is criteria drift: test scripts are written around what the system actually does, rather than what it was supposed to do.
Project managers under schedule pressure compound the problem. Acceptance testing gets compressed when delivery runs late. A phase planned for six weeks becomes three. Testers work through a subset of scenarios. Defects get classified as minor to avoid delaying sign-off. This pattern shows up in post-implementation reviews across federal and state projects, and it's directly connected to the operational problems that emerge six to twelve months after go-live.
Agencies that handle IT project sign-off gates well tend to separate acceptance testing from project closure pressure. The gate is a genuine hold point, not a rubber stamp, and the people signing acceptance documents have read the test results rather than simply trusting a summary from the project team.
The independence problem
Acceptance testing on government IT projects is frequently run by the same team that built the system, or by testers who report to the vendor. This is a governance failure, not a resource constraint. Independent testing is more expensive in the short term. It consistently catches more defects before go-live and reduces operational incidents in the first year of service.
Some larger agencies, particularly within Services Australia and the ATO, have moved toward independent verification and validation (IV&V) arrangements where an organisation with no delivery stake assesses whether acceptance criteria have been met. This approach is still the exception rather than the rule across Australian government IT. Smaller agencies running projects under $20 million rarely have the procurement capability or budget to establish genuine independence.
The steering committee plays a critical role here. When steering committees ask hard questions about who ran the tests and what independence means in practice, acceptance quality improves. When they accept a one-page summary from the project manager, the testing process becomes largely performative.
Non-functional requirements: the most neglected category
Functional testing, checking whether the system does what it's supposed to do, gets most of the attention in government acceptance processes. Non-functional requirements get far less scrutiny, and that's where most post-go-live crises originate.
Performance under load is the most obvious gap. Government digital services often face unpredictable traffic spikes. A welfare payments portal, a tax lodgement system, or a state licensing platform can receive ten times normal traffic on a single day. Acceptance testing that doesn't simulate peak load tells the agency almost nothing useful about whether the system will hold up when it matters. The ATO's online services, for example, experience pronounced spikes around lodgement deadlines. Systems accepted without load testing against those peaks have caused outages that made national news.
Security acceptance testing is the second major gap. Many government IT contracts include a clause requiring a penetration test before go-live, but the scope of that test is often too narrow. Testing the web application layer without testing the supporting infrastructure, APIs, and integration points leaves genuine risk undetected. Agencies operating under the Essential Eight maturity model should be verifying that a delivered system meets the required maturity level as part of acceptance, not as a separate post-launch activity.
Accessibility and compliance testing
Australian government websites and digital services must comply with the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA, as set out by the Digital Transformation Agency. Accessibility testing should be a mandatory acceptance criterion for any public-facing system. In practice, it's tested superficially, automated against a checklist rather than validated with assistive technology and real users.
The DTA publishes guidance on accessibility requirements, but enforcement at project level depends on whether the agency has embedded accessibility into its acceptance criteria from the start. Projects that treat accessibility as a late-stage compliance check rather than a design requirement almost always find defects too late to fix properly before go-live.
Data migration acceptance: a category of its own
When a new system replaces a legacy one, data migration is often the highest-risk element of the project. Acceptance testing for data migration needs its own framework, separate from functional testing of the new system. Agencies need to verify that migrated data is complete, accurate, and correctly mapped to the new schema. They need to confirm that business rules applied during migration haven't introduced systematic errors.
The practical challenge is that data migration acceptance requires the agency to have a clear picture of what the source data looked like and what the target state should be. Many agencies don't have adequate data dictionaries for their legacy systems. Migration acceptance testing then becomes a sampling exercise, which creates genuine risk that systematic errors in low-frequency data categories go undetected until they cause a problem in production.
What good looks like
Agencies that handle acceptance testing well share a few consistent practices. They write testable acceptance criteria during procurement, not during delivery. They appoint an independent test manager who reports to the project board rather than the delivery team. They treat non-functional requirements, including performance, security, and accessibility, as first-class acceptance criteria rather than afterthoughts.
They also build in a formal defect triage process with pre-agreed classification rules. A critical defect blocks acceptance. A major defect requires a remediation plan with a fixed date before acceptance can proceed. A minor defect gets logged and tracked post-go-live. Having that classification agreed before testing starts removes the political pressure to downgrade defect severity to hit a go-live date.
Finally, good agencies keep records. Acceptance test results, defect logs, and sign-off certificates are preserved as project artefacts. When something goes wrong six months after go-live, those records determine whether the agency has contractual recourse or is bearing the cost of a vendor's defect on its own budget.