How to run web-app acceptance testing before launch

Test the release that was agreed

Begin with the approved first-release journeys and acceptance criteria. A test such as “a coordinator can create a request” is too loose: it does not say which information exists, what confirmation appears or where the saved record can be found. Rewrite it as an observable outcome. For example, “Given a valid customer and an empty request list, a coordinator can save a request and see its reference, status and creation time in the list.”

Acceptance testing should not reopen the whole product plan. Record attractive new ideas separately and judge this release against its agreed scope. If an essential journey has no acceptance criterion, pause approval and clarify the expected outcome. Link each test to the relevant criterion so a product owner can see which commitments have evidence and which remain untested.

Use a journey-based acceptance-test template

Create one row for one meaningful behavior, not one row for every click. Give it a stable identifier so defects, evidence and retests refer to the same test. Use realistic but clearly marked test records. Preconditions should state the role, account state, existing records and device or browser conditions needed before the first step.

Copy the fields below into a shared sheet or test tool. The expected result should cover both what the user sees and what the business must retain. Evidence can be a screenshot, saved record identifier or short screen recording, provided it contains no unnecessary personal information. A pass means the observed result matches the written expectation; “looked fine” is not a repeatable decision.

• Test ID and journey: a stable reference and the business task being checked.
• Preconditions and role: required records, permissions, feature state and starting page.
• Steps and sample data: concise actions plus labelled, non-sensitive values to enter.
• Expected result: visible confirmation, saved state, downstream effect and safe failure behavior.
• Actual result and evidence: what happened, where evidence is stored and who ran the test.
• Severity and owner: business impact, responsible person and target decision or fix date.
• Retest status: build or release tested, result, date and any remaining limitation.

Cover roles, data states and failure paths

For every core journey, test the smallest useful set of roles: someone allowed to act, someone who can view but not change, and someone who must not access the record. Directly opening a copied URL is an important permission check; hiding a button does not prove that the underlying action is protected. OWASP’s testing guidance provides structured areas for checking authentication, authorization, session behavior, input handling and other web risks. Use specialist security testing where the app’s risk requires it.

Vary the record state as well as the user. Try an empty account, a normal record, a record already completed and a record changed by someone else. Check missing and invalid inputs, a double submission, a timed-out connection and a retry. The expected result may be a clear error and a preserved draft. It should never be an ambiguous success message when the required record was not saved.

Hypothetical example: accepting a service-request journey

Consider a hypothetical maintenance-request app. The agreed journey lets a customer contact create a request with a site, category and description; a coordinator then assigns it. The main test starts with an active customer account and no open requests. It confirms that one saved record appears to both permitted roles with the same reference and that a read-only finance user cannot edit it.

Related tests use a closed customer account, omit the category, submit twice and interrupt the network response. The team finds that an uncertain retry creates two requests, marks the defect high severity because it can cause duplicate work, and withholds acceptance for that journey. After a fix, the tester repeats the original steps on the named release and attaches the two record searches as evidence. This is a hypothetical planning example, not a Kinetivy client result.

Include accessibility checks and user evidence

Run the essential journeys using only a keyboard, at increased zoom and on a narrow screen. Check page titles, headings, visible focus, labels, errors and status updates. W3C’s Easy Checks are a useful preliminary review, but they explicitly do not cover every accessibility requirement. Treat them as a starting point and arrange a fuller assessment appropriate to the service.

Acceptance tests answer whether the built release meets explicit expectations. Research with representative users answers a different question: whether people understand the service and can use it in context. GOV.UK’s service guidance recommends starting with user needs rather than assumptions. Observe a small set of priority tasks, record where language or flow causes difficulty, and distinguish a release-blocking failure from a possible later improvement.

Triage evidence and make sign-off explicit

Define severity before testing. A critical defect may expose information or prevent all use of a core journey. A high defect blocks an important task without a safe workaround. Medium and low defects have narrower effects, but still need owners and decisions. Severity describes impact; priority describes when the team will act. Keeping them separate prevents a visually annoying issue from being confused with lost or incorrectly shared data.

Use this sign-off checklist: every core journey has a named test; required roles and important states were covered; failed tests have recorded decisions; fixes were retested on the release candidate; accessibility and representative-user evidence were reviewed; production configuration, backup and rollback owners are known; and the product owner records approval or rejection with the release identifier. Preserve the evidence after launch so a later change can reuse the tests instead of rebuilding knowledge from memory.