Free template

QA and testing project checklist

The full QA workflow, from test plan to post-go-live smoke test. 83 items across 8 stages, 19 of them needed from the client.

For: QA lead

01Before we start

Signed proposal or contractKeyFrom client
Countersigned, not "verbally agreed". Work started on a promise is work that may not be paid for.
Deposit or first invoice paidKeyFrom client
The payment condition in the contract, met. This is the line the sales SOP will not let a project pass.
Decision-maker confirmed by nameKeyFrom client
Who signs things off, and who can say no. A project approved by a committee is a project approved by nobody.
Day-to-day contact named, and their working hoursFrom client
Including timezone. Half of "they are slow to respond" is a five-hour offset nobody wrote down.
Billing contact and PO or reference number, if they need oneFrom client
Ask now. An invoice rejected in month three for a missing PO number delays payment by a month.
Sales-to-delivery handoff completedKeySales
Call notes, proposal versions, commitments, risks and stakeholders - everything promised during the sale, in writing, where delivery can read it.
Scope, exclusions and assumptions restated in our own wordsPM
Written by the people delivering it, not copied from the proposal. Rewriting it is how you find what the proposal left ambiguous.
Project workspace, folders and client portal set upPM
Client invited and confirmed able to sign in - not "invitation sent".
Team assigned with named owners per disciplinePM
One name per discipline. "The design team" is not an owner.
Commercials checked against capacity before any date is promisedPM
The PM SOP puts this before assignment on purpose: a timeline agreed without checking the calendar is a timeline that will be missed.
NDA or data-handling requirements identifiedPM
If they handle health, financial or children’s data, that changes where things may be stored - and it is cheaper to know now.

02Kick-off

Review turnaround agreed in working daysKeyFrom client
How long feedback takes. Every date in the plan is built on this number, so it is agreed rather than assumed.
Feedback consolidated through one personFrom client
Contradictory feedback from three stakeholders is the single most common cause of rework.
Client team introduced, including anyone who can vetoFrom client
The person who appears in week eight to reject everything was always going to appear. Better in week one.
Holidays, launches and blackout dates on both sidesFrom client
Their trade show and our public holidays, on the plan before it is signed off.
Kick-off call held with the decision-maker presentKeyPM
Whole delivery team plus whoever signs off. A kick-off without the decision-maker has to be repeated.
Milestones and delivery dates agreed in writingKeyPM
With internal review dates set before each client-facing date, never on the same day.
Kick-off notes circulated with decisions, owners and next actionsPM
Within 24 hours, while people still agree on what was said.
Communication channel and update cadence agreedPM
Where we talk, how often we report, and what counts as urgent. Written down, so "I messaged you on WhatsApp" is not a delivery method.
Escalation path agreed both waysPM
Who to call when something is going wrong, on their side and on ours, before it is going wrong.
Change-request process explained and acceptedPM
How a new request gets costed and scheduled. Explaining it at the kick-off is a conversation; explaining it in week seven is a confrontation.
Risks and dependencies logged with ownersPM
The PM SOP asks for risks raised early with a proposed solution, not only the problem.
QA present at the internal kick-offQA
QA that joins after the build has already missed the requirements it is meant to test against.

03Discovery

Brand assetsKeyFrom client
Logo in vector, fonts with their licences, colour values, existing guidelines. "We will send the logo" usually means a PNG off the website.
Acceptance criteria agreedKeyFrom client
What "done" means, written before testing rather than argued after it.
Business goal for this project, in a numberFrom client
More leads, fewer support tickets, faster checkout. Without a number, "did it work" is a matter of opinion.
Who the audience is, and what we want them to doFrom client
Competitors you actually lose toFrom client
Not the biggest names in the category - the ones that come up in your deals.
What must not changeFrom client
The thing their customers recognise, or the integration that cannot break. Cheaper to hear now than to rebuild later.
Test accounts, sample data and any sandbox credentialsFrom client
Devices and browsers that matter to their usersFrom client
Their real analytics beats our assumptions, and usually shortens the matrix.
Requirements written down and confirmed back to the clientKeyPM
In their words and ours. The confirmation is the point: it is where a misunderstanding surfaces while it is still free.
Test plan written: scope, environments, device matrix, risk areasKeyQA
Plus the severity classification - critical, high, medium, low - agreed before the first bug is raised, so severity is a fact rather than a negotiation.
Existing material reviewed before asking for morePM
Their analytics, support tickets and sales objections are research that is already written down and already paid for.
Dependencies mapped between content, design, build and approvalsPM
Which piece cannot start until which other piece finishes, and who is holding each one.
Missing information listed and requested as one batchPM
One clear request beats eleven emails over three weeks, and gives the client something they can actually work through.
Task breakdown created with owners, reviewers and internal deadlinesPM
Test cases written: module, scenario, steps, expected result, priorityQA
The tracker format from the QA SOP. Test cases written after testing are a description, not a plan.

04Build

Environment readiness confirmedQA
Staging opens on every device, logins work, permissions are right, and test payments and dummy data are enabled.

05Internal review

