Acceptance Test Plan Example
A worked plan with test cases, roles and sign-off rules that shows how a client checks a web project before approving it.
1 Overview
An acceptance test plan describes how the client checks that a finished web project does what was ordered, and under which conditions the client approves it. It is written before testing starts and agreed by both sides. Its value is simple: sign-off stops being a feeling ("it looks fine, I think") and becomes a result that anyone can verify. That protects the client from approving something unfinished and the provider from an approval that never comes.
What the plan must contain
- Scope. Which parts of the project are tested and which are not, with a reference to the specification or the user stories the tests are derived from.
- Test environment. Where testing takes place, with which data, and on which browsers and devices.
- Roles. Who tests, who records defects, who fixes them, and the one person who declares acceptance.
- Schedule. The test window, the time reserved for fixes and the date for the retest.
- Test cases. Each with an ID, a precondition, numbered steps and an expected result that can only be passed or failed.
- Defect classes. Usually three: blocks use, impairs use, cosmetic. With examples.
- Sign-off criteria. The rule that decides whether the project is accepted, stated in numbers.
Writing good test cases
A test case follows a real task from start to finish: a customer books an appointment, an employee exports a list. Write it so that a colleague who has never seen the system can run it. The expected result must be observable: "the confirmation email arrives within 2 minutes and shows the booked time" can be checked, "booking works well" cannot. Include cases for what should not be possible, such as booking a slot that is already taken, and for the things users do wrong, such as leaving a required field empty. Use the people who will work with the system as testers; they notice problems a project manager will not.
Common mistakes
- The plan is written after delivery. Then the tests describe what was built, not what was ordered.
- Only the happy path is tested. Errors, permissions and edge cases are where defects sit.
- Test cases are derived from nothing. Every case should point to a requirement; a requirement without a case is not tested.
- Sign-off criteria are missing or say "free of defects". No software is, and the sentence invites endless discussion. Define how many defects of which class may remain open.
- New wishes are logged as defects. Something that was never specified is a change request and is handled and priced separately.
- No time for fixes and retest. Plan both from the start.
- Testing on the provider's demo data only. Use realistic data, including long names, special characters and large lists.
After testing
Record every run with tester, date, result and, for failures, a screenshot and the steps taken. At the end, the responsible person signs a short acceptance record that lists the remaining open defects with their fix dates. Acceptance often triggers the final payment and the start of warranty periods, and what it means legally depends on your contract and jurisdiction. If you are unsure about a conditional acceptance or a refusal, ask a lawyer before you sign.
2 Example
This invented plan covers the acceptance of an online repair booking portal for a bicycle workshop. Company, people, dates and figures are made up, and only five of the fourteen test cases are shown.
Acceptance Test Plan: Repair Booking Portal
Client: Wrenlow Cycle Works
Provider: Yarrowby Digital
Version 1.0, agreed on 30 October 2026
1. Scope
Tested: online booking of repair slots, customer account, workshop calendar for staff, email notifications. Basis: specification version 2.3, sections 4 to 7.
Not tested: the existing marketing website and the till system.
2. Environment
Staging system with a copy of the service catalogue and 40 invented customer records. Browsers: current versions of Chrome, Firefox and Safari on desktop, plus one Android phone and one iPhone.
3. Roles
- Harriet Fairholt, owner: decides on acceptance and signs the record
- Duncan Brandt, workshop manager: tests the staff calendar
- Anjali Nandakumar, front desk: tests booking and customer account
- Tomasz Wieland, project lead at the provider: receives defects, plans fixes, does not test
4. Schedule
- Testing: 9 to 13 November 2026
- Fixes by the provider: 16 to 18 November 2026
- Retest of failed cases: 19 and 20 November 2026
- Acceptance decision: 23 November 2026
5. Test cases (excerpt)
AT-01 Book a repair slot. Precondition: not logged in.
- Step 1: open the booking page and choose "Brake service"
- Step 2: pick a free slot on any weekday and enter name, email and phone
- Step 3: confirm the booking
- Expected: a confirmation page shows service, date and time; a confirmation email with the same data arrives within 2 minutes
AT-02 Slot already taken. Precondition: AT-01 passed.
- Step 1: in a second browser, try to book the same slot
- Expected: the slot is not offered; no second booking is created
AT-04 Required fields.
- Step 1: submit the booking form without an email address
- Expected: the form is not sent; a message next to the field names the missing entry
AT-07 Cancel a booking. Precondition: logged in as a customer with one booking.
- Step 1: open "My bookings" and cancel the booking
- Expected: the booking shows as cancelled, the slot is free again in the staff calendar, customer and workshop each receive an email
AT-11 Staff calendar permissions. Precondition: logged in as front desk.
- Step 1: open the calendar and try to change the opening hours
- Expected: bookings are visible; the opening hours setting is not available to this role
6. Defect classes
- Class A: a core task cannot be completed, or data is lost or shown to the wrong person
- Class B: a task can be completed only with a workaround
- Class C: cosmetic, such as spacing or a typing error
7. Sign-off criteria
The portal is accepted when all 14 test cases have been run and recorded, no class A defect is open, at most 3 class B defects are open and each has an agreed fix date, and class C defects are listed in the record. Requests that are not in specification 2.3 are recorded as change requests and do not affect acceptance.
3 Who this is for
Project manager
You get a structure for the test phase: scope, roles, schedule, defect classes and a sign-off rule in numbers, so that the end of the project is planned work and not an open-ended round of feedback.
Founder
You see what you should check before you approve a web project and release the final payment, and how to tell a real defect from a new wish that needs its own estimate.
Product manager
You can turn requirements into test cases with steps and observable expected results, and you see why every requirement needs at least one case before testing starts.
4 Questions and answers
Who writes the acceptance test plan, the client or the provider?
Either can draft it, but both must agree on it before testing starts. In practice the provider often drafts the structure and the test cases from the specification, and the client adds cases from daily work and decides the sign-off criteria. The client's own people should run the tests, because acceptance is the client's decision.
How many test cases does a web project need?
Enough to cover every agreed requirement at least once, plus the most likely error situations. There is no useful fixed number. A small booking portal may need 10 to 20 cases, a shop with several roles far more; these figures are an illustration only. If a requirement has no test case, either add one or accept that it will not be checked.
What if a defect is found after sign-off?
That depends on your contract. Many contracts include a warranty period in which the provider fixes defects that existed at acceptance at no extra cost, and a maintenance agreement can cover what comes later. List known open defects in the acceptance record so they are not lost. For questions about your legal rights, consult a lawyer.
Planning a project like this?
Tell us what you are building. You get a straight answer on scope, approach and effort.