QA Testing Checklist for Web Applications

Shipping a web application without a structured QA checklist is a gamble. Not because your developers are careless, but because the surface area of a modern web application — across browsers, devices, network conditions, user flows, and edge cases — is larger than any single person can hold in their head during a testing session.

A checklist does not replace judgment. It prevents the kind of omission that happens when a tester is two hours into a session, has found six bugs already, and mentally moves on from a section before it is fully verified. The checklist is the floor, not the ceiling.

This guide covers every major category of web application testing with actionable checklist items you can copy directly into your QA process. Use the full list for major releases, and create trimmed-down versions for patch releases or specific feature areas.

1. Functional Testing

Functional testing verifies that every feature in the application does what it is supposed to do. It is the most fundamental layer of QA and the most frequently incomplete one — because functional coverage tends to expand with the product while the time allocated to testing stays the same.

Core user flows

All primary user journeys complete without errors from start to finish
Every CTA (button, link, form submit) triggers the correct action
All CRUD operations (create, read, update, delete) work as specified
State changes are reflected in the UI immediately and correctly
Multi-step workflows (wizards, funnels, onboarding sequences) advance and retreat correctly
Actions that require confirmation prompt appropriately and respect the user's choice

Business logic

Calculations, totals, and derived values produce correct output across all input ranges
Conditional logic (show/hide fields, enable/disable features) fires under the correct conditions
Business rules (eligibility checks, pricing tiers, permission gates) are applied correctly
Edge cases for numeric fields: zero, negative numbers, decimal values, maximum allowed values

Error handling

Broken or unavailable third-party services degrade gracefully without crashing the page
Expired sessions redirect to login and return the user to their original destination after re-authentication
404 pages are informative and include a path back to the application
500 errors display a user-friendly message and do not expose stack traces
Network timeouts are handled — no silent failures or infinite loading states

Search and filtering

Search returns relevant results for valid queries
Empty search results display a clear "no results" state
Filters narrow results correctly and can be combined without producing incorrect output
Clearing filters restores the full result set
Pagination is accurate and consistent as filters change

2. UI and UX Testing

Functional correctness is necessary but not sufficient. An application that works correctly but is confusing or inconsistent to use will generate support tickets, poor reviews, and user churn. UI/UX testing catches issues that functional tests miss.

Visual consistency

Typography (font families, sizes, weights, line heights) is consistent across all pages
Color usage matches the design system — no off-brand greens, unexpected grays, or missing hover states
Spacing and alignment are consistent within and across components
Icons and imagery render at the correct size and resolution
Loading and skeleton states are implemented for all async content

Interaction design

All interactive elements have visible hover and focus states
Disabled states look distinct from enabled states and are not clickable
Destructive actions (delete, cancel, clear) are visually distinct from primary actions
Feedback is immediate after every user action — no silent submissions
Animations and transitions complete in under 300ms and can be disabled via prefers-reduced-motion
Tooltips, popovers, and modals open and dismiss correctly on both click and keyboard

Content and copy

Page titles are descriptive and accurate
Error messages describe the problem and suggest a resolution — not just "Something went wrong"
Empty states include guidance on how to add data or get started
All visible text is free of spelling errors and truncation
Dates, currencies, and numbers are formatted according to the user's locale where applicable

3. Cross-Browser Testing

A web application that works in Chrome is not a tested web application. Browser engines differ in their handling of CSS, JavaScript APIs, font rendering, and more. Users on Safari, Firefox, and Edge encounter your application differently than your developers do.

Desktop browsers

Chrome (current and one major version back)
Firefox (current and one major version back)
Safari on macOS (current and one major version back)
Edge (current)
Opera (if in your target audience analytics)

Mobile browsers

Safari on iOS (current and one major version back) — this is the engine that matters, not "Chrome on iOS"
Chrome on Android (current)
Samsung Internet (significant market share on Android)

What to check in each browser

Layout renders correctly — no broken grids, overflowing content, or misaligned elements
Custom fonts load and fall back gracefully
CSS animations and transitions behave consistently
JavaScript-dependent features work without console errors
Form inputs render correctly and accept input as expected
Video and audio playback functions where applicable
Scroll behavior (including sticky headers and fixed elements) works correctly

4. Responsive Design Testing

Responsive testing is not just "does it look okay on mobile." It is a systematic pass through the breakpoints that define your layout behavior, on real devices and device emulators, checking that every interaction is usable at every viewport size.

Breakpoints to verify

Mobile portrait: 320px–480px
Mobile landscape: 480px–767px
Tablet portrait: 768px–1023px
Tablet landscape / small desktop: 1024px–1279px
Desktop: 1280px–1440px
Wide desktop: 1440px and above