Internal review complete before anything reaches the clientKeyPM
The PM SOP is blunt about this: no drafts, no unreviewed work, no outdated versions sent to a client.
Responsive pass at 375, 768, 1024 and 1440KeyQA
No overflow, menus behave, tap targets at least 48px, forms scroll and submit.
Browser pass on at least three: Chrome, Safari, and Firefox or EdgeKeyQA
Safari on real iOS, not an emulator - it is where the differences actually live.
Regression pass after fixesKeyQA
Re-test every resolved issue and re-walk the key flows. Fixes break things; that is what regression testing is for.
Reviewed against the scope, not just against "does it work"PM
Every requested item, every feedback point, every agreed state present.
No placeholders, lorem ipsum, or test content left anywherePM
Version and file naming correct, and the client is getting the right onePM
Sending v3 when v4 exists costs a review cycle and some credibility.
Functional pass: navigation, buttons, forms, links, sliders, popupsQA
Every module, against the test cases, not by wandering around the site.
Login, logout and session behaviour testedQA
Including what happens when a session expires mid-form.
Cart and checkout tested end to end, where applicableQA
Role-based access tested from each role, including logged outQA
The test that finds the data leak. Try to reach the thing you should not be able to reach.
Visual QA against the design fileQA
Font sizes and weights, radius, padding, margins, icon placement, white space, alignment.
At least one test on a real physical deviceQA
Emulators do not reproduce touch, keyboards, or a slow connection on a train.
Accessibility pass: contrast, alt text, focus order, labels, ARIAQA
WCAG 2.2 AA, checked with a tool and with the keyboard. Tab through the whole thing without touching the mouse.
Performance measured against the budgetQA
Lighthouse above 80 on mobile and 90 on desktop, Core Web Vitals within thresholds, network tab checked for oversized payloads.
SEO and metadata verifiedQA
Unique titles and descriptions, one H1 per page, Open Graph tags, favicon, alt text, sitemap and robots.
Broken links, redirect chains and the 404 page checkedQA
Forms, payments and integrations tested end to end with real submissionsQA
Follow the data to where it lands. A form is not tested until someone has received one.
Every bug logged with evidenceQA
Screenshot or recording, OS and browser, severity, steps to reproduce, and an assigned developer. A bug report without steps is a conversation.
Reopened bugs tracked rather than quietly re-closedQA

06Client review and sign-off

Written sign-off recordedKeyFrom client
In the portal or in writing. Per the MSA a portal approval is binding, which is exactly why it is worth having.
Feedback collected in one placeFrom client
One thread, one document. Feedback spread across email, calls and messages is feedback that will be missed.
QA sign-off given, with known issues stated honestlyKeyQA
Total cases, bugs by severity, what is deferred, and device coverage. Sign-off with a hidden known issue is not sign-off.
Walkthrough delivered rather than a link dropped in a chatPM
Ten minutes of context turns "I do not like it" into specific, actionable feedback.
Every feedback point converted into a tracked item and closedPM
Tracked by version, so "we told you about that" has an answer either way.
Anything out of scope identified, costed and agreed - not absorbed silentlyPM
Quietly absorbing scope teaches a client that scope is free, and the next request will be bigger.
Deferred low-priority bugs listed and accepted, not forgottenQA
Written down and agreed, so they are a decision rather than a discovery.

07Launch

Post-go-live smoke test on the live domainKeyQA
Forms, popups, carts, logins, CTAs - on production, on mobile and desktop. Staging passing is not production passing.
Launch date and window agreed, and who is available during itKeyPM
Not a Friday afternoon. Not the day before a holiday. Somebody on call for the hours after.
Pre-launch backup of everything being replacedKeyDev
Files and database, taken and verified before the switch, not after.
DNS and domain pointing confirmed, including www and the apexKeyDev
Both hosts resolve, and one redirects to the other. Sessions and SEO both depend on picking one.
HTTPS valid across every URL, with no mixed contentKeyDev
Search engine blocking removed from productionKeyDev
The staging robots rule that follows a site to production is the classic launch mistake - and it is invisible until traffic never arrives.
Analytics, GA4 and any pixels confirmed firing on productionQA
Real-time events on the real domain, before any paid traffic is pointed at it.
Lighthouse re-run on the live siteQA
Production is where the CDN, the real images and the third-party scripts finally all show up together.
Redirects live and spot-checked against the old URL listDev
Sitemap submitted and the property verified in Search ConsoleDev
Transactional email tested from productionDev
Enquiry, receipt, password reset. Check it arrives and does not land in spam - which is a different question from whether it sends.
Monitoring and uptime alerts pointed at the live domainDev
Client told it is live, and what to watch for in the first 48 hoursPM
First-week check-in booked before leaving launch dayPM
Launch is a window, not a button. Most of what a launch breaks shows up in the following week.

08Handover and close

QA summary reportDeliverableQA
Cases run, bugs found and their status, deferred items, device and browser coverage, sign-off note.
Final test case sheet with resultsDeliverableQA
Bug log archived with evidence attachedDeliverableQA
Kept for the support window, so a question in month two has a record behind it.

All templates

Run this checklist with your client.

It is built into WorkTogethr - add it to a project, and your client sees what they owe you.

Start free

Try the demo Book a walkthrough