Topic hub

Website Testing

Website testing checks whether people can complete important tasks reliably across devices, browsers and realistic conditions. A page that looks correct on one developer's screen may still fail through keyboard use, slow…

2 published guides0 subtopicsUpdated 21 July 2026

Start here

The main guide for this topic

Step-by-step

Cross-Browser Testing

Cross-browser testing checks that a website's important content and functions work across the browser engines, devices and operating systems used by its audience. It does not mean making every minor v…

Open the complete guide →

Published guides

Articles in this section

Step-by-step14 August 2026

Cross-Browser Testing

Cross-browser testing checks that a website's important content and functions work across the browser engines, devices and operati…

Read guide →

Step-by-step21 July 2026

How to Test a Website on Mobile

Mobile testing is more than shrinking a desktop browser. It checks whether real visitors can read, navigate, type, upload, pay and…

Read guide →

About this section

This section helps small businesses organise testing before launch, after significant changes and during ongoing maintenance.

Choose the guide you need

Main website testing guides
Need	Guide	Main outcome
Check the full release	Website Testing Before Launch	A controlled acceptance process covering business and technical risks
Check phones and tablets	How to Test a Website on Mobile	Working layouts, touch targets, forms and real-device journeys
Check browser compatibility	Cross-Browser Testing	A risk-based browser matrix and recorded defects
Check whether people understand the site	Website User Testing on a Budget	Observed evidence from realistic tasks rather than internal opinion

Test by task, not page appearance

Write the important user tasks first:

find the appropriate service;
understand price or request a quotation;
contact the business;
book or pay;
create or recover an account;
find delivery, returns or privacy information;
change a consent preference;
use the site with a keyboard or enlarged text.

Each task needs a starting point, expected result and evidence. “Looks fine” is not a test result.

Use several types of testing

Website testing layers
Testing type	What it finds
Functional	Broken forms, calculations, accounts, bookings, payments and links
Content	Incorrect wording, missing pages, outdated policies and inconsistent details
Usability	Confusing journeys, unclear labels and unexpected behaviour
Accessibility	Keyboard, focus, labels, contrast, text resizing and assistive-technology barriers
Compatibility	Browser, device and operating-system differences
Performance	Slow loading, delayed interaction and layout movement
Security and privacy	Weak access, exposed data, unsafe configuration and incorrect tracking behaviour
Recovery	Whether backups, rollback and incident procedures actually work

Build a risk-based test matrix

Prioritise combinations used by the audience and those carrying the greatest business impact. Include at least representative mobile and desktop environments, major browser engines and important assistive or input methods. Test payment and account routes more deeply than a low-risk informational page.

Keep staging realistic but controlled

Use representative content and data without exposing unnecessary personal information. Test external services in sandbox modes where available. Prevent staging from being indexed and ensure temporary restrictions do not accidentally reach production.

Record defects consistently

A useful defect includes:

page or task;
device, browser and account state;
steps to reproduce;
expected and actual result;
screen capture or log where useful;
severity and business impact;
owner and retest result.

Use acceptance criteria

Agree which defects block launch. A spelling issue and a failed payment should not have the same priority. Security, data loss, inaccessible core tasks, failed transactions, broken contact routes and unrecoverable deployment normally require resolution before public release.

Continue after launch

Production introduces real DNS, traffic, mail reputation, caches and third-party behaviour. Repeat critical journeys after deployment and monitor errors, forms, transactions, 404s and user reports. Schedule regression testing after major updates.

The next practical step is to list the five most valuable or risky user journeys and turn each into a repeatable test case.