Layout behavior

Navigation collapses to a hamburger or drawer at the correct breakpoint and functions correctly
Tables either scroll horizontally or reformat into a vertical card layout on small screens
Images scale correctly and do not overflow their containers
Text remains readable without horizontal scrolling at any supported viewport width
No content is hidden by fixed headers or footers
Touch targets (buttons, links, form fields) are at least 44x44px on mobile viewports

Real device checks

Test on at least one physical iOS device and one physical Android device
Verify that pinch-to-zoom is not blocked for content that requires it
Confirm that the virtual keyboard does not cover active input fields
Check that sticky elements do not misbehave when the address bar shows or hides on scroll

5. Form Testing

Forms are where users complete goals — and where bugs have the highest business impact. A broken checkout form or registration flow has direct revenue or growth consequences. Forms deserve thorough, methodical testing.

Validation and error states

Required fields are clearly marked and enforce input before submission
Inline validation fires at the correct moment (on blur, not on every keystroke)
Error messages appear adjacent to the relevant field, not just at the top of the form
Valid input clears error states — no lingering red borders after correction
Character limits are enforced and the current count is visible when a limit is set

Input types and edge cases

Email fields reject malformed addresses and accept all valid formats (including those with subdomains and plus signs)
Phone number fields handle international formats if the application serves global users
Password fields enforce the stated requirements and provide clear feedback on what is missing
Date pickers function on all supported browsers and accept manual entry where applicable
File upload fields enforce stated size and type restrictions with a clear error if exceeded
Long text inputs (names, addresses, descriptions) accommodate the actual length users provide

Submission behavior

Successful submission produces clear confirmation — a message, a redirect, or both
Duplicate submission is prevented (submit button disables after first click)
Failed submission preserves all user-entered data so they do not have to retype it
Server-side validation errors are displayed to the user in readable language
Autofill works correctly and does not populate the wrong fields

6. Navigation Testing

Navigation is the skeleton of the application. Broken links, wrong redirects, and inaccessible pages are high-visibility bugs that damage user trust immediately.

Links and routing

Every navigation link leads to the correct destination
No broken links in the primary navigation, footer, or in-page links
External links open in a new tab with rel="noopener noreferrer" set
Breadcrumbs reflect the actual location within the application hierarchy
The active state in navigation visually indicates the current page

Browser history

The browser back button returns to the previous page in the correct state
Deep links (URLs to specific pages or resources) work when pasted directly into a browser
URLs update correctly during navigation — no stale URL showing the previous page
Bookmarked pages load correctly when revisited

Authentication-gated routes

Protected pages redirect unauthenticated users to login
After login, users are returned to the page they originally tried to access
Logged-in users cannot access login/register pages — they are redirected to the dashboard
Role-based access control is enforced — users cannot access routes above their permission level

7. Performance Testing

Performance is a quality attribute, not an infrastructure concern. Slow pages increase bounce rates, hurt SEO rankings, and — for complex applications — signal architectural problems that compound over time.

Page load

Time to First Contentful Paint (FCP) is under 1.8 seconds on a simulated 4G connection
Largest Contentful Paint (LCP) is under 2.5 seconds
Time to Interactive (TTI) is under 3.8 seconds
Cumulative Layout Shift (CLS) score is under 0.1 — no elements jumping as the page loads
No render-blocking resources in the critical path

Assets and network

Images are compressed and served in modern formats (WebP, AVIF) with appropriate fallbacks
JavaScript bundles are code-split — no unnecessary code loaded on initial page visit
CSS is minified; unused styles are not included in production builds
Third-party scripts load asynchronously and do not block page interactivity
Static assets are served with appropriate cache headers

Under load

Data-heavy pages (dashboards, reporting, large lists) load within acceptable time limits
Infinite scroll or pagination does not degrade performance as the list grows
Concurrent user sessions do not produce 500 errors or degraded response times (verify with load testing tools if applicable)

8. Security Testing

Security bugs are not always visible to users — which makes them easier to miss and more dangerous to overlook. Basic security validation belongs in the QA checklist, not only in a dedicated security audit.

Input handling

Text inputs do not execute scripts — test by entering <script>alert(1)</script> in every field
SQL injection attempts in search and form fields return errors, not data
File uploads reject disallowed file types even when the MIME type is spoofed

Authentication and sessions

Passwords are never visible in URL parameters, console logs, or network request payloads
Session tokens are invalidated on logout
Account lockout or rate limiting is active after repeated failed login attempts
"Remember me" functionality does not bypass session expiration inappropriately
Password reset links expire after use and after a defined time window

