Website QA Testing: How to Catch Bugs Before Customers Do

Every website, from a simple landing page to an online shop with hundreds of products, needs to work without glitches. In reality, every live system that keeps evolving has bugs: a form that doesn't send, a button that disappears on mobile, a tracking pixel that counts every click twice, or a page that only renders properly in one browser.

The question is not whether there will be bugs, but who finds them first: your team or your customers. On small projects, developers usually test their own work. On larger ones, testing becomes a separate discipline called QA. In this guide we'll cover:

• what QA is and why even a small company website needs it;
• the stages of a structured testing process;
• the main types of testing and what the testing pyramid is;
• what to check on a website before launch, including multilingual sites;
• which tools teams use today and which mistakes to avoid.

What QA is and why even a small business website needs it

QA (quality assurance) is the process of making sure a digital product works the way it should. It's a broader idea than "testing": it also includes reviewing the specification and requirements before development starts, so problems are caught at the stage where fixing them costs almost nothing.

A well-defined QA process saves both time and budget. A bug found while the specification is being written is fixed with one line in a document. The same bug discovered after launch can cost you lost leads, an ad campaign burning money on a broken page, and a dent in your reputation.

In larger development teams, QA engineers own testing. Their job is to examine the product in depth before it reaches users: find defects, make sure everything works on every supported device and browser, and document each problem in a detailed bug report so a developer can reproduce and fix it.

A small or mid-sized business website usually doesn't have a dedicated tester, but that doesn't mean you can skip the stage. A website is a sales tool. If the contact form never reaches your CRM, the business simply doesn't know it's losing enquiries. So even for a ten-page company website, it's worth deciding who tests, what gets tested and when.

What a QA process looks like: from analysis to report

QA is not clicking random buttons the day before launch. It's a process split into stages, and each stage has a clear output.

Requirements analysis

First, you review the specification: what the site is supposed to do, where forms are sent, which journeys visitors will take and which weak spots should be tested first. The more thorough this analysis is, the lower the chance the site goes live with defects. This is also where gaps surface, such as "What happens if someone submits the form without a phone number?" or "Which page appears after a failed payment?"

Writing test cases

Next, you write test cases: short instructions describing the setup, the steps and the expected result. For example: "Open the home page on mobile, tap the WhatsApp button, expect a chat to open with a pre-filled message." Every important function on the site deserves its own test case, from the checkout flow down to a single button.

Running tests and reporting bugs

This is the core stage: testing the interface, the functionality, the integrations with external systems and every realistic visitor journey. Each problem is logged in a bug report: what was done, what was expected, what actually happened, on which device and browser, ideally with a screenshot or screen recording.

Regression testing

Once developers have fixed the bugs, you test again. The goal is to confirm the fixes didn't break something else. Regression testing is also repeated after every significant change: a theme update, a plugin swap or a move to a new platform.

Summary report

Finally, you prepare a report: what was tested, what was found, what was fixed, and what is still open and at what priority. The report helps you decide whether the site is ready to go live and what to plan for the next release.

Types of testing worth knowing

There are dozens of testing types, and no project uses all of them. Each project picks the methods that fit its requirements, budget and risks. Here are the main ways to classify them.

By level of automation

Manual testing: a tester works through the scenarios and performs the steps themselves. It takes time, but it's essential for judging usability, design and the overall feel of the site, and it's the right way to check small changes.

Automated testing: you write a script that imitates user actions, for example filling in a form and clicking "Submit". The script can then run again and again, with one click, on a schedule or after every update. It pays off for flows that repeat constantly, such as sign-up, add-to-basket and checkout.

By purpose

Functional testing checks that the site does what it is supposed to do: the form submits, the catalogue filter works, the order is recorded.

Non-functional testing checks how the site behaves under different conditions: speed, load, security, browser compatibility, accessibility and localisation.

By knowledge of the system

In black-box testing, the tester can't see the code and behaves like an ordinary visitor. This is the most common approach for websites, and it fits every stage.

In white-box testing, the tester knows the code and architecture and checks the logic from the inside. In grey-box testing, they have partial access, for example to the admin panel or the CMS, but the test itself is still carried out through the interface.

By type of scenario

Positive testing uses valid data and checks that the normal scenario works. Negative testing feeds in invalid data: what happens if someone types letters into the phone field? Leaves a required field empty? Uploads a huge file? On websites, many of the most expensive bugs turn up exactly here.

By who tests and when

