Service
Pre-launch QA review
A pre-launch QA review puts every strand of testing into one scoped pass in the days before go-live: functional flows, browsers, devices, accessibility, security settings, search metadata and performance. You get one defect list, retesting as the quote lists it, and one record of what was checked.
Launch week is a bad time to discover what nobody checked. A pre-launch QA review is a fixed, written plan for that week. It is the service we would point to first if you are launching a new site or a redesign and want an outside view before visitors arrive.
What the review includes
The review draws on each of our individual services, scaled to the size of the release.
- Functional testing of every form and the main user flows, with test cases you can see in advance. See functional testing.
- Cross-browser testing on current Chrome, Edge, Firefox and Safari, chosen from your analytics where available. See cross-browser testing.
- Responsive testing on real phones and a width sweep from 320 pixels upwards. See responsive and device testing.
- Accessibility checks on a sample of templates against WCAG 2.2, as one strand of QA rather than a formal audit. See accessibility checks.
- Security configuration checks of HTTPS, headers, exposed files and admin exposure. See security checks.
- Search metadata checks of titles, canonicals, redirects, sitemaps and staging leftovers. See search metadata checks.
- Performance checks of the main templates against Core Web Vitals thresholds. See performance checks.
- Content checks for placeholder text, broken links, wrong contact details and missing images.
How the week runs
The review follows our standard QA process, compressed to fit a launch timetable.
- Scope We agree the pages, flows, browsers and devices in writing, along with what is out of scope and the dates for testing and retesting.
- Test cases We write test cases for the key flows and share them before testing starts, so your team can correct any wrong assumptions.
- First pass All strands are tested on the staging site. Defects go into a shared list as they are found rather than waiting for a final report, so fixing can start on day one.
- Triage We go through the list with you and agree which defects block launch, which should be fixed soon after, and which can wait.
- Fixes and retest Your developers fix the blockers; in the retest rounds the quote lists, we check each fix and run nearby checks for side effects.
- Live check If the quote includes it, straight after launch we repeat the checks that only make sense on the live domain: redirects, certificates, canonicals, indexing rules and form delivery.
- Sign-off record A short report records what was tested, what was found, what was fixed, and what was knowingly left for later.
Defect severity
Each defect gets a severity so launch decisions are quick and consistent.
| Severity | Meaning | Suggested launch decision |
|---|---|---|
| Blocker | A key task cannot be completed, data is exposed, or the site cannot be indexed | Fix before launch |
| High | A key task fails for some visitors or in some browsers | Fix before launch where possible |
| Medium | Something is wrong but a workaround exists | Fix in the first update |
| Low | Cosmetic or minor wording issues | Fix when convenient |
The launch decision column is guidance. The decision is always yours; our job is to make the trade-off visible.
What we ask you to prepare
The review runs faster, and finds more, when a few things are ready before day one:
- A staging site that matches what will go live, with real content and real images, and its address and any password.
- Test accounts for member areas, bookings or checkouts, created for the purpose so they can be deleted afterwards.
- Payment test mode switched on, with the provider's test card details, if the site takes payments.
- A list of business rules that the site enforces: opening hours, delivery thresholds, booking limits, minimum orders, discount conditions.
- Your analytics overview, if an older site exists, so the browser and device list reflects real visitors.
- A named contact who can answer questions during testing and decide on triage.
None of this has to be perfect. If something is missing, we note it in the scope and work around it, but each item saves time and makes the results more useful.
After the review
The sign-off summary is the end of the engagement but not the end of testing. In the weeks after launch, real visitors can take paths nobody planned for. Two habits keep the gains from the review: run the high-priority test cases again after the first round of post-launch fixes, and keep the defect list open for anything that was knowingly deferred, with the dates agreed. If you would like us to run a short regression round after the first updates, we can quote it as part of the review or separately.
What you receive
- The test plan and test cases.
- A live defect list during testing, with evidence for every item.
- Retest results as quoted, including any new defects found.
- The live check results after go-live, if the quote includes one.
- A sign-off summary you can file with the project.
What the review does not cover
The review covers what is in the written scope, on the browsers and devices listed. It is not a penetration test, an accessibility conformance audit, a code review, or a load test. We do not fix defects; your developers or agency do, and we confirm the fixes.
Questions about the pre-launch review
How far ahead should we book?
As early as you know the launch date. Testing works best once the build is feature-complete and real content is in, with enough days afterwards for fixes and a retest.
What if our launch date moves?
Tell us as soon as it does. We move the testing dates where our calendar allows, and the quote explains how rescheduling works.
Do we have to launch if blockers remain?
No. The report states plainly what is unresolved. Whether to launch with known issues is your call; some teams do, with a fix date agreed.
How many retest rounds are there?
As many as the written quote lists. If the scope changes, the change is agreed in writing first.
Want one scoped pass before go-live?
Send the launch date and staging address. A free email reply carrying no obligation says whether a pre-launch review fits your timetable.
- Written scope
- Fixed quote before any deposit
- Plain-language findings