A practical user acceptance test for government web applications

The practical answer to how to conduct a simple user acceptance test for a government web application is to ask representative users to complete realistic tasks in a release candidate, then compare what happened with agreed business requirements. The aim is not to certify security or accessibility. It is to decide whether the service is understandable and workable enough for people and staff to use it during normal operations.

Start with journeys rather than screens. This user acceptance testing exercise can examine applying for a service, checking a case, correcting details, and obtaining help as meaningful units rather than conducting a page-by-page tour. A short session with a handful of representative users can expose confusing labels, broken handovers, missing confirmations, and assumptions that only the delivery team understands.

This is independent reference material, not an official e-Pragati or Australian government testing protocol. It is nevertheless designed for Australian use by departments, councils, agencies, and suppliers, including teams whose users work in Canberra, Sydney, Melbourne, Brisbane, and regional Australia.

Set the scope and success rules

Write a one-page test plan before anyone opens a browser. Name the release, date, environment, facilitator, participants, critical journeys, pass threshold, and anything outside scope. Avoid turning acceptance testing into an indefinite quality assurance campaign. A useful starting point is to map each journey to the organisational capability it supports; the capability map guide explains that approach in a departmental context. Acceptance criteria should be observable, such as “the application can be submitted and a receipt is available”.

Choose participants who resemble actual users: a resident or community member, a frontline caseworker, an approver, and a support officer. Identity habits vary across Australia. Some residents use Commonwealth Digital ID or state services such as myID and Service NSW, while others rely on an agency login or an assisted process. Include alternative routes where they are legally or operationally available instead of assuming everyone owns the same digital credential.

Use synthetic personal information and a test environment isolated from production. If the service handles personal information, involve the privacy officer and check the Privacy Act 1988, the Australian Privacy Principles, and applicable state or territory privacy legislation. Accessibility conformance, security controls, performance testing, and operational readiness need separate sign-off; the Digital Service Standard and the Australian Signals Directorate’s Essential Eight are relevant where their scopes apply. In the Australian market, delivery may involve a council, a departmental team, a cloud provider, or a local software supplier, so the plan should identify who owns each support channel. If a supplier is involved, state how the UAT evidence will support contractual acceptance.

Choose representative tasks

Draft test cases as outcomes rather than button clicks. Each scenario should state its starting point, supplied information, expected result, and how the participant will know the journey is complete. Avoid internal agency terminology. Before writing scenarios, look at a public-facing service with a different audience, such as the Arushivilla public site. Its value here is comparative: a visitor should understand the purpose, navigation, and calls to action without specialist knowledge. Apply that clarity to the government journey rather than copying another organisation’s interface.

A useful set of scenarios might include:

• Complete an online application and reach a confirmation screen.
• Sign in with the participant’s usual identity route and recover access.
• Respond to a request for corrected information and see the case updated.
• Locate the status of a request, the next action, and a support contact.

Make the scenarios reflect genuine operating conditions. Residents may complete forms on a phone while travelling between work and appointments in Sydney or Melbourne, while some users in regional and remote areas encounter variable connectivity. Include a resume-after-interruption task and check whether important information survives. Where a non-digital channel remains available, ask whether staff can identify and support the same journey rather than treating an online failure as the citizen’s problem.

During drafting, have a colleague who did not build the service read every task aloud. If they need to ask what a label means, rewrite it. Keep internal reference codes out of the prompt, and provide synthetic records in the format the participant would realistically receive. This simple check often prevents the moderator from accidentally rescuing a participant during the live session.

Run short moderated sessions

Invite four to six participants and schedule 45 to 60 minutes per person. Test the same release candidate in a controlled environment, using a current Chrome, Edge, or Safari browser and the participant’s usual device where practical. Explain the test, obtain consent for notes or screen recording, and remind participants that the service is being tested rather than their performance. Provide a script for the moderator so every person receives comparable prompts.

Observe more than whether the task finishes. Record time taken, incorrect screens, requests for help, repeated backtracking, and any point where the participant relies on knowledge outside the supplied instructions. Ask the participant to think aloud, but do not explain what a button does or lead them toward the intended path. A participant who succeeds only after coaching has still supplied important usability feedback.

Keep the exercise within its purpose. User acceptance testing provides functional confidence; it does not replace code review, infrastructure assessment, or penetration testing. Teams assessing an office network can consult a penetration testing guide before introducing test accounts or access. Use least-privilege roles, synthetic records, and an agreed process for reporting accidental exposure of real information.

Record evidence and rate findings

Turn each session into a traceable evidence trail. A visual renovation walkthrough demonstrates how sequence and clear visual cues can remove uncertainty; the same principle applies when a participant cannot tell what happens after submitting a form. Capture what was expected, what occurred, and why it matters to the service outcome, then link each issue to a journey and requirement.

For every material finding, record:

• The scenario, expected result, and actual result.
• The relevant screenshot or short recording clip.
• The browser, device, environment, and build tested.
• The severity, proposed owner, and next review date.

Separate usability evidence from defects. A typo may need correction before release, while a missing confirmation could create uncertainty or delay a payment, benefit, or case decision. Use a simple severity scale: blocker prevents completion, critical risks a serious service or privacy outcome, major causes substantial error or rework, and minor adds friction without derailing the journey. Product, service, accessibility, privacy, and security owners should assess issues in their respective domains.

Hold a short triage meeting after the sessions. Agree which findings are release blockers, which can be accepted as known limitations, and which belong in the backlog. A finding without an owner, due date, or decision can still be recorded as risk, but it should not disappear between the test room and the release meeting. Keep the raw evidence separate from the final decision so that reviewers can trace the recommendation back to observed behaviour.

Approve, remediate, and retest

Conclude with a clear recommendation: approve, approve with conditions, or reject the release candidate. State the scope tested and the build tested, then explain any limitation that materially affects confidence. Do not treat a polished demonstration by the project team as user acceptance evidence. If an untested path carries significant risk, either test it before approval or record it as an accepted risk with an accountable owner.

Fix release blockers and retest the affected journey with a participant who did not take part in the original session when feasible. Repeat a small set of unchanged critical tasks to check that the correction has not created a regression. The product owner, service owner, and relevant control owners can then sign the decision against the documented criteria and release version.

Set the acceptance review now: reserve one hour for the moderated session, assign a note-taker, load the synthetic data, and give the product owner a dated go or no-go recommendation before the release meeting.