Alpha testing is done on an early version inside the team. Beta testing opens the product to a limited group of real users before the full launch. By order of execution, you'll also hear about confirmation testing (verifying that a specific bug is fixed), regression testing (verifying nothing else broke) and acceptance testing (verifying the site meets all of the client's requirements before handover).

The testing pyramid: from unit tests to the UI

In software development, tests are usually split into levels that together form what's known as the testing pyramid. The base holds many small, fast tests; the top holds a few broader, more expensive ones.

Unit tests

These check a single function or component in the code. Developers usually write them themselves, so errors are caught before the code ever reaches a tester. On sites with custom code, such as a bespoke WordPress plugin or a JavaScript integration, this is the level that saves the most time.

Integration tests

These check how different parts work together: the website and the CRM, the form and the automation workflow, the shop and the payment provider. On modern websites this is the main weak point, because every connection depends on an external system that can change without notice.

End-to-end tests

These check a complete user journey: arriving on the site from an ad, filling in a form, and ending with the lead appearing in the CRM and a sales rep getting a notification. This is the test closest to your customer's real experience.

UI tests

These check the visual layer: design, consistency, button and form states, and rendering at different screen sizes. Visual regression testing belongs here too: it automatically flags unexpected changes in how a page looks.

On a site built with a platform like Webflow or Wix, most of the code is managed by the platform, so the emphasis shifts to integration, end-to-end and UI testing. On a site with custom code, it's worth investing in the base of the pyramid as well.

What to check before launch: a practical checklist

Theory matters, but a business owner mainly needs to know what to check before the site goes live. Here's the checklist we recommend working through, ideally on a staging environment before publishing to the main domain.

Forms, leads and integrations

• every form submits and reaches the right destination: email, CRM, Google Sheets or an automation platform;
• the thank-you message or page appears, and a second click doesn't create a duplicate submission;
• invalid fields show clear error messages, including international phone numbers entered in different formats;
• spam protection (reCAPTCHA, Turnstile or a built-in mechanism) works without blocking real visitors;
• the WhatsApp button opens a chat with the correct number and the correct message.

Devices and browsers

• testing on real phones, both iPhone and Android, not just in the browser's responsive mode;
• current versions of Chrome, Safari, Edge and Firefox;
• the mobile menu opens and closes, there's no horizontal scrolling, and nothing gets cut off;
• images and video load without distortion on very narrow and very wide screens.

Speed and performance

• a check in PageSpeed Insights and the Core Web Vitals report, with a focus on mobile;
• images in a modern format (WebP or AVIF) and at a sensible size;
• no leftover scripts from plugins and tools you no longer use. You'll find the full picture in our website speed optimisation guide.

Technical SEO

• every page has a unique title and meta description, and a single H1;
• no important pages are set to noindex, and robots.txt isn't blocking the site;
• the sitemap (sitemap.xml) is valid and submitted to Google Search Console;
• 301 redirects from old URLs are in place, there are no broken links, and the 404 page is genuinely useful. We explain how to build one in our guide to 404 error pages.

Accessibility

• full keyboard navigation with a visible focus state;
• alt text for images, sufficient colour contrast and labels on form fields;
• an accessibility statement, with WCAG 2.2 AA as a sensible target. In the EU, the European Accessibility Act now applies to many consumer-facing digital services, so check whether it covers your business (this is not legal advice). More detail in our website accessibility guide.

Analytics, pixels and privacy

• GA4, Google Tag Manager and the Meta pixel each load only once;
• conversion events (form submission, WhatsApp click, purchase) are counted correctly, with no duplicates;
• the cookie banner and privacy policy are up to date, non-essential tags don't fire before consent, and personal data is collected only where needed, in line with the GDPR and ePrivacy rules (this is not legal advice);
• the site runs on HTTPS only, with no "mixed content" warnings.

Extra checks for multilingual websites

A site that serves several languages and markets adds a layer of testing that many templates and tools don't account for, especially if one of the languages is written right to left, such as Arabic.

Right-to-left layouts

• arrows, "next" and "previous" icons and sliders point in the right direction;
• spacing and text alignment haven't been flipped incorrectly in components originally built for left-to-right languages;
• email and URL form fields are displayed left to right, so visitors can see what they're typing.

Mixed text and numbers

Sentences that mix scripts, numbers and punctuation tend to break: a full stop jumping to the start of the line, a phone number displayed backwards, a currency symbol on the wrong side of the price, or dates and decimal separators in the wrong local format. It's worth going through every page and looking specifically for lines like these.

