How to use this checklist
This checklist covers the core areas every web application should be tested against before release. Use it as a minimum bar — not a substitute for risk-based testing, which should be calibrated to your specific application.
1. Functional Testing
- All user-facing features work as specified
- Edge cases tested: empty inputs, maximum lengths, invalid formats
- Error messages are clear and actionable (not just "An error occurred")
- Form validation works client-side and server-side
- Multi-step flows complete correctly and handle back-navigation gracefully
- Confirmation dialogs, modals, and tooltips behave correctly
- Pagination, sorting, and filtering work correctly with varied data
2. Cross-Browser & Cross-Device Testing
- Chrome (latest), Firefox (latest), Safari (latest), Edge (latest)
- iOS Safari on iPhone (latest OS)
- Chrome on Android
- Responsive breakpoints: mobile (375px), tablet (768px), desktop (1280px), large (1920px)
- Touch interactions work correctly on mobile (tap targets ≥48px recommended)
3. Accessibility Testing
- Run automated scan with axe or RedQA's free scanner
- All images have meaningful alt text (or
alt=""for decorative images) - All form inputs have associated labels
- Keyboard navigation: can complete all flows without a mouse
- Focus indicators are visible
- Colour contrast meets 4.5:1 for normal text, 3:1 for large text
- Page has a logical heading structure (one H1, logical H2/H3 hierarchy)
- ARIA roles and attributes used correctly
4. Performance Testing
- Run Lighthouse (Chrome DevTools) — aim for 90+ on Performance
- Largest Contentful Paint (LCP) < 2.5 seconds
- Cumulative Layout Shift (CLS) < 0.1
- First Input Delay (FID) / Interaction to Next Paint (INP) < 200ms
- Images are compressed and served in WebP format where possible
- JavaScript bundle size reviewed — no unnecessary large packages
5. API Testing
- All expected responses return correct HTTP status codes
- Validation errors return 400 with actionable messages
- Authentication required endpoints return 401/403 for unauthenticated/unauthorised requests
- Error responses don't leak internal implementation detail (stack traces, DB errors)
- Rate limiting is in place on sensitive endpoints
- Response time for critical endpoints under load
6. Security Basics
- No sensitive data in URLs (token, password, PII)
- HTTPS enforced, no mixed content
- CSRF protection on state-changing requests
- Input not reflected unescaped into HTML (XSS risk)
- SQL injection test on all input fields that interact with a database
- Cookie flags: Secure, HttpOnly, SameSite=Strict/Lax
7. Regression Testing
- Core user journeys still work after the latest changes
- Previously reported bugs are confirmed fixed and not re-introduced
- Automated regression suite runs green
Need help building this testing coverage for your application? Get in touch with RedQA.
Related articles
What is Exploratory Testing and Why Automation Can't Replace It
Exploratory testing finds the bugs that scripted tests and automation miss. Here's what it is, how it works, and why every team needs both.
When to Outsource QA vs Hire In-House: A Practical Guide
Should you build an internal QA team or outsource? This practical guide covers the decision factors, hidden costs, and when each approach makes the most sense.
What is Regression Testing?
Regression testing verifies that existing software still works correctly after changes. This guide covers what it is, why it matters, and how to do it efficiently.
Ready to Ship with Confidence?
Let's discuss how RedQA can help you deliver better software, faster. Get a free consultation and quote tailored to your project.
Get a Free Quote