The Complete Web Application QA Checklist for 2026

A QA testing checklist for a web application is a structured list of verifications — functional, visual, accessibility, performance, security — that a tester walks through before a release ships. It exists because the surface area of a modern web app, across browsers, devices, network conditions, locales, and user flows, is larger than anyone can hold in their head during a two-hour test session.

The version below is rebuilt for 2026. Core Web Vitals now use Interaction to Next Paint (INP) — it replaced First Input Delay in March 2024. WCAG 2.2 is the accessibility baseline, enforced under the European Accessibility Act since June 28, 2025. The security section follows the OWASP Top 10 2021.

TL;DR — what to verify before any release

• Functional flows — every primary user journey completes end-to-end, including error and empty states
• Cross-browser — Chrome, Firefox, Safari (iOS engine), Edge, and Samsung Internet on Android
• Responsive — touch targets meet WCAG 2.2's 24×24 CSS pixel minimum; layout holds from 320px up
• Core Web Vitals — LCP <2.5s, INP <200ms, CLS <0.1 on a simulated 4G connection
• Accessibility — WCAG 2.2 AA, axe-core clean, keyboard-only completable, focus visible
• Security — OWASP Top 10 spot checks, HTTPS enforced, auth tokens out of URLs and localStorage
• Forms, auth, network resilience, i18n — the categories most teams under-test and users notice

---

1. Functional testing — does every feature still do its job

Functional testing verifies that each feature behaves as specified. It is the most fundamental layer of QA and the one most often left half-done — coverage expands with the product while testing time stays flat.

Flows and business logic

• Every primary user journey completes start to finish without errors
• Each CTA triggers the correct action; all CRUD operations behave as specified
• State changes reflect in the UI immediately — no stale data
• Multi-step workflows (onboarding, wizards, checkout) advance, retreat, and resume correctly
• Destructive actions surface a confirmation prompt and respect cancel
• Calculations, derived values, and conditional logic are correct across the full input range
• Business rules (pricing, eligibility, permission gates) apply consistently
• Numeric edges pass: zero, negative, decimals, maximum allowed value
• Date and timezone handling holds across DST boundaries and midnight UTC

Errors, search, and filters

• A broken or slow third-party service degrades gracefully — the page does not white-screen
• Expired sessions redirect to login and return the user to their original destination
• 404 pages are informative; 500 responses never expose stack traces
• Network timeouts are caught — no silent failures, no infinite spinners
• Search returns relevant results; empty results render a clear "no results" state
• Filters narrow correctly and combine; clearing filters restores the full list
• Pagination stays accurate when filters change

---

2. UI and UX testing — does it look and feel coherent

Functional correctness is necessary but not sufficient. An application that works correctly but feels inconsistent generates support tickets and churn. UI/UX testing catches what automated tests cannot — the issues a human notices because they read the page rather than parse the DOM.

• Typography, colour, spacing, and alignment are consistent across pages and match the design system
• Icons and images render sharp at all densities; loading skeletons cover async blocks
• Every interactive element has a visible hover and focus state
• Disabled controls look distinct from enabled ones and reject click
• Destructive actions are visually distinct from primary actions
• Feedback is immediate after every user action — no silent submissions
• Animations complete within ~300ms and respect prefers-reduced-motion
• Tooltips, popovers, and modals open and dismiss correctly on click and keyboard
• Page titles describe the page; error messages describe the problem and suggest a fix
• Empty states explain how to get started; no spelling errors or Lorem Ipsum in production
• Dates, currencies, and numbers respect the user's locale

---

3. Cross-browser testing — Chrome alone is not "tested"

A web application that works in Chrome is not a tested application. Engines differ on CSS subgrid, modern JavaScript APIs, font rendering, autofill, and clipboard access. Chrome holds the largest desktop share, but Safari, Edge, and Firefox combined still represent a meaningful slice of real users.

Desktop

• Chrome, Firefox, Safari on macOS — current and one major version back
• Edge — current
• Any browser with >1% share in your own analytics

Mobile

• Safari on iOS — this is WebKit, the engine that matters; "Chrome on iOS" is also WebKit
• Chrome on Android — current
• Samsung Internet — worth a smoke pass on Samsung devices

What to verify in each browser

• Layout holds — no broken grids, no overflow, no z-index regressions
• Custom fonts load and fall back without a flash of invisible text
• JavaScript-driven features work without console errors; CSS animations behave consistently
• Form inputs render correctly and accept the expected input types
• Video and audio play where applicable, with captions intact
• Sticky headers, fixed elements, and scroll-snap containers behave on iOS

