THE SHORT ANSWER
Test the most important user journeys end to end, then vary inputs, identity, device, browser and failure conditions. Cover functional behavior, usability, forms, payments, permissions, accessibility, performance, security, analytics and operational recovery. Record expected results and decide which failures block launch.
Prioritize tests by harm and likelihood
Begin with journeys that create commitments, handle sensitive information, move money or change permissions. Test the ordinary route and the failures that could leave a person uncertain, charged twice, locked out or exposed to another user's data.
| Journey | Happy path | Important edge or failure |
|---|---|---|
| Registration | Valid details create one record | Repeated submission does not duplicate it |
| Payment | Captured payment confirms the order | Delayed callback reconciles safely |
| Account | Correct user can sign in | Expired session cannot perform a protected action |
| Form | Valid values submit | Invalid, missing and unusually long values are handled |
Cover the product, not only the screen
- Core tasks and navigation
- Usability with representative users
- Responsive layouts, browsers and device input
- Forms, validation and error recovery
- Payments, refunds and duplicate events where applicable
- Authentication, authorization and privacy
- Keyboard use, focus, labels, contrast and zoom
- Performance under realistic conditions
- Analytics and monitoring signals
- Backup, rollback and support procedures
Evidence & context: W3C Web Accessibility Initiative · NIST
Write expected results before declaring success
For each critical test, record the starting state, action, expected result, actual result and evidence. Include the database or provider state when an interface message alone cannot prove the outcome.
Evidence & context: GOV.UK Service Manual
Retest changed and connected behavior
A fix can affect neighboring journeys. Retest the defect, its main integration points and a small set of established critical journeys. Automate stable, repeated checks where that meaningfully reduces release risk, while retaining human usability and exploratory testing.
Once launch criteria pass, move to launch and continuous improvement.
Sources & further reading
- Quality assurance: testing your service regularly
GOV.UK Service Manual. Government guidance on usability, functional, performance, security, accessibility and continuous testing. It does not prescribe one universal test suite.
- Easy Checks — A First Review of Web Accessibility
W3C Web Accessibility Initiative. A first-pass accessibility review covering titles, headings, contrast, keyboard focus, labels and zoom. Passing these checks is not comprehensive conformance testing.
- Secure Software Development Framework
NIST. Outcome-based secure-development guidance covering preparation, protection, secure production and vulnerability response. It is a framework, not a product-specific checklist.
Examples and exercises are illustrative unless attributed to a source. No independent expert review is claimed.
A correction, a counterexample or an experience worth sharing?
Join the conversation ↗