QA & cross-browser testing checklist
"It works on my machine" is the most expensive sentence in web development. This checklist turns testing from an ad-hoc final click-through into something structured enough to actually catch problems before visitors do.
What to test on
- The site is checked on the current versions of the major browsers your actual audience uses—check analytics for what that mix really is rather than guessing
- At least one real phone and one real tablet are used, in addition to browser device-simulation modes, since simulation doesn't fully replicate real touch and rendering behavior (see the mobile checklist)
- Both a recent and a somewhat older browser version are checked where practical, since not every visitor updates immediately
- If the site has meaningfully different behavior signed in vs. signed out, both states are tested, not just whichever is more convenient
Functional testing
- Every primary user flow—browsing, searching, filling a form, checking out—is walked through start to finish, not just spot-checked at individual steps
- Every navigation link, button and interactive element has actually been clicked at least once
- Form validation is triggered deliberately—submit with fields empty, with invalid input, with unexpected characters—to confirm error handling is clear and correct
- Search functionality, if present, is tested with a query that should return results and one that genuinely shouldn't, to confirm both cases are handled sensibly
Edge cases
- Very long text (a long name, a long product title) is tested to confirm layouts don't visibly break
- Empty states are checked—an empty cart, zero search results, a list with nothing in it—since these are often untested and look broken by default
- Slow and interrupted network conditions are tested, not just a fast, unbroken connection
- Browser back/forward navigation is tested through multi-step flows like checkout or multi-page forms
- JavaScript-disabled behavior is at least considered, particularly for content that should be crawlable or usable without it
Visual & layout checks
- Layout is checked at a range of widths, not just the smallest and largest breakpoints—awkward in-between sizes catch real bugs
- Dark mode and light mode (if the site supports both) are each checked independently, not just visually skimmed
- Print styles are checked in an actual print preview if any pages are meant to be printed
- Zoomed-in text (a visitor increasing browser font size) is checked to confirm layout doesn't break
Regression testing
- Before any significant deploy, the core user flows are re-tested, not assumed unaffected because the change looked unrelated
- A running list of previously-found, previously-fixed bugs is kept and periodically re-checked, since regressions on old fixes are common
- Changes are tested on a staging environment that mirrors production as closely as practical before going live
💡 A structured test pass doesn't need to be expensive or automated to be valuable. A written checklist that a second person actually works through, every time, catches far more than an unstructured final glance from whoever built the feature.
Reporting & tracking issues
- Bugs found during testing are written down with clear steps to reproduce, not just mentioned in passing and forgotten
- Each issue is triaged—genuinely blocking for launch, or acceptable to fix after—rather than treated as uniformly urgent or uniformly ignorable
- Fixed issues are actually re-verified as fixed, not just assumed resolved because a change was made
Fold this into the pre-launch checklist before a new site goes live, and into the site migration checklist before replacing an existing one.