Fonts and content

Check that the font supports every character and diacritic in each language, that there's no visible font swap while the page loads, and that all microcopy is translated: form error messages, basket buttons, automated emails and system pages. Many plugins and templates leave untranslated strings that only come to light after launch.

Language versions

If the site has several language versions, check the language switcher, the hreflang tags, the text direction in each version, and that forms in every language reach the right destination.

Website testing tools in 2026

Professional testers work with dozens of tools. A business website doesn't need all of them, but these are the main ones worth knowing:

• Chrome DevTools and Lighthouse: performance, accessibility and basic SEO checks right in the browser, including device emulation and slow-network simulation.
• PageSpeed Insights and Google Search Console: speed data from real users, indexing errors and page experience issues.
• BrowserStack or LambdaTest: cloud platforms for testing on real devices and browsers when you don't have your own device lab.
• Playwright and Cypress: open-source libraries for automated browser testing. The veteran Selenium is still in use, but new projects today usually choose Playwright or Cypress.
• Postman: API and webhook testing, useful when your site is connected to a CRM or another external system.
• k6 or Apache JMeter: load testing, for example before a big sale or campaign.
• WAVE and axe DevTools: automated accessibility scanning. They catch some of the issues, but they don't replace manual checks.
• Screaming Frog SEO Spider: crawls the site to find broken links, redirects, duplicate titles and missing pages.
• Jira, Linear or monday.com: managing bug reports and tracking fixes.
• Microsoft Clarity: session recordings and heatmaps that help you spot bugs visitors run into after launch.

AI-based tools already help write test cases and automation scripts, but the results still need to be reviewed by a person who understands the business and its customers.

Common website testing mistakes

Testing only on the developer's computer

The developer knows the site by heart and works on a large screen in a single browser. Most of your visitors, meanwhile, are likely to arrive on a phone. Test on real devices, and ask someone who didn't build the site to run through the scenarios.

Testing only the happy path

A form that works with perfect data isn't enough. Most failures appear when a visitor makes a mistake, changes their mind halfway, hits the browser's back button or clicks "Submit" twice.

Not checking what happens after the form

The form submits and the thank-you message appears, but the lead never reaches the CRM because a field name changed. Test the whole chain all the way to the person who follows up, not just the part the visitor sees.

No regression testing after updates

A WordPress plugin update, a component change in Webflow or a new theme can break pages nobody touched. After every significant update, run through a short list of critical scenarios.

Testing once and forgetting

A website is a living system: external services update, certificates expire and new content is added. Schedule regular checks, for example once a month, plus a full test before every major campaign.

How RJL Studio tests websites before launch

At RJL Studio, testing is built into every project rather than squeezed into the last day. We write test cases for every form, integration and checkout flow, test on real devices and across browsers, check accessibility and every language version, and verify that each lead reaches the CRM and each event is counted correctly in GA4 and the ad pixels. After launch we keep monitoring and run regression tests with every update.

Building a new website, or want to check your current one before a campaign? Read about our Webflow development and WordPress websites, or get in touch and we'll come back to you with a testing plan tailored to your site.

Frequently asked questions

What is the difference between QA and software testing?

Software testing is part of QA. Testing finds bugs in an existing product, while QA is the whole process: analysing requirements, writing test cases, testing, fixing, regression checks and reporting, with the aim of preventing bugs rather than just finding them.

How long does website testing take before launch?

It depends on the size of the site and the number of integrations. A landing page with a single form usually needs a few hours. A company website with a CMS and a CRM integration deserves a few days. An online shop with payments and stock management needs more than that. Always leave time for fixes and a second round of testing.

Can I test my website myself?

Partly, yes: filling in forms, viewing the site on your phone, running PageSpeed Insights and an automated accessibility scanner. But integration testing, analytics, technical SEO and standards-based accessibility audits require experience and tools, so it's worth involving a professional tester or your development team.

When is automated testing worth it?

When you have critical flows that repeat constantly and change often, such as sign-up, the shopping basket and checkout, and especially on sites that are updated frequently. For a small company website, manual testing against a fixed checklist is usually enough.

What should I do if I find a bug after launch?

Log it in a proper bug report with steps to reproduce, the device and the browser, assess its impact and fix it according to priority. Bugs that affect forms, payments or conversions should be fixed immediately. After the fix, run a regression test and add a scenario to your checklist so the bug doesn't come back.