How to test a government services portal

01Direct answer

02What counts as a government services portal

A government services portal here is a citizen-facing web portal run by or for a public agency, where people sign in, fill and save applications, upload documents, pay fees through a government payment service and follow case status. It covers sign-in and identity proofing, benefit claims, case records, staff admin tools and enrolment or deadline peaks. Internal caseworker systems with no public access and agency mobile apps with offline drafts are out of scope.

Adjacent product types not covered here

• patient portal: A patient portal shows a provider's health records and messages to its own patients, so record mix-ups and proxy access lead instead of benefit claims filed with stolen identities.
• identity and access management service: An identity provider issues sign-in for many relying apps, so token and session flaws lead instead of public-sector accessibility duties and enrolment-window peaks.
• e-signature service: An e-signature product records who signed which document and when, so signer identity and audit trail integrity replace benefit payments and case-status pages.

03Risk map

04Mandatory tests (8)

1. 1

   Step 1: release smoke tests

   Why:data-breach

   Done when: On the release build, a citizen signs in, starts an application, saves it and sees its case status, and sees only their own cases.

   Tool class: browser automation. Who usually runs it: QA engineer.

2. 2

   Step 2: penetration testing

   Why:data-breachfraud-abuse

   Done when: A tester signed in as one citizen cannot view another person's case or documents by changing an ID, and cannot bypass identity proofing to file a claim.

   Tool class: proxy. Who usually runs it: security specialist.

3. 3

   Step 3: end-to-end functional tests

   Why:fraud-abuse

   Done when: A claim filed with a test identity that fails proofing is held for review, and a claim under an identity already in use is flagged before payment.

   Tool class: browser automation. Who usually runs it: QA engineer.

4. 4

   Step 4: compliance checks

   Why:accessibility-liabilitydata-breach

   Done when: A reviewer holds a current accessibility conformance report and a current security authorisation for the release.

   Tool class: test management. Who usually runs it: product manager.

5. 5

   Step 5: accessibility testing

   Why:accessibility-liability

   Done when: A screen reader user and a keyboard-only user each complete an application, upload a document and read case status without help.

   Tool class: accessibility checker. Who usually runs it: accessibility specialist.

6. 6

   Step 6: security scanning

   Why:data-breach

   Done when: The scan report for the portal and its admin tools lists no open high-severity finding, and every staff account requires phishing-resistant sign-in.

   Tool class: DAST scanner. Who usually runs it: security specialist.

7. 7

   Step 7: performance and load testing

   Why:outage-under-load

   Done when: Sign-in and form submission keep working while a load test simulates the opening hours of an enrolment window.

   Tool class: load generator. Who usually runs it: QA engineer.

8. 8

   Step 8: resilience and failure testing

   Why:outage-under-load

   Done when: When the identity or case backend is slowed in a test, applicants see a queue or retry message and no submitted form is lost.

   Tool class: chaos tool. Who usually runs it: developer.

05Recommended and optional tests

• integration testsrecommended

  Becomes mandatory when a new backend is connected.

• usability testingrecommended

  Becomes mandatory when abandonment is high on the main form.

• device and browser compatibilityrecommended

  Becomes mandatory when usage data shows older devices in the user base.

• localization testingrecommended

  Becomes mandatory when a language access requirement applies.

• data integrity and migration testingrecommended

  Becomes mandatory when the portal hands data to more than one case system.

• unit testsoptional

  May help where eligibility rules change by law.

• regression suiteoptional

  May help once releases ship often.

• exploratory testingoptional

  May help where support tickets mention lost progress.

06Not needed and why

• contract tests

  Not needed: the portal is the only consumer of its backend API. Becomes recommended when several agencies consume the portal API.

• payment and money-flow testing

  Not needed: fees are handed to a separate government payment service. Becomes recommended when the portal takes card payments itself.

• analytics and event tracking tests

  Not needed: no risk above depends on analytics events. Becomes recommended when third-party analytics scripts are added to signed-in pages.

07Order of work

08Tools

Listed alphabetically inside each test type, filtered to the tests above and to the platforms of government services portal (web). Not recommendations.

09What to send to the person who will test

Send the checklist and the brief below. The printable checklist for government services portal has the same 8 items with checkboxes.

Download the checklistMarkdownCSVBrief (Markdown)

Acceptance criteria wording

A release of the government services portal is accepted when a citizen can sign in, start, save and submit an application and see its case status, and a screen reader user and a keyboard-only user can do the same without help. A citizen cannot open another person's case by changing an ID, and a claim with an identity that fails proofing or is already in use is held before payment. Sign-in and submission keep working under a simulated enrolment-window peak, with no submitted form lost when a backend slows.

Brief

# Test brief: government services portal

Product type: government services portal. Citizen-facing forms, payments and case status.
Risk map and evidence: https://howtotestaproduct.com/how-to-test/government-portal/
Printable checklist: https://howtotestaproduct.com/checklists/government-portal/

