What an acceptance test plan is really for
It makes acceptance objective. As long as tests live in people's heads, everyone checks what they think matters and forgets the rest; and at the end, nobody can say whether the site is compliant. The acceptance test plan freezes the list of cases before testing, so you know exactly what was verified, by whom, and with what result. It is also contractual protection: it spells out what was ordered, line by line, and serves as the basis for the sign-off at the end.
The minimal structure of a test case
A good test case fits in a few columns: an ID, the feature concerned, the scenario (the steps to follow), the input data if needed, the expected result, then the actual result and a pass/fail status filled during acceptance. The expected result is the column that does everything: without it, the tester cannot tell whether what they see is a bug or the intended behavior. Write it in the present tense and verifiably: "the form shows a confirmation message and sends an email to the entered address", not "the form works".
How to organize the plan for a website
Group cases by area, it avoids gaps and makes review fast. An organization that works: navigation and links, forms and submissions, content and media, responsive display, browser compatibility, performance, technical SEO, accessibility, privacy compliance. Each area gets its own cases. This structure maps directly onto our copy-paste template: the acceptance test plan is just a checklist made traceable, with a status column and an owner.
A concrete acceptance test plan example
Take the contact form on a brochure site. Case ACC-012: sending a valid message. Scenario: fill in name, email, message with correct data, click Send. Input: valid email in the format [email protected]. Expected result: a confirmation message appears, the email arrives in the target inbox, the fields clear. Case ACC-013: invalid email. Scenario: enter "abc" in the email field, send. Expected result: a clear error message under the field, no submission. Two rows, two clear results: you immediately see what a usable plan looks like.
The plan does not replace defect tracking
Common mistake: thinking the acceptance test plan covers everything. It lists what you verify and the pass/fail status, but a fail is not yet a fixable ticket. When a case fails, you open a defect with its context (URL, browser, screenshot, steps), prioritize it, track it to the fix, then re-verify the row. The plan says "what to test"; a ticket board says "where each bug stands". The two work together: the Couac widget turns a fail into a reproducible ticket with no retyping.
Frequently asked questions
Acceptance test plan or test plan, what is the difference?
A test plan is broader: it describes the test strategy (what to test, how, with what resources, over what scope). The acceptance test plan is the concrete execution on the validation side: the list of cases actually run to accept the deliverable, with their results. In practice, on a web project, the acceptance test plan is often the only formal document, and it plays both roles.
What format should an acceptance test plan use?
A spreadsheet is enough to start: one row per case, columns for scenario / expected result / actual result / status. Excel or Google Sheets do the job for a brochure site. Format matters less than discipline: cases written before testing, a verifiable expected result, a status kept up to date. As soon as defect volume climbs, pair the plan with a ticket tracking tool so you do not manage bugs in the same sheet.
Who writes the acceptance test plan?
Usually the project manager or a QA lead on the vendor side, from the specification. Ideally you have the client approve it before acceptance: that way the list of cases reflects what they expect, not just what the team has in mind. On agile projects, it is often the acceptance criteria of each user story that feed the plan as you go.
Who runs acceptance testing, and with which plan?
On the vendor side, the team runs internal acceptance first from the plan; on the client side, a business lead walks the same cases to validate fit to the need. The tester does not need to be technical: a well-written acceptance test plan, with a clear expected result per case, lets any reviewer call pass or fail without knowing the code. That is the whole point of a verifiable expected result rather than a vague "check that it works": acceptance no longer depends on who holds the keyboard.