Front-End Testing Checklist for Web Applications

A front-end release checklist should cover the tasks people need to complete, how the interface behaves across screen sizes, accessibility, performance, and whether automated tests are repeatable. Start with the highest-risk user journeys, then check the rendered experience in supported browsers and combine automation with human review. A clean test run is evidence about the checks you ran; it is not proof that the application is free of defects or fully accessible.

1. Verify the critical user journeys

Test complete tasks from the user’s perspective, from entry point through the visible result. Assert what a person can see or do rather than private implementation details such as function names or internal data structures. Playwright recommends testing user-visible behavior and isolating test state (Playwright best practices).

• Entry and navigation: Open the application at its normal entry point, follow primary navigation, and check browser back and forward behavior. For client-side routes, load a deep link directly and reload it.
• Search and discovery: Where search exists, check a matching query, no results, empty input, and any visible error or loading state.
• Forms: Check labels, required fields, valid and invalid values, inline errors, submit behavior, confirmation, reset behavior, and handling of unexpected or malicious input where relevant.
• State transitions: Check empty, loading, success, and failure states. Verify that progress, disabled controls, and confirmation messages make sense to users.
• Recovery: Simulate a failed request or interrupted flow where practical. Confirm the person receives an understandable message and can retry or recover without losing valid input unnecessarily.
• Persistence: Check whether refresh, navigation away and back, or a new session should retain or discard the data, and confirm that behavior matches the product requirement.

Prefer assertions such as “the confirmation is visible” or “the user reaches the order summary” over assertions about a CSS class or a function being called. Record the action, expected outcome, actual outcome, browser, and environment for failures.

2. Check layout and responsive presentation

Choose representative pages and components, then inspect them at the viewport sizes and device classes the application supports. There is no universal browser and viewport matrix: make the project’s supported environments explicit and test that matrix.

• Check narrow, typical, and wide layouts, including constrained widths and long content.
• Look for clipped text, horizontal overflow, overlapping controls, unexpected wrapping, and content hidden behind sticky elements.
• Check images at different sizes and aspect ratios, including whether they load and remain legible.
• Review typography, text scaling, color contrast, and layout under relevant user display settings.
• Check menus, dialogs, tables, and forms at small viewports, not just the page shell.
• Review visual changes in context: a screenshot difference is a signal for investigation, not proof that the new rendering is wrong.

If you use visual regression comparisons, keep the operating system and browser versions consistent between baseline and comparison. Playwright notes that rendering can vary by environment, which can create noisy comparisons (Playwright visual comparisons).

3. Test accessibility with automation and people

Decide which pages and user journeys are in scope and the intended WCAG conformance level. WCAG 2.2 became a W3C Recommendation on 5 October 2023 and added nine success criteria compared with WCAG 2.1 (W3C: What’s New in WCAG 2.2).

Automated checks

Run an accessibility scan on important screens and states. Automated tools can detect some issues, such as missing accessible names, certain contrast problems, and duplicate IDs. Playwright documents an axe integration example and emphasizes that automation finds only some accessibility issues (Playwright accessibility testing).

Manual and assistive technology checks

• Complete critical tasks using only the keyboard. Check that focus is visible, the order is logical, and controls can be reached and operated.
• Open and close dialogs and menus with the expected keys; check focus movement and return behavior.
• Submit forms with errors and confirm that messages are understandable and associated with the relevant fields.
• Use a screen reader or other assistive technology to review names, roles, states, reading order, and task completion.
• Where practical, include inclusive user testing with people who use assistive technologies.

A clean automated scan does not prove accessibility or WCAG conformance. Massachusetts government guidance also cautions that automation alone cannot confirm conformance (Massachusetts: Accessibility testing). Pair scans with manual assessment and user testing.

4. Measure performance in lab and field

Use lab checks during development to catch regressions consistently, and field data or real-user monitoring where available to understand actual visits. These answer different questions: a synthetic run is repeatable, while field data reflects a wider range of devices, networks, and user interactions.

Google’s current Core Web Vitals “good” thresholds are:

Metric	Good threshold	What it describes
Largest Contentful Paint (LCP)	2.5 seconds or less	Loading performance
Interaction to Next Paint (INP)	200 milliseconds or less	Responsiveness to interactions
Cumulative Layout Shift (CLS)	0.1 or less	Visual stability

Evaluate these at the 75th percentile of page views and segment mobile and desktop (Google web.dev: Web Vitals). Treat them as useful targets, not a complete performance plan: also inspect the pages, actions, and devices that matter to the application.

INP requires user interaction, so a Lighthouse lab run with no interaction cannot measure it directly. Total Blocking Time can serve as a lab proxy for responsiveness, but it is not the same metric. Use interaction-driven checks and field observations when evaluating INP (Google web.dev: INP).

5. Make automated tests reproducible

