Reviewed and republished November 14, 2026. This guide replaces earlier content and has been revised for accuracy and practical use.
Quality assurance for a web application should establish whether the system supports its intended users and handles failure safely. Begin with the journeys that would harm the business or its customers if they failed. A checklist helps organize coverage; it does not replace understanding the application.
Identify the critical journeys
List the actions people rely on: signing in, submitting a request, approving work, updating a record, paying, or receiving a confirmation. For each journey, define the user role, starting data, expected outcome, and important failure cases. Separate test environments from live systems and use authorized synthetic data.
Map each requirement to a test and assign a reviewer. A successful screenshot is not enough when the underlying record, permission, or external notification may be wrong.
Cover the major risk areas
| Area | Examples to test |
|---|---|
| Permissions | Anonymous, normal user, staff, and administrator access boundaries |
| Data integrity | Required fields, validation, duplicates, concurrent edits, and audit history |
| Integrations | Timeouts, retries, duplicate messages, and partial failures |
| Usability | Keyboard navigation, labels, error messages, and mobile forms |
| Performance | Representative page and workflow response under expected demand |
| Recovery | Restart behavior, backup restoration procedure, and operational alerts |
Test negative and interrupted paths
- Submit incomplete or invalid information and check the error guidance.
- Repeat a submission and verify that it does not create unintended duplicates.
- Expire a session during a workflow and check the recovery path.
- Interrupt a network request and reconcile the visible status with the stored result.
- Try access using a role that should not be allowed and confirm server-side enforcement.
Handle sensitive workflows carefully
Use official sandbox or test modes for payment and messaging integrations where available. Do not trigger real charges, customer communications, or irreversible production changes as an incidental test. Prepare a specific approved live verification plan when a production-only behavior must be checked.
Security testing requires an authorized scope and suitable expertise. This functional QA checklist does not constitute a penetration test or a compliance certification. Refer to an established testing guide when planning those specialist checks.
Record useful defect evidence
A defect report should contain the environment, build, role, prerequisites, reproducible steps, expected result, observed result, and business impact. Attach sanitized evidence and avoid recording passwords, tokens, or private customer data. Retest the correction and nearby behavior that may have changed.
Automate stable, important checks when they provide repeatable value. Keep exploratory and user acceptance testing for questions that require judgment. More automated tests do not automatically mean the right risks are covered.
Agree the release decision
Summarize pass results, open defects, known limitations, rollback readiness, and business acceptance. A named owner should decide whether the remaining risks are acceptable. After release, verify the critical journeys and monitoring in the intended environment.
Read the business user acceptance checklist and the requirements template, or explore software delivery services.