Our QA process, from scope to sign-off

The process exists so that "tested" means the same thing on every project. Each stage produces something you can see: a scope, a set of test cases, a defect list, a retest record and a final summary. If you ever want to know where things stand, the answer is in one of those documents.

1. Brief

You tell us what is launching or changing, when it needs to go live, and what matters most. Useful things to include:

• The address of the site or the staging site.
• The launch date and any dates that cannot move.
• The forms, flows and integrations the site has, such as bookings, payments, newsletters or member areas.
• Who your visitors are, and any analytics showing which browsers and devices they use.
• Anything that must not be touched during testing, such as live payment accounts or production data.

A short email is enough to start. If something is missing, we ask.

2. Written scope

We write down what will be tested and what will not. The scope lists pages and templates, flows, browsers and devices, the strands of testing, the dates for testing and retesting, and the people who will receive the defect list. It also records access arrangements, such as a staging password or a test login.

The out-of-scope list matters as much as the in-scope list. It stops anyone assuming wider coverage than was agreed, and it is repeated in the final report.

3. Test cases

For functional testing, we write test cases before testing starts: a title, preconditions, numbered steps and an expected result for each. We share them with you, because you know the business rules better than we do, and a wrong expectation is far cheaper to fix in a test case than in a defect argument later.

For the other strands, such as browser, accessibility or security checks, we share the checklist we will work from instead.

4. Testing with evidence

We run the test cases and checks on the agreed browsers and devices. Every defect is logged as soon as it is found, in a shared list, with:

• The page address and the browser, device and operating system.
• Numbered steps to reproduce it.
• The expected result and the actual result.
• A severity: blocker, high, medium or low.
• A screenshot or short recording, and any console errors.

We do not wait for the end of testing to share findings. Your developers can start fixing blockers while testing continues.

We also log what passed. A defect list on its own cannot show coverage; the test log can.

5. Triage

Part-way through testing and again at the end of the first pass, we go through the defect list with you. Together we decide what blocks launch, what follows in the first update, and what can sit for later. Severity describes impact; the launch decision is yours. Our part is to make the trade-off clear and to say plainly when we think something is more serious than it looks.

6. Fixes and retest

Your developers fix the defects. We retest each fixed defect using its original steps, in the browser and device where it appeared, and run nearby checks to catch side effects. A fix that works is closed. A fix that does not work, or that breaks something else, goes back to the list with a note.

The number of retest rounds comes from the written quote. If the scope moves during testing, we agree the change in writing before carrying on.

7. Live check, where quoted, and sign-off record

Some checks only make sense on the live site: redirects from old addresses, the certificate on the live hostname, canonical tags, indexing rules, and form delivery from the real server. Where the quote includes a live check, we repeat those straight after launch.

The final summary records:

• What was in scope and what was not.
• What was tested, on which browsers and devices, and when.
• Every defect found, with its final status.
• Anything knowingly left unresolved, with the reason and, where agreed, a fix date.

You can file it with the project. If someone later asks whether a feature was tested before launch, the summary answers the question.

How long each stage takes

For a small site, the timeline below is a planning guide; your quote sets the real dates:

The longest and least predictable stage is fixing, which happens on your side. Leaving enough time between the first pass and the launch date does more for the quality of testing than almost anything else a project can arrange.

How we communicate

We agree one channel at the start; by default that is a shared defect list plus email. Findings are written for two readers: a plain summary for the person deciding, and technical detail for the person fixing. If we find something serious, such as exposed data or a payment flow that charges the wrong amount, we report it to you on its own rather than waiting for the next update.

What we need from you

• Access to a staging site or agreement on how to test the live site safely.
• Test accounts where flows need them, created for the purpose and removed afterwards.
• A contact who can answer questions about business rules while testing is under way.
• Developer time for fixes between the first pass and the retest.

Working with your developers or agency

We test the site; we do not build or fix it. That separation is deliberate. It means the findings go to whoever needs them in a neutral form, and nobody is marking their own work. Developers and agencies receive the same evidence-backed reports as owners, and we can talk through findings with them.

See what the outputs look like on the sample reports page, or read how we price and quote the work.