• Isolate state: Give tests their own storage, cookies, and data setup so they can run independently.
• Assert rendered behavior: Prefer the interface and outcomes users observe over internal implementation details.
• Set the browser matrix: Run tests in the browsers and environments the project supports; document any intentional exclusions.
• Use the right test level: Run relevant unit, component, integration, and end-to-end checks in CI.
• Make failures diagnosable: Preserve steps, browser and environment details, relevant logs, and a screenshot when it helps reproduce a visible failure.
• Keep visual comparisons stable: Use consistent browser and operating system versions for screenshot baselines and comparisons.

Google’s front-end testing guidance names frameworks such as Jest, Vitest, Cypress, Mocha, and Jasmine, and runners such as Playwright and WebDriver as examples; it does not establish a universal best stack (Google: Testing on the Web). Compare options by language and framework fit, test level, browser coverage, CI integration and runtime, isolation and debugging, accessibility tooling, and team familiarity.

6. Review screenshots of important states

Screenshots help reviewers inspect rendered pages, compare a change with a baseline, and preserve evidence of a visual issue. Capture the states the checklist covers: initial load, long content, validation errors, open menus or dialogs, and responsive layouts. A screenshot shows appearance at one moment and viewport; it cannot establish keyboard behavior, screen-reader usability, performance across visits, or correctness of a workflow by itself.

For a local browser-based workflow, use the browser automation runner already present in your project to navigate to the target page, set the viewport, wait for the relevant state, and save a screenshot. Keep browser and operating system versions stable for visual comparisons. Inspect any difference against the intended behavior before updating a baseline.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server for developers. One GET request can return a PNG, JPEG, WebP, or PDF; see the ScreenshotNeo API documentation for the available options.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
const image = Buffer.from(await res.arrayBuffer());
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', image));

• Cookie and consent banners are accepted like a visitor, and 60+ known consent platforms, newsletter popups, and chat widgets are removed before the shot; each step can be turned off.
• Bot checks and CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing. Responses identify the page verdict and billing status in headers.
• An MCP server provides take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients.
• 1,000 screenshots per month are free with no card; paid plans start at $5 for 3,000 screenshots.

Sign up for ScreenshotNeo’s free plan and get 1,000 screenshots a month with no card.

7. Troubleshoot common checklist failures

Symptom	Likely cause	What to do
A browser test passes alone but fails in the suite	Shared cookies, storage, data, or order-dependent setup	Give the test isolated state and setup; make it runnable independently.
A visual comparison changes between runs	Different browser or operating system versions, or a page captured in a changing state	Pin the comparison environment and capture after the intended state is reached.
A test passes while a user-visible issue remains	Assertions cover implementation details or only a narrow success path	Assert visible outcomes and add the affected error, empty, or recovery state.
An automated accessibility scan is clean but keyboard use fails	The scan covers detectable rule violations, not the full interaction experience	Test keyboard flows and assistive technology manually; include user testing where practical.
A lab performance run looks good but field responsiveness is poor	Lab conditions do not represent all devices, networks, and interactions	Inspect field data, segment mobile and desktop, and test actual interactions for INP.
A deep link fails on reload	The server or routing setup does not serve the client application for that path	Check direct navigation and reload behavior for supported routes, then correct route fallback or server configuration.
A form error is hard to find or understand	Error text is not visible, associated with the field, or announced appropriately	Review the message visually and with keyboard and assistive technology; check the field association and recovery path.

8. Release checklist

1. Critical entry points, navigation, search, forms, and confirmation flows work.
2. Empty, loading, success, validation, network failure, and recovery states have been reviewed where applicable.
3. Back, forward, direct deep links, and reload work for client-side routes.
4. Representative pages have been checked at the supported viewport sizes and browsers.
5. Visual differences have been reviewed in context with a stable comparison environment.
6. Automated accessibility checks have run, and keyboard and assistive technology checks cover critical tasks.
7. Lab performance checks have run; field Core Web Vitals are reviewed where available using the 75th percentile and separate mobile and desktop data.
8. Automated tests use isolated state, assert user-visible behavior, and produce enough environment detail to reproduce failures.
9. Release risks and unresolved failures have an owner and a documented decision.

Frequently asked questions

Does a front-end checklist replace code review?

No. It checks user-facing behavior and release risks; code review addresses implementation concerns and can identify issues that are not visible in a particular test run.

Should every page get the same depth of testing?

No. Prioritize by user impact, change risk, and the cost of failure. Cover shared components and high-value flows carefully, then extend checks to less critical pages based on the project’s risk.

Can a screenshot prove a page is correct?

No. It records a visual state at a point in time. Workflow behavior, accessibility, and performance need their own checks.

Which test runner should a team choose?

Choose based on the application’s language and framework, needed test level and browser coverage, CI runtime, isolation and debugging, accessibility integrations, and team experience. The named frameworks and runners in the guidance are examples, not a universal ranking.