Website testing guides

The guides are written for working use rather than background reading. Each one opens with the short answer, then explains how to apply it, what to watch for, and where the limits are. Where a guide relies on a standard, a law or vendor documentation, the source is listed at the end with the date it was read.

• Website launch checklistWhat to test before go-live, business-critical checks first.Read
• Writing good bug reportsThe eight parts of a report a developer can act on.Read
• Test cases for small websitesStart from visitor tasks and give each case one purpose.Read
• Cross-browser testing in 2026Choose browsers from your analytics and use Baseline to judge feature risk.Read
• Testing forms and contact flowsFollow each message to the inbox, then test awkward input.Read
• Manual vs automated testingManual for judgement, automation for repetition, and how to split the work.Read
• Pre-launch security checksHTTPS, headers, exposed files, admin access and staging, before launch.Read
• Testing after CMS updatesA short regression routine that stops updates breaking things quietly.Read
• Collecting test evidenceScreenshots, recordings, console logs and a test record that holds up.Read
• Website QA cost in IrelandThe factors that set the price of testing, with published Irish figures.Read

Where to start

If you are launching soon, read the website launch checklist first, then use the QA checklist tool to work through it. If you are already testing and want better results from your developers, the guides on bug reports and test cases are the place to start. If your site is live and changes often, the guide to testing after CMS and plugin updates covers the routine that stops updates from breaking things quietly.

Guides by question

How the guides are written

Every guide follows the editorial policy. In short: claims about standards, laws and products are checked against the primary source where one exists; secondary and commercial sources are labelled as such; and nothing is presented as tested or measured unless it was. Guides carry a "last updated" date, and when a cited source changes, the guide is revised and the date moves.

The guides are written by Samuel Price, the editor of Qaveridia. Samuel writes under a pen name; the author page explains why and what that means for accountability.

Reading the guides as a team

The guides work best when everyone involved in a launch has read the same ones. A useful set for a small project team:

• Site owner or project lead: the launch checklist, the cost guide and the guide to collecting evidence.
• Developer: the security configuration checks, the cross-browser guide and the guide to testing after updates.
• Whoever tests: the guides on test cases, bug reports and forms.

When everyone uses the same vocabulary for severity, test cases and evidence, conversations about defects become shorter and less personal. The guides deliberately use the same terms throughout for that reason.

What the guides do not cover

The guides concentrate on testing websites before launch and after updates. They do not cover building websites, writing code, choosing hosting, or marketing. They do not cover native mobile apps, load testing or penetration testing in any depth, because those are specialist fields with their own methods. Where a guide touches one of those areas, it says so and suggests what kind of specialist to look for.

A note on scope

These guides describe good practice for testing websites. They are not legal advice. Where a guide mentions the European Accessibility Act, the GDPR or other rules, it does so to explain why a test matters, and points to the official source. Whether a rule applies to your organisation is a question for your own adviser.

Keeping the guides current

Testing advice changes as browsers, standards and laws change. WCAG 2.2 replaced 2.1 as the current version; the European Accessibility Act began to apply in June 2025; EN 301 549 version 4.1.1 was published in September 2026. Each of those changes touched one or more guides. When something similar happens, the affected guides are revised and their dates move, and the source lists show exactly which documents were read and when.

Suggesting a topic

If there is a testing question you would like answered, send it in. Suggestions shape what gets written next, and good questions are added to the questions and answers page.