In short
Before launch, a web app should test core business rules, permissions, data integrity, integrations, critical end-to-end journeys, validation and recovery, accessibility, security boundaries, representative performance, browser and device support, deployment, backups, analytics, and monitoring. Depth should follow the consequence of failure.
Build the plan from failure consequence
List critical journeys and ask what happens if each returns the wrong result, exposes data, charges twice, loses work, or becomes unavailable.
| Risk | Strong test focus |
|---|---|
| Business-rule error | Unit and integration tests around the rule |
| Permission failure | Role matrix, negative cases, server enforcement |
| Broken user journey | End-to-end test and manual exploration |
| Third-party failure | Contract tests, timeouts, retry, fallback |
| Data loss | Transaction, backup, restore, migration tests |
Essential layers
Business rules
Automate pricing, eligibility, status transitions, calculations, and permissions. Include boundaries and invalid states.
Data and migrations
Test required fields, uniqueness, transactions, concurrency, imports, exports, retention, and rollback. Run migrations against production-like data volume.
Authentication and authorization
Test invitation, login, recovery, session expiry, role changes, revoked access, tenant separation, and server-side enforcement.
Integrations
Test correct payloads plus timeouts, duplicates, rate limits, expired credentials, partial responses, and unavailable services.
Critical end-to-end journeys
Cover a small set of complete user outcomes across interface, API, data, notifications, and analytics. Keep them stable and valuable rather than automating every visual path.
Accessibility
Use automated checks and manual keyboard, focus, label, error, contrast, zoom, responsive, and representative assistive-technology testing.
Security
Review threat boundaries, inputs, secrets, dependencies, authorization, logging, data exposure, and abuse. High-consequence systems need qualified security assessment.
Performance and reliability
Test representative loads, slow dependencies, large data, important pages, queues, caching, and recovery. Do not extrapolate from an empty development database.
Deployment and operations
Verify configuration, migrations, rollback, backups, restore, alert routing, logs, dashboards, support, and incident ownership.
The launch smoke test
Immediately after production deployment, test login, permissions, priority workflow, form or transaction, email delivery, analytics, integrations, and monitoring. Confirm staging controls and production indexation where relevant.
Common questions
Does every feature need automated tests?
No. Automate stable, consequential rules and journeys where repeatability provides confidence. Use manual exploration for new interaction and unusual states.
Are end-to-end tests enough?
No. They are slower and less precise at locating failures. Combine focused rule tests, integration tests, and a small end-to-end set.
Who should test the app?
Engineers, designers, product owners, domain experts, accessibility specialists, security reviewers, and representative users contribute different evidence.
Can testing happen only before launch?
No. Test throughout delivery, then continue with production monitoring, regression tests, incident learning, and release checks.
What is the minimum for an MVP?
Protect the core value path, user data, permissions, recovery, measurement, and operational support. Minimum scope does not mean minimum safety.
