By Mehdi HassanQA is the part of a website project that gets squeezed. Design ran a few days over, development took what was left, and the QA pass becomes ten minutes of clicking through pages the night before launch. You don't need a QA department to do better. You need a routine that fits in one day and finds the problems real visitors would hit.
How do you QA test a website before launch?
To QA test a website before launch, check it in a fixed order on the staging environment: content, devices, forms, links and redirects, browsers, speed and accessibility, logging every issue in one place. QA is the step before launch in the website design process. It's about how to test; the website launch checklist covers what must be true on the day.
The routine below is built for a small team, typically the developer plus one non-technical person such as the founder or a marketer. Two people find more than one, because the non-technical tester uses the site like a visitor, not like the person who built it.
What does a one-day website QA routine look like?
A one-day QA routine splits testing into timed blocks so nothing gets skipped when time runs short. Run it on staging a few days before launch, leaving time to fix what you find and re-test.
Morning, block 1: content pass
Read every page top to bottom on desktop. Look for placeholder text, wrong prices, broken images, inconsistent product names and missing legal links. Log as you go.
Morning, block 2: real phone on cellular
Switch off Wi-Fi on a real phone and load each key page. Check the first screen, menu, tap targets, text size and anything that shifts while loading.
Midday, block 3: forms and integrations
Submit every form with test data. Confirm the email arrives, the CRM record is created and the thank-you state appears. Try invalid inputs too.
Midday, block 4: links and redirects
Run a link checker for broken internal links. Then test redirects from a list of old URLs, checking that each lands on the right page in one hop.
Afternoon, block 5: browsers
Check key pages in current Chrome, Safari, Firefox and Edge, plus Safari on iOS. Focus on layout, fonts, video and anything animated.
Afternoon, block 6: speed and accessibility
Run a lab speed test on the homepage and pricing. Then do the accessibility smoke test: keyboard only, visible focus, contrast and labels.
End of day: triage
Sort the bug log into blocks launch, fix this week and later. Assign each blocking bug to one person with a date for the re-test.
How do you test forms and redirects properly?
Test forms by submitting them on the real environment and checking every destination, and test redirects from a written list of old URLs. These two areas cause the most expensive silent failures: lost leads and lost search rankings. Neither shows up when you just browse the site.
Forms
- Submit with valid data and confirm the notification email, CRM record and any autoresponder.
- Check that notification emails come from an authenticated domain and don't land in spam.
- Submit with missing fields and invalid emails to see the error messages.
- Test on a phone, where autofill and keyboards behave differently.
Redirects
Export your old URLs from analytics or your redesign audit, then check each one with a bulk redirect tool or a simple script. Each old URL should return a single permanent redirect to the right new page. Chains (A to B to C) and redirects to the homepage for everything both waste search value. Our website redesign checklist covers building the redirect list.
What cross-browser testing does a small team really need?
A small team needs to test the current versions of Chrome, Safari, Firefox and Edge on desktop, plus Safari on iPhone and Chrome on Android. That covers the browsers most visitors use. Testing old browser versions rarely pays off for a startup marketing site unless your analytics show a meaningful share of visitors on them.
Environment | What breaks most often | Priority |
|---|---|---|
Safari on iPhone | Viewport height, sticky elements, video autoplay, form zoom | High |
Chrome on Android | Font loading, tap targets, layout at narrow widths | High |
Desktop Safari | Newer CSS features, backdrop effects, date inputs | Medium |
Desktop Firefox | Scroll-linked animations, custom form controls | Medium |
Desktop Chrome and Edge | Usually fine if the developer built in Chrome | Low |
How do you run an accessibility smoke test?
An accessibility smoke test is a quick manual pass covering keyboard navigation, focus visibility, color contrast, alt text, form labels and heading order. It takes well under an hour per page template and catches many of the issues that block real users. It doesn't replace a full audit; for that, see our guide on how to test website accessibility.
- Put the mouse away and tab through the page. Can you reach and use every link, button and form field?
- Can you always see where focus is? If the outline disappears, that's a bug.
- Run an automated contrast check on text over backgrounds and images.
- Check that images have meaningful alt text, or empty alt text if purely decorative.
- Check that every form field has a visible label, not only placeholder text.
- Turn on your system's reduced-motion setting and confirm heavy animations calm down.
How to write a bug report the developer can fix in one go
A useful bug report has five parts: the page URL, the device and browser, the steps to reproduce, what you expected and what happened, plus a screenshot or short screen recording. For example: on the pricing page, iPhone Safari, tapping the annual toggle doesn't change the prices; expected annual prices to show; recording attached.
Avoid reports like "pricing is broken". The developer then spends time reproducing the problem before fixing it, and might fix a different issue than the one you saw. One bug per report also helps, so each can be closed separately.
Where should you run website QA testing?
Run website QA testing on a staging environment that matches production as closely as possible, then repeat a short version on production right after launch. Staging lets you find and fix problems without real visitors seeing them. A website staging environment should use the same hosting setup, build process and integrations as the live site.
Some things can only be fully tested on production: DNS, HTTPS, caching and final form destinations. Keep a short post-launch QA script for those. After launch, fold a lighter version of this routine into your website maintenance checklist so every new page or release gets checked, not just the first launch.
