# 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.