Website quality assurance and pre-launch testing
Every release deserves a second look.
Qaveridia tests websites before launch and after updates. We work through forms, browsers, devices, accessibility, security settings and search metadata, write down what we find with the evidence attached, and check fixes again in the retest rounds your quote lists.
- Functional testing
- Cross-browser testing
- Accessibility checks
- Launch readiness
Our release protocol
- 01Plan Agree the scope, the pages and the devices in writing.
- 02Test Run structured checks across browsers and screens.
- 03Fix Your team resolves issues; we retest them as quoted.
- 04Verify Final checks and a written record for sign-off.
The release is only as strong as its evidence.
Every finding we log carries the page, the browser, the steps and a screenshot or recording. When something passes, we say what we tried. That record is what lets you launch knowing what was checked and what was not.
Functional testing
- Forms
- User flows
- Integrations
- Core features
Performance checks
- Page weight
- Core Web Vitals
- Server response
- Images and fonts
Accessibility checks
- WCAG 2.2 sample
- Keyboard paths
- Labels and errors
- Contrast and zoom
Security checks
- Certificates and HTTPS
- Response headers
- Exposed files
- Admin and updates
Our QA services
Testing that covers the whole release
A website can look finished and still fail on a phone, in a browser nobody on the team uses, or when a visitor presses Tab instead of clicking. We test the parts people use, one strand at a time, and report each strand separately so you can act on it.
View all services- Functional testingForms, logins, checkout steps and integrations, tested end to end.
- Cross-browser testingChrome, Safari, Firefox and Edge, on the versions your visitors run.
- Responsive testingPhones, tablets and wide screens, plus zoom and rotation.
- Accessibility checksA WCAG 2.2 sample within QA: keyboard, labels, contrast, zoom.
- Search metadata checksTitles, descriptions, canonicals, redirects and structured data.
- Security checksHTTPS, response headers, exposed files and update hygiene.
Defect to release
Our QA process
One loop runs through every engagement: plan, test, fix, retest for the rounds the quote lists, then sign off. A finding stays open until a fix has been seen working.
See the detailed process- Plan and prepareDefine scope and test cases.
- Run testsExecute the agreed cases.
- Issues found?YesNo
- Fix and retestResolve, then test again.
- Final verificationChecklist and approval.
- LaunchThe website goes live.
Yes goes back through fix and retest. No moves on to final verification.
Preflight checklist
Launch readiness checklist
The short version of what we confirm before a site goes live. The full list, with notes and an export, is in the free checklist tool.
Open the checklist| # | Check item | Description | Sample status |
|---|---|---|---|
| 01 | Core features working | Forms, search, user flows, integrations | Completed |
| 02 | Cross-browser testing | Chrome, Firefox, Safari, Edge | Completed |
| 03 | Mobile responsive | Tested on phones and tablets | Completed |
| 04 | Accessibility check | WCAG 2.2 sample review | In progress |
| 05 | Search metadata | Titles, descriptions, structured data | Completed |
| 06 | Security settings | HTTPS, headers, exposed files | Pending |
| 07 | Performance check | Page weight, Core Web Vitals | In progress |
| 08 | Final content review | Text, links and media | Not started |
Before you launch
- Test everything in scope
- Fix the blockers
- Verify on real devices
- Get written approval
What testing can tell you, and what it cannot
Testing is a way of finding out. A QA review shows which flows work on the browsers and devices in scope, which ones fail, and how badly. It produces a list of defects, each one reproducible, and a record of what passed. It does not prove that a website has no defects left, and we will not tell you that it does. A clean report means nothing in scope failed while we were looking.
The same applies to accessibility and security. Our accessibility checks sample pages against WCAG 2.2 using automated tools, keyboard testing and manual inspection. They find barriers; they are not a formal conformance audit or a legal opinion. Our security checks look at configuration that anyone can see from outside, such as certificates, headers and exposed files. They are not a penetration test, and we say so in every report.
What you get is a clear picture before launch day: what is ready, what is blocking, and what can wait for the next release. A quoted retest round earns its place, because a fix that breaks something else is still a broken release.
Practical tools
Tools to make QA easier
Four free tools that run in your browser. Nothing you type is sent anywhere.
QA checklist
Thirty-eight pre-launch checks to tick, annotate and save as text.
Open toolTest case builder
One structure for every test case, exported as a spreadsheet file.
Open toolBug report generator
Turn a problem into a report a developer can reproduce.
Open toolLaunch readiness planner
List your release gates and see what still blocks launch.
Open tool
Frequently asked questions
Your QA questions answered
Short answers here. The full list is on the questions page.
View all questionsWhat is website QA testing?
It is the work of checking a website against what it is supposed to do before real visitors find the gaps. That means clicking through flows, submitting forms, trying different browsers and screens, and writing down each failure so it can be fixed, then checked again in a quoted retest.
Why test before launch?
A defect found before launch is fixed before any visitor meets it. After launch, the first sign of a broken form may be a lost enquiry rather than a tester's report.
What types of websites do you test?
Brochure sites, content sites, booking and enquiry flows, and small online shops. We test the website as visitors use it, whatever it was built with.
Do you provide QA reports?
Yes. Every engagement ends with a written report: what was tested, what failed with evidence, what passed, and what was left out of scope.
How long does testing take?
It depends on the number of pages, flows and devices in scope. The quote states the testing days before any work starts.
Do you offer ongoing testing?
Yes, as a quoted arrangement for regression testing after updates, for example after a CMS or plugin release.
Can you fix the issues?
Our job is to find and document defects, then retest in the rounds the quote lists. Your developers or agency make the fixes, so the testing stays separate from the build.
Do you also test accessibility?
Yes, as one strand of QA: a WCAG 2.2 sample with keyboard and manual checks. It finds barriers but is not a formal conformance audit.
Ready to launch a better website?
Launching soon? Tell us what and when.
Send a short brief. A free email back, with no obligation, says whether and how we could help.
- No obligation
- Written scope
- Plain-language findings