BrowserStack, Sauce Labs, and LambdaTest cover this without a device lab, and modern Playwright handles much of the desktop spread inside CI. For the framework trade-offs, see Selenium vs Playwright vs Cypress.

---

4. Responsive and mobile testing — past 320px and beyond

Responsive testing is not "does it look fine on my phone." It is a systematic pass through the breakpoints that define your layout — on real devices and emulators — verifying every interaction holds at every viewport.

• Cover the breakpoints: mobile (320–767px), tablet (768–1279px), desktop (1280–1440px), wide desktop (1440px+), plus a 1920px spot check
• Primary navigation collapses to a drawer at the correct breakpoint and opens reliably
• Data tables scroll horizontally or reformat into a stacked card layout on small screens
• Images scale without overflowing; text reflows without horizontal scrolling
• Sticky headers and footers do not cover content or obscure CTAs
• Touch targets meet WCAG 2.2 — 24×24 CSS pixels floor, 44×44 for margin
• Test on at least one physical iOS and one physical Android device per release
• The virtual keyboard does not cover active input fields; pinch-to-zoom is not blocked unnecessarily
• Sticky elements behave when iOS Safari's address bar shows and hides
• Foldables (Galaxy Fold, Pixel Fold) at least do not crash; full support if share is measurable

---

5. Performance testing — Core Web Vitals as table stakes

Performance is a quality attribute, not an infrastructure concern. Slow pages increase bounce, hurt rankings, and signal architectural problems that compound. Google's Core Web Vitals are LCP, INP, and CLS — INP replaced FID in March 2024 because FID only measured the very first interaction.

Core Web Vitals — 75th-percentile thresholds Google uses

• LCP under 2.5s, INP under 200ms, CLS under 0.1 — all "good"
• TTFB under 800ms; FCP under 1.8s on a simulated 4G connection
• No render-blocking resources in the critical request path

Assets and load

• Images compressed and served as AVIF/WebP with fallbacks
• JavaScript bundles code-split; CSS minified with unused selectors stripped
• Third-party scripts (analytics, chat, A/B tools) load asynchronously and are budgeted
• Static assets carry correct cache headers and immutable hashes where possible
• Data-heavy pages render within an agreed time budget; virtualised lists hold as data grows
• Concurrent sessions do not produce 5xx errors or latency spikes at expected peak

Chrome DevTools (Lighthouse, Performance panel), PageSpeed Insights, and CrUX field data are where to validate the numbers. For a walkthrough of the Performance panel, see Chrome DevTools performance auditing.

---

6. Accessibility testing — WCAG 2.2 AA, not optional anymore

Accessibility is a legal requirement in most jurisdictions a SaaS product cares about. The European Accessibility Act has been enforceable since June 28, 2025 for in-scope products in the EU. The US ADA Title II rule requires WCAG 2.1 AA for state and local government digital services on a phased schedule through 2026 and 2027, and Title III litigation against private businesses continues to rise. According to the 2025 WebAIM Million, 94.8% of the top one million home pages still have detectable WCAG failures.

Keyboard and screen readers

• Every interactive element is reachable by Tab in a logical order; focus is always visible
• Modals trap focus and return it to the trigger on close
• Custom dropdowns navigate with arrow keys and dismiss with Escape; no keyboard traps
• Meaningful images have alt text; decorative images use alt=""
• Form fields are paired with a real <label> — placeholder text is not a label
• Error messages announce via aria-live, aria-describedby, or role="alert"
• Page headings form a logical outline — no skipped levels

Color and WCAG 2.2 criteria most teams miss

• Text meets WCAG AA — 4.5:1 normal, 3:1 large; information never carried by colour alone
• 2.4.11 Focus Not Obscured — focused elements stay at least partially visible
• 2.5.7 Dragging Movements — drag interactions have a single-pointer alternative
• 2.5.8 Target Size — interactive targets at least 24×24 CSS pixels
• 3.3.7 Redundant Entry — users do not re-enter information already provided
• 3.3.8 Accessible Authentication — no cognitive tests required to log in

Axe DevTools, WAVE, Lighthouse, and Pa11y catch what a static scan can — Deque puts that around 57% of WCAG issues. The rest needs manual review. See the best accessibility testing tools for WCAG 2.2 for a current comparison.

---

