A repeatable website QA process before launch

Part one: what the machine checks

Anticode runs three layers of checks on every build. Your QA starts by reading their results, not by repeating them.

The Critic

Nineteen design checks, such as one font family, body text size, radius by role, links that go nowhere, em dashes, purple gradients and stock phrasing. Its results appear as the build runs, and Pro mode adds a Report tab.

The design gate

Blocks publishing a page that misses basics: a page language, a phone viewport, a name, visible keyboard focus, reduced-motion support and alt text, or that has serif fallbacks, a third font family, a purple-blue gradient, stock AI phrases, placeholder text or empty links (an empty href, "#" or javascript:). It doesn't test whether outside URLs work.

Sentinel

Twelve security checks on the exact HTML that ships: the Content-Security-Policy, forms, links, images, and anything that looks like a secret. At publish the server re-runs the checks that matter once a page is public, so failing pages can't go live.

For app builds there's a fourth layer when it's available: a headless browser opens the build at phone and laptop widths, takes screenshots, clicks through it, and the Critic fixes what it finds. It's a check on the build, not a replacement for you holding a phone.

Run the release checklist after the last change. It runs every publish check, including the security baseline, without publishing, and says whether the build is release-ready and, if not, what's missing and where.

Part two: what a person checks

Do this on a real phone, on mobile data, and on a laptop. Ideally the person doing it didn't build the site.

1. Facts. Read every phone number, email address, street address, opening hour and price against the client's approved content list. Automated checks catch an empty link, but they don't follow outside links to see if they work, and they can't tell a phone number is the right one.
2. Every form, for real. Send a submission through each one with a test name. Confirm it appears in the submissions list, that the notification email arrives, and that each connector (Slack, a sheet, a CRM) receives it. Then tell the client to expect test entries, or delete them.
3. Booking calendar, if there is one: book a slot, then try to book the same slot again and confirm it's refused.
4. Every link and button, including the footer, social links and payment-link buttons, which should all open the client's one checkout. Click outside links too: no check follows them for you.
5. Reading on a phone. Can you find the main action without scrolling? Is any text too small or crammed? Does anything overlap?
6. Keyboard only. Tab through the home page on the laptop. You should see where you are at every step and reach every control.
7. Legal pages. The Privacy Policy and Terms Anticode writes from what the site does are a starting point; check the client has read and accepted them.
8. Search and sharing basics. Page titles make sense in a browser tab; the site's robots.txt and sitemap.xml load after publishing.

Recording the result

Use the same short sheet every time: site, version, date, tester, and a line per check with pass, fail or note. Attach it to the client's sign-off. A failed manual check goes back as a specific change ("contact page phone number is the old one; replace with the number in the content list"), and the checks are rerun after the fix, not just the one that failed.

Who does what

What goes wrong

• Testing on the office Wi-Fi only. Real visitors are on mobile data and older phones.
• Testing the preview, not the live site. After publishing to the client's domain, repeat the form tests there.
• Treating passed checks as finished. Every automated check can pass on a site with the wrong prices.

Limits

Anticode runs the Critic, the design gate, Sentinel, the security baseline and, for apps, the headless-browser review, and the release checklist shows the result before publishing. It doesn't test on your devices, verify facts, or check forms deliver to the right inbox. Pair this with the website launch checklist, testing a website on mobile and client website sign-off.

Questions people ask

Can automated checks replace manual website testing?

No. They catch repeatable problems such as missing alt text or an unsafe form; a person still has to confirm the facts, the forms' destinations and how the site reads on a phone.

What does the release checklist do?

It runs every check that publishing runs, without publishing, and tells you what's missing and where to fix it.

Who should do website QA?

Someone other than the person who built the site, with the client checking facts and legal pages.