Data exposure

API responses do not return fields the current user is not authorized to see
Sensitive data (card numbers, SSNs, tokens) is masked in the UI and not stored in localStorage
Error messages do not expose internal paths, database schema, or server configuration
HTTPS is enforced — HTTP requests redirect to HTTPS without exception

9. Accessibility Testing

Accessibility is both a legal requirement in many jurisdictions and a quality signal. Accessibility bugs often overlap with usability bugs — if a screen reader cannot navigate your form, a user without a mouse probably cannot either.

Keyboard navigation

Every interactive element is reachable by Tab key in a logical order
Focus is visible at all times — no invisible focus states
Modals trap focus while open and return focus to the trigger element when closed
Dropdown menus open and navigate with keyboard arrow keys
No keyboard traps — users can always Tab out of any component

Screen reader compatibility

Every image has descriptive alt text or alt="" for decorative images
Form fields have associated <label> elements — not just placeholder text
Error messages are announced via aria-live or aria-describedby
Page headings form a logical outline (h1 → h2 → h3) — no skipped levels
Dynamic content updates are announced to screen readers where relevant

Color and contrast

Text meets WCAG AA contrast requirements (4.5:1 for normal text, 3:1 for large text)
Information is never conveyed by color alone — icons, labels, or patterns supplement color
The application is usable in high-contrast mode on Windows and macOS

10. API and Integration Testing

The frontend is only half the picture. For applications that depend on APIs and third-party services, integration-level testing catches bugs that unit tests and UI tests miss.

API behavior

All API endpoints return the correct HTTP status codes (200, 201, 400, 401, 403, 404, 500)
API responses match the documented schema — no missing or unexpected fields
Pagination parameters (page, limit, cursor) produce correct, non-overlapping result sets
Filtering and sorting parameters work correctly in combination
Rate-limited endpoints return 429 and include a Retry-After header

Third-party integrations

Payment processors complete transactions correctly in sandbox mode
OAuth login flows for all configured providers (Google, GitHub, etc.) complete end to end
Webhook payloads from connected services are handled and produce the correct application state
Analytics events fire at the correct moments (page view, form submit, conversion)
Email notifications send, arrive promptly, and render correctly in major email clients

Using This Checklist Effectively

A checklist this comprehensive is meant to be adapted, not run verbatim on every release. Here is a practical approach:

Major releases: Run the full checklist. Assign sections to different testers so coverage is distributed and review happens in parallel.

Minor releases and feature additions: Run the full checklist for the feature area, plus the cross-cutting sections (navigation, performance, accessibility) to catch regressions introduced by the new code.

Patch releases and hotfixes: Run a targeted checklist for the affected area plus a smoke test of the primary user flows.

Document your results. A checklist that produces a pass/fail record is a testing artifact; a checklist that lives only in someone's memory is not. Spreadsheets work. Your bug tracker works. A shared Notion or Confluence page works. What matters is that the results are visible and searchable.

Capturing Bugs as You Work Through the Checklist

A checklist tells you what to test. It does not help you document what you find. That documentation — clear reproduction steps, environment details, console errors, network payloads — is where QA reports tend to break down, particularly under time pressure.

This is exactly where Crosscheck fits into a checklist-driven workflow. Crosscheck is a browser extension built for QA teams that automatically captures everything at the moment you find a bug: a screenshot or session replay, the complete console log, every network request, and your browser environment details. You give the bug a title, mark severity, add any notes — Crosscheck handles the evidence.

When you are working through a checklist and hit an issue in the performance section, you do not have to pause, open DevTools, screenshot the waterfall, copy network timings, and manually construct a report. Crosscheck has already captured it. One click and it goes to Jira or ClickUp with everything a developer needs to act on it immediately.

For teams running formal QA cycles against a checklist, Crosscheck also provides instant replay — a replayable recording of the session leading up to the bug. When the developer picks up the ticket, they are not guessing at what the tester did. They watch it.

The Bottom Line

A QA testing checklist for web applications is not a sign that your team lacks confidence — it is a sign that your team takes quality seriously enough to be systematic about it. The categories in this guide cover the full surface area of a modern web application: functional correctness, UI consistency, cross-browser and responsive behavior, form handling, navigation, performance, security, accessibility, and API integration.

No checklist will catch every bug. But a well-structured checklist, applied consistently, catches the bugs that omission and familiarity bias miss — which are often the most embarrassing ones to ship.

Run the checklist. Document the results. And when you find something, make sure the report you file is complete enough to be acted on without a follow-up conversation.

Crosscheck makes that last part automatic. Try it free and see how much faster your QA cycle moves when every bug report comes with full technical context attached.