7. Security testing — OWASP Top 10 as the QA-layer floor

Security bugs are easy to miss because they are usually invisible on the happy path. Basic validation belongs in the QA checklist, not only in a quarterly pen test. The list below maps to the OWASP Top 10 (2021) — current authoritative release, 2025 update in progress.

Injection and input handling (A03)

• Text inputs do not execute scripts — test <script>alert(1)</script> and event-handler payloads
• SQL-style payloads in search and form fields return errors, never data
• File uploads reject disallowed types even when MIME is spoofed; rich-text editors sanitise HTML

Authentication, sessions, access control (A01, A07)

• Passwords are never visible in URLs, console logs, or network payloads
• Session tokens invalidate on logout server-side; logout is not just client-side
• Account lockout or progressive rate limiting kicks in after repeated failed logins
• Password reset links expire after a single use and within a short time window
• API responses never return fields the user is not entitled to see; IDs cannot be enumerated (IDOR)
• Privilege escalation is impossible by editing request bodies; RBAC enforces on the server

Data exposure, configuration, components (A02, A05, A08–A10)

• HTTPS is enforced — HTTP redirected, HSTS set
• Sensitive data is masked in the UI and never stored in localStorage
• Error messages do not expose internal paths, schema, or stack traces
• Security headers set: CSP, X-Content-Type-Options, Referrer-Policy, Permissions-Policy
• Cookies use Secure, HttpOnly, and SameSite where applicable
• User-supplied URLs cannot be coerced into internal network requests (SSRF)
• Dependencies are scanned (npm audit, Snyk, Dependabot) and high-severity issues triaged
• Auth events, access failures, and high-value actions produce audit logs

---

8. Form testing — where revenue actually breaks

Forms are where users complete goals. A broken checkout or signup has direct revenue consequences, so they deserve methodical attention.

• Required fields are clearly marked and enforced; inline validation fires on blur, not on every keystroke
• Error messages appear adjacent to the field, not only at the top of the form
• Valid input clears prior error states; character limits are enforced and visible
• Email fields accept valid addresses (plus-addressing, subdomains) and reject malformed ones
• Phone fields handle international formats; password fields enforce policy and explain what is missing
• Date pickers function across browsers and accept manual entry where the design allows
• File uploads enforce size and type with a clear error when exceeded
• Long inputs (names, addresses) accommodate real-world length
• Success produces a clear confirmation — toast, redirect, or both
• Duplicate submission is prevented; failed submission preserves entered data
• Server-side errors surface in plain language; browser autofill works (test autocomplete)

For a structured way to file the bugs you find, see the perfect bug report template.

---

9. Navigation, auth, and network resilience

Navigation is the skeleton. Broken links, wrong redirects, and inaccessible pages erode trust quickly because every user sees them.

Links, routing, history

• Every nav link reaches the intended destination; no broken links in nav, footer, or body
• External links open in a new tab with rel="noopener noreferrer"
• Breadcrumbs reflect hierarchy; active nav state indicates the current page
• Back button returns to the previous page in the correct scroll position and state
• Deep links load correctly when pasted into a fresh tab; URLs update on SPA route change
• Bookmarked pages still resolve after deploys

Authentication-gated routes

• Protected pages redirect unauthenticated users to login
• After login, users land on the page they originally tried to access
• Authenticated users are redirected away from login and register screens
• Role-based access is enforced on the server — never just hidden in the UI

Network resilience

• Offline state surfaces a useful message rather than a crash
• Slow 3G simulation still produces a usable experience
• Retrying failed requests does not double-submit a transaction
• Long-polling, SSE, and WebSocket connections reconnect cleanly after a drop
• Background tabs throttled by the browser recover when refocused

---

10. Internationalisation and localisation

Internationalisation gets skipped more often than any category on this list — usually because the team ships in English first. If a multi-language version is on the roadmap, audit early. The cost of retrofitting i18n grows with every hardcoded string.

• All visible strings are pulled from a translation catalogue — no hardcoded English in JSX/HTML
• Layouts hold for longer-word locales (German, Finnish) and shorter ones (Chinese, Japanese)
• Right-to-left locales (Arabic, Hebrew) render with mirrored layout, icons, and progress indicators
• Dates, numbers, and currencies format per locale (Intl.DateTimeFormat, Intl.NumberFormat)
• Time zones are stored in UTC and displayed in the user's local time
• Pluralisation handles locale-specific plural forms (Russian and Arabic have more than two)
• HTML lang attribute reflects the active language; hreflang tags exist on multi-language pages

