Front End Testing Checklist: What to Test

Updated 14 November 2026 · Standard formula, shown below

This checklist covers the essential front-end tests every web page should pass before launch: functionality, layout, responsiveness, accessibility, performance, and cross-browser behavior. You enter your page URL or run the checks manually, and you get a clear list of what to verify and how to fix common issues.

Why Front-End Testing Matters

Front-end testing is the process of verifying that a website works correctly for real users in real browsers. It catches problems that backend tests miss: broken buttons, overlapping text, slow loads, and inaccessible forms. A single uncaught layout bug can cost you conversions or credibility, so a structured checklist makes sure nothing slips through.

A good checklist covers more than just “does it work.” It also checks how it works under different conditions—small screens, slow networks, keyboard-only navigation, and older browsers. This is what separates a polished site from one that feels broken to a portion of your audience.

Core Functionality Tests

Start with the basics: every interactive element must do what it promises. Test each of these on the main pages and on any page with a form or dynamic content.

Links and navigation: Click every internal link, verify the URL changes, and confirm the back button works. Check that anchor links scroll to the right section.
Forms: Submit with valid data, invalid data, and empty fields. Verify error messages appear, required fields are enforced, and the form actually sends or saves.
Buttons and toggles: Click all buttons—including dropdowns, accordions, and modals—and confirm they open, close, and update state correctly.
Search and filters: Type a query, apply a filter, and check that results update without a full page reload (if that’s the intended behavior).
Third-party integrations: If you use a chat widget, payment iframe, or embedded map, test that they load and function.

Responsive and Cross-Browser Testing

Your site must look and work on a wide range of devices and browsers. Modern development tools help, but manual checks are still necessary.

Test at common viewport widths: 320px (small phone), 375px (iPhone), 768px (tablet), 1024px (small laptop), and 1920px (desktop).
Check for horizontal scrolling: At every width, the page should not scroll sideways unless a data table or image gallery intentionally does.
Verify touch targets: On mobile, buttons and links should be at least 44×44 pixels (Apple’s guideline) to be easy to tap.
Test in at least two browser engines: Chrome (Blink), Firefox (Gecko), Safari (WebKit), and Edge (Blink). Each engine renders CSS slightly differently.
Check responsive images: Large images should scale down, and the page should not load a 2MB photo on a phone.

Accessibility Checks

Accessibility is not optional—it’s a legal requirement in many regions and a usability win for everyone. A few simple checks catch most issues.

Keyboard navigation: Use Tab to move through the page. You should see a visible focus indicator, and all interactive elements should be reachable.
Screen reader basics: Run a free tool like NVDA (Windows) or VoiceOver (Mac) and listen to a few headings and links. They should make sense out of context.
Color contrast: Text must have at least a 4.5:1 contrast ratio against its background (WCAG AA). Use a contrast checker for small text.
Alt text: All meaningful images should have descriptive alt text; decorative images should have empty alt (alt=””).
Form labels: Every input must have a visible label or an aria-label that screen readers announce.

Performance and Load Speed

Speed is a feature. Google uses page speed as a ranking factor, and users abandon sites that take longer than 3 seconds to load. Run a performance test and look at these key metrics.

Largest Contentful Paint (LCP): Should be under 2.5 seconds. This measures when the main content appears.
First Input Delay (FID) or Interaction to Next Paint (INP): Should be under 200ms. This measures how quickly the page responds to clicks.
Cumulative Layout Shift (CLS): Should be under 0.1. This measures unexpected layout jumps as the page loads.
Total page weight: Aim for under 1.5MB for a typical landing page. Compress images and remove unused JavaScript.

Common Mistakes and How to Avoid Them

Even experienced developers make these errors. Knowing them helps you spot them early.

Testing only on your own device: Your laptop’s resolution and browser may hide issues that others see. Always test on at least one other device.
Ignoring console errors: Open the browser’s developer tools and look at the Console tab. JavaScript errors can break functionality silently.
Forgetting the 404 page: Test a broken URL and make sure the error page is styled and has a link home.
Skipping the “happy path” after changes: A fix for one bug can break another. Re-test the main flows after every update.
Not testing with real network conditions: Use the browser’s throttling feature to simulate a slow 3G connection. Images and scripts may load out of order.

Tools and How to Choose Them

You don’t need to buy expensive tools to do front-end testing. Start with what’s free and built into browsers.

Browser DevTools: Every modern browser has a device toolbar, network throttling, and a console. This is your first stop.
Lighthouse: A free tool in Chrome and Edge that audits performance, accessibility, and SEO. Run it in incognito mode for a cleaner result.
WAVE or axe: Browser extensions that scan for accessibility issues. They catch missing labels, contrast problems, and ARIA misuse.
Cross-browser services: If you need to test on real devices, services like BrowserStack or Sauce Labs offer free trials, but manual testing on your own devices is often enough for small sites.

Frequently Asked Questions

How often should I run a front-end test?

Run a full checklist before every major release and after any change to CSS, JavaScript, or templates. For a site that changes daily, consider automated smoke tests that check critical paths every time you deploy.

What is the difference between unit, integration, and end-to-end testing?

Unit tests check a single function or component in isolation. Integration tests check how multiple parts work together. End-to-end tests simulate a real user journey through the whole app. Front-end testing usually focuses on integration and end-to-end, because unit tests live in the codebase.

Do I need to test on real physical devices?

Not necessarily. Browser DevTools can simulate most screen sizes and touch events. But if your audience uses older Android phones or specific devices, testing on a real device is the only way to catch hardware-specific quirks.

What is the most important test for a small business website?

The contact form and the checkout (if you sell online). If those break, you lose money. Also check that the site loads quickly on a phone, because most local searches happen on mobile.

Can automated testing replace manual testing?

No. Automation catches regressions and repetitive tasks, but it cannot judge visual design, feel, or overall user experience. A human eye is still needed to notice that a button looks misaligned or that a page feels slow.

How do I test if my site is accessible?

Start with automated tools like WAVE or axe, but remember they only catch about 30-40% of issues. Then do a manual keyboard test and a screen reader test. Finally, if possible, ask a person who uses assistive technology to try your site.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.