Run these 8 mandatory tests in this order. A test is done only when its done condition is true on the build you will release.

1. release smoke tests (risks: data-breach). Tool class: browser automation. Usually run by: QA engineer.
   Done when: On the release build, a citizen signs in, starts an application, saves it and sees its case status, and sees only their own cases.
2. penetration testing (risks: data-breach, fraud-abuse). Tool class: proxy. Usually run by: security specialist.
   Done when: A tester signed in as one citizen cannot view another person's case or documents by changing an ID, and cannot bypass identity proofing to file a claim.
3. end-to-end functional tests (risks: fraud-abuse). Tool class: browser automation. Usually run by: QA engineer.
   Done when: A claim filed with a test identity that fails proofing is held for review, and a claim under an identity already in use is flagged before payment.
4. compliance checks (risks: accessibility-liability, data-breach). Tool class: test management. Usually run by: product manager.
   Done when: A reviewer holds a current accessibility conformance report and a current security authorisation for the release.
5. accessibility testing (risks: accessibility-liability). Tool class: accessibility checker. Usually run by: accessibility specialist.
   Done when: A screen reader user and a keyboard-only user each complete an application, upload a document and read case status without help.
6. security scanning (risks: data-breach). Tool class: DAST scanner. Usually run by: security specialist.
   Done when: The scan report for the portal and its admin tools lists no open high-severity finding, and every staff account requires phishing-resistant sign-in.
7. performance and load testing (risks: outage-under-load). Tool class: load generator. Usually run by: QA engineer.
   Done when: Sign-in and form submission keep working while a load test simulates the opening hours of an enrolment window.
8. resilience and failure testing (risks: outage-under-load). Tool class: chaos tool. Usually run by: developer.
   Done when: When the identity or case backend is slowed in a test, applicants see a queue or retry message and no submitted form is lost.

Acceptance criteria wording:
A release of the government services portal is accepted when a citizen can sign in, start, save and submit an application and see its case status, and a screen reader user and a keyboard-only user can do the same without help. A citizen cannot open another person's case by changing an ID, and a claim with an identity that fails proofing or is already in use is held before payment. Sign-in and submission keep working under a simulated enrolment-window peak, with no submitted form lost when a backend slows.

Report back for each test: pass or fail against its done condition, the build or version tested, and the proof (screenshot, log line or report file).

Licence: CC BY 4.0.

For founders: what to forward and what to ask back. For product managers: turning this page into tickets.

10Questions about testing a government services portal

11Evidence

1. ev-0243regulatorsecondary

   Unemployment Insurance: Estimated Amount of Fraud During Pandemic Likely Between [amount] and [amount] (GAO-23-106696), U.S. Government Accountability Office

   Supports fraud-abuse for a government services portal: GAO reports large-scale fraud in online unemployment benefit claims, the abuse an application and identity proofing flow must resist.

   published 2023-09-12 · verified 2026-10-07

2. ev-0016standardprimary

   Web Content Accessibility Guidelines (WCAG) 2.2, W3C

   WCAG 2.2 is the W3C standard that accessibility law and procurement rules reference; level AA is the usual target.

   published undated · verified 2026-10-07

3. ev-0018regulatorprimary

   Fact Sheet: New Rule on the Accessibility of Web Content and Mobile Apps Provided by State and Local Governments, U.S. Department of Justice

   The 2024 ADA Title II rule requires state and local government web content and mobile apps to meet WCAG 2.1 AA.

   published undated · verified 2026-10-07

4. ev-0038regulatorprimary

   Section508.gov, U.S. General Services Administration

   Section 508 requires US federal agencies to make the information and communication technology they develop, buy or use accessible.

   published undated · verified 2026-10-07

5. ev-0037standardprimary

   NIST SP 800-63B: Digital Identity Guidelines, Authentication and Authenticator Management, National Institute of Standards and Technology

   SP 800-63B sets requirements for authenticators, multi-factor authentication, session management and throttling of guessing attempts.

   published undated · verified 2026-10-07

6. ev-0092regulatorsecondary

   The OPM Data Breach: How the Government Jeopardized Our National Security for More than a Generation, U.S. House Committee on Oversight and Government Reform

   Supports data-breach for a government services portal: the congressional report documents theft of personnel and background investigation records from a federal agency's systems.

   published 2016-09-07 · verified 2026-10-07

7. ev-0242regulatorsecondary

   Healthcare.gov: Ineffective Planning and Oversight Practices Underscore the Need for Improved Contract Management (GAO-14-694), U.S. Government Accountability Office

   Supports outage-under-load for a government services portal: GAO found the federal enrolment site launched without verification that it met performance requirements and many users could not access or use it.

   published 2014-07-30 · verified 2026-10-07

12Disclaimer

This page lists tests and risks for a product category, not for your product. Risks are attached only with the evidence shown in the Evidence section. Tools are listed alphabetically and are not recommendations. Nothing here is legal, regulatory or security advice; where a regulator or a store sets a requirement, their page is linked and takes precedence.