---

11. SEO and basic discoverability

SEO is not a marketing concern bolted on at the end. A QA pass should confirm the metadata search engines and AI crawlers expect to find is actually rendered.

• Every page has a unique <title> and <meta name="description">
• One <h1> per page; the heading outline descends without skipping levels
• Canonical URL is set and points at the preferred version of the page
• Open Graph and Twitter Card tags render accurate share previews
• robots.txt and sitemap.xml are reachable and reflect the current site
• Structured data validates against Schema.org where used
• JavaScript-rendered content is visible to crawlers (Google's URL Inspection Tool)
• Pages return the correct HTTP status — 200, 301, 404 as appropriate

---

12. API and integration testing

The frontend is half the surface. For applications that depend on internal APIs and third-party services, integration-level checks catch what unit and UI tests do not.

API behaviour

• Endpoints return correct HTTP status codes (200, 201, 400, 401, 403, 404, 409, 429, 500)
• Responses match the documented schema — no missing or unexpected fields
• Pagination produces non-overlapping, complete result sets; sorting and filtering combine cleanly
• Rate-limited endpoints return 429 with a Retry-After header

Third-party integrations

• Payment processors complete sandbox transactions, including 3DS challenges
• OAuth flows for all configured providers complete end-to-end and handle the cancel path
• Webhooks from connected services are received, verified, and produce the right state
• Analytics events fire at the expected moments and respect consent
• Transactional email arrives, renders across Gmail, Outlook, and Apple Mail, and the unsubscribe link works

---

Using the checklist without burning out the team

A checklist this comprehensive is meant to be tailored, not run verbatim on every commit. A practical rhythm:

• Major release — full checklist, split by section across testers so coverage runs in parallel
• Feature release — affected area plus the cross-cutting sections (navigation, performance, accessibility, security)
• Patch and hotfix — targeted slice for the area touched, plus a smoke pass on the primary user flows
• Pre-flight — wire the automatable categories (functional regression, axe-core, Lighthouse, OWASP ZAP) into CI so they run on every PR

Document the results. A checklist that produces a pass/fail record is a testing artifact; one that lives only in someone's memory is not. Spreadsheets, the bug tracker, a shared Notion page — what matters is that the results are visible, searchable, and tied to a release.

2026's accelerant is AI-assisted test generation — Playwright with GitHub Copilot, Mabl, and Testim convert natural-language steps into runnable specs meaningfully faster than before. That helps with the what to test question, not the did the build pass one. The checklist is still the spine.

---

FAQ

What should a QA testing checklist for a web application include?

At minimum: functional flows, UI consistency, cross-browser coverage, responsive behaviour, Core Web Vitals (LCP, INP, CLS), WCAG 2.2 accessibility, OWASP-aligned security checks, form validation, navigation and authentication, network resilience, internationalisation if relevant, and API integration. The 12 sections above map one-to-one.

What are the current Core Web Vitals thresholds in 2026?

LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1, measured at the 75th percentile of page loads. INP replaced First Input Delay (FID) as a Core Web Vital in March 2024.

Does the WCAG 2.2 target-size rule apply to all interactive elements?

Success Criterion 2.5.8 requires a minimum target size of 24×24 CSS pixels with documented exceptions — inline targets in sentences, user-agent controls, and cases where equivalent functionality is reachable another way. AAA-level 2.5.5 still asks for 44×44, and most teams aim there for usability.

How often should the full checklist run?

Full list on every major release. For feature releases, run the affected sections plus the cross-cutting ones. For patches, a targeted slice plus a smoke pass. The automatable categories — functional regression, accessibility scans, performance budgets, dependency audits — should run on every PR in CI.

---

Run the checklist, file the bugs faster

A checklist tells a tester what to verify. It does not help document what they find — and that documentation, with reproduction steps, environment details, console errors, and network payloads, is where QA workflows tend to break down under deadline pressure.

That is the gap Crosscheck closes. Crosscheck is a free Chrome extension for QA testers and developers: while you work through a checklist, it captures a screenshot or screen recording, the full console log, every network request, and the browser environment. You give the bug a title, mark severity, and send it to Jira, Linear, ClickUp, GitHub, or Slack with the evidence attached. The developer who picks up the ticket is not guessing — they have the recording, the logs, and the payloads in one place.

Try Crosscheck free and see how much faster the bugs you find on this checklist become bugs that ship fixed.