Testing a Website Before Launch: Browsers, Devices and Forms

Why your own laptop is not enough

MDN's introduction to cross-browser testing defines it as "the practice of ensuring that a website works across various browsers and devices". It covers different browsers, different devices and people who use assistive technologies or only a keyboard, and warns: "you are not your users".

MDN says a site "doesn't need to deliver the exact same experience on all browsers and devices, as long as the core functionality is accessible in some way". The GOV.UK Service Manual's page on designing for different browsers and devices agrees: small visible differences are fine "as long as it does not make it harder for the user to understand the content or interact with the page".

MDN also advises testing as you go rather than at the end, because bugs found late "will be a lot more expensive and time-consuming to fix". The final pass on launch day is covered in our website launch checklist.

Choosing browsers and devices

You cannot test every combination, so agree a list with your developer before the build. MDN says it is "enough that you ensure your site works on the most important ones", where important "often means 'commonly used among the target audience'".

The GOV.UK Service Manual publishes the list UK government services test in, updated from February 2026:

• iOS: Safari, Chrome and Edge.
• Android: Chrome, Samsung Internet and Firefox.
• Windows: Edge, Chrome and Firefox.
• macOS: Safari, Chrome and Firefox.

GOV.UK says this list represents about 98% of the most popular browsers used on GOV.UK, and that you should use analytics to decide whether your own users need more. If you already have a site, your analytics show which browsers and screen sizes your visitors actually use. MDN warns of one bias: you will see no users of a browser if the site was already broken in it.

Emulators versus real devices

Browser tools can imitate a phone on a desktop. Chrome's device mode simulates mobile screen sizes, touch, orientation and slower connections.

Google is clear about the limits. Device mode is "a first-order approximation", you "don't actually run your code on a mobile device", and some things, such as the architecture of mobile processors, DevTools "will never be able to simulate". Its advice: "When in doubt, your best bet is to actually run your page on a mobile device."

MDN's guide to testing strategies says the same: a real device "provides the greatest accuracy in terms of behavior and overall user experience". A practical split is to use emulation during the build for layouts and breakpoints, then test the important pages and every form on at least one real iPhone and one real Android phone before launch.

Choosing which pages to test

On a small site you can test every page. On a larger one you need a sample. The W3C's WCAG Evaluation Methodology (WCAG-EM) 2.0, published in July 2026, was written for accessibility evaluations, but its sampling method works for any pre-launch test. It recommends testing the whole product where feasible. Otherwise:

• A structured sample: pages covering the common views, the essential functionality, the different types of page, and the technologies the site relies on.
• A random sample: extra pages equal to 10% of the structured sample, as a check on the first.
• Complete processes: when a page is part of a process, include every step of it, such as every step of a checkout.

For a typical business site this means the home page, one of each page template (service, article, contact), the navigation and footer, every form, and the full checkout or booking flow.

Test cases for forms

Forms are where a lead or a sale is won or lost, so give each one its own test cases rather than a single test submission:

• A valid submission: the success message appears and the email or record arrives where it should.
• Required fields left empty, and values in the wrong format, such as an email address without "@".
• The same form on a phone, with the on-screen keyboard open.
• The form used with a keyboard only, from the first field to the submit button.

Error messages need checking too. WCAG success criterion 3.3.1 Error Identification says that if an input error is detected automatically, "the item that is in error is identified and the error is described to the user in text". Checks should also run on the server, not only in the browser, and spam protection should not block real people; our guide to stopping contact form spam covers both.

Testing payments without real money

Payment providers give you a test environment so you can try every path without moving money. Stripe's testing documentation, as one example, says test transactions "don't move funds" and test cards let you simulate successful payments, declines, invalid data, disputes, refunds and 3D Secure authentication. PayPal's sandbox is described as a virtual testing environment that "simulates the live PayPal production environment".

Test cases worth running in test mode:

• A successful payment, then a check that the order confirmation, stock level and email are right.
• A declined card, and what the customer sees next.
• A payment that needs extra authentication, such as 3D Secure.
• A refund, and how it appears in your admin and to the customer.

Never test with real card details in test mode; Stripe says its agreement prohibits testing in live mode with real payment details. Switching to live keys is a launch-day step, covered with other shop checks in our e-commerce launch checklist. Choosing a provider is covered in accepting payments online.

Accessibility checks along the way

Accessibility belongs in the same test plan. MDN suggests treating it as an "A-grade" requirement, and the GOV.UK guide to testing for accessibility recommends running your own tests regularly during development, using both automated tools and manual checks, because "you'll miss some issues if you only do automated testing". Our website accessibility guide turns these into a checklist you can run yourself.

Recording what you find

Write the test criteria down before testing starts. MDN suggests listing "testing requirements that need to pass to be accepted". When something fails, WCAG-EM notes that "clear issue descriptions, steps to reproduce, severity of the findings, screenshots and/or videos" help teams fix issues faster.

Testing again after updates

Testing does not stop at launch. MDN says regular testing makes sure "new additions to the code don't break old features that were previously working". This is regression testing. After any update to plugins, themes or code, run the important test cases again, ideally on a staging copy first: forms, checkout, logins and the main page templates.

GOV.UK adds that compatibility decisions "cannot be something you specify at the start of your project and then forget about". Review the browser list as your visitors change, and give users "an obvious way" to report problems. Our website maintenance checklist covers the routine.

A testing checklist

• A browser and device list is agreed, based on analytics or a published list such as GOV.UK's.
• Layouts are checked in device emulation during the build, and on at least one real iPhone and one real Android phone before launch.
• A sample of pages covers every template, every form and every complete process.
• Each form is tested with valid, empty and wrong input, on a phone and with a keyboard only.
• Payments are tested in test mode: success, decline, extra authentication and refund.
• Bugs are recorded with steps to reproduce, browser, device and screenshots.
• The key test cases are run again after every update.

Frequently asked questions

Which browsers should I test my website in?

Agree a list with your developer, based on your own analytics if you have them. The GOV.UK Service Manual list, covering Safari, Chrome, Edge, Firefox and Samsung Internet across iOS, Android, Windows and macOS, is a sensible start.

Is Chrome device mode enough for mobile testing?

It is useful during the build for layouts and breakpoints, but Google calls it a first-order approximation: your code does not actually run on a phone. Test the important pages and every form on real phones before launch.

Do I need to test every page?

On a small site, yes. On a larger site, the W3C WCAG-EM method suggests a structured sample of every page type and key function, a random extra 10%, and every step of complete processes such as checkout.

How do I test online payments without being charged?

Use your payment provider's test mode or sandbox. Stripe and PayPal both offer one, with test cards or accounts for successful payments, declines and refunds. Never use real card details for testing.

What is regression testing?

Running your key test cases again after a change, to check that updates have not broken features that worked before. Forms, checkout, logins and the main templates are the first things to recheck.

Planning a new website? We build it on a private staging site you can click through and comment on, review the design on phone and desktop, and check speed, forms, accessibility, redirects and search basics before it goes live. After launch, updates are tested on staging first. See our website development and website care services and all our services, or email [email protected].