Acceptance test book: definition, contents and how to write one
An acceptance test book (called a « cahier de recette » in French) is the document that lists every test case to run before a piece of software is accepted: for each case, the steps to follow, the data to use and the expected result. It checks that the delivery matches the specification, and its results feed the acceptance report that records the acceptance. It is also known as a UAT test plan or UAT test script.
What is an acceptance test book for?
The test book turns a specification, necessarily written in everyday language, into concrete checks that any tester can replay. It serves four purposes:
- Check compliance: every requirement of the specification is covered by at least one test case.
- Share a reference: before testing starts, provider and client agree on what will be checked and on what each function is expected to do.
- Trace the results: every execution is recorded (OK, KO, blocked or not applicable), with its comments and defects.
- Decide on delivery: the summary of results underpins the verdict of the acceptance report (accepted, accepted with reservations or rejected).
Who writes and who runs the acceptance test book?
The split depends on the contract. Most often the provider (the contractor, called MOE in French projects) writes the book from the specification and submits it to the client (the project owner, MOA) for review. The client may also write it. Execution falls to the client's business users, sometimes supported by a tester from the provider, under the guidance of a project manager.
In IT services firms and agencies, the book is usually written by the provider and then run by testers on the client side: they must be able to read it and enter their results without a heavy tool. See Spec2Sign for IT firms and agencies.
What does an acceptance test book contain?
An acceptance test book is usually a table in which each row is a test case. The most common columns are:
| Column | Purpose |
|---|---|
| Identifier | Unique reference of the case (for example CT-012), reused in defects and in the report. |
| Source requirement | Section or requirement of the specification that the case verifies: this is what proves coverage. |
| Batch or module | Functional grouping, useful to split execution between several testers. |
| Title | What the case verifies, in one sentence. |
| Preconditions and test data | Starting state, accounts to use, test values. |
| Steps | Actions to perform, one per line, in order. |
| Expected result | Observable behaviour that validates the case. |
| Priority | Weight of the case in the acceptance decision. |
| Status | OK, KO, blocked or not applicable, filled in at execution. |
| Comment and defect | The tester's observation and a link to the defect opened in case of a gap. |
How to write an acceptance test book in 6 steps
- Extract the testable requirements from the specification. A vague requirement (« the site must be fast ») has to be clarified with the client before writing any case.
- Organise into batches and modules that mirror the application (authentication, order, invoicing…), so that execution can be split and followed.
- Write the cases: one test intent per case, short steps in the imperative, and an expected result that can be observed without interpretation.
- Plan test data and prerequisites: accounts, rights, initial states. A case that cannot be replayed for lack of data ends up « blocked ».
- Prioritise: if time runs short, critical cases must run first. Also state what blocks delivery and what can become a reservation.
- Have the client review it, then version the book together with the specification it verifies. A book that does not follow the spec version no longer proves anything.
Example of a test case
| Field | Content |
|---|---|
| Identifier | CT-012 |
| Source requirement | Authentication, § 2.3: a wrong password is rejected. |
| Title | Sign-in with an incorrect password |
| Preconditions | An active account exists with the address [email protected]. |
| Steps | 1. Open the sign-in page. 2. Enter [email protected] and an incorrect password. 3. Click « Sign in ». |
| Expected result | A clear error message is displayed, the user stays on the sign-in page and gets no access to any data. |
| Priority | High |
Execution statuses of a test case
| Status | Meaning |
|---|---|
| OK | The observed result matches the expected result. |
| KO | A gap is observed: a defect is opened and linked to the case. |
| Blocked | The case cannot be executed (missing prerequisite, blocking defect upstream). |
| N/A | The case does not apply to this version or scope. |
At the end of the campaign, the number of cases per status and the severity of remaining defects are the basis for the verdict of the acceptance report.
Acceptance, VABF, VSR: what is the difference?
Acceptance (« recette ») is the whole verification phase that leads to the software being accepted. In some contracts, notably French public IT contracts, it is split into two stages: the VABF (verification of suitability for correct operation), which checks that the delivered system works as expected, then the VSR (verification of regular service), which observes its operation over time under real production conditions. Their duration and criteria are set by the contract.
The test book describes what is verified; these acronyms describe the moment and the contractual framework of the verification. Find these definitions in the glossary of software acceptance testing.
Common mistakes
- Writing the book at the end of the project, when there is no time left to fix the ambiguous specification it reveals.
- Cases without a measurable expected result (« the page displays correctly »): two testers will conclude differently.
- No link with the requirements: impossible to say what is not covered.
- A specification that changes and a book that does not follow: the cases test a version that no longer exists.
- Several versions of the same Excel file circulating by email, with results entered in several places.
Excel or a dedicated tool?
For a small project with a single tester, a spreadsheet is enough. As soon as acceptance involves several testers, successive versions of the specification and defect tracking, a dedicated tool avoids duplicates and keeps traceability. The comparison between Excel, test management tools and Spec2Sign details the selection criteria.
Generate your acceptance test book with Spec2Sign
Spec2Sign produces the acceptance test book from your specifications:
- you upload the specification (PDF, Word, Excel or Markdown);
- the AI extracts the requirements, quoted word for word with their source, and proposes a plan in batches and modules;
- for each requirement it writes test cases with steps, expected result, priority and test data, and flags the points to clarify that the specification leaves open;
- a coverage matrix shows the requirements without a test case;
- when the specification changes, an impact analysis proposes the cases to add, modify or make obsolete, which you accept line by line.
The generated book is a proposal: review and validate it before any contractual use.
Frequently asked questions
What is the difference between an acceptance test book and a test plan?
The test plan describes the strategy: scope, types of tests, environments, resources and schedule. The acceptance test book is its operational part: the list of precise test cases to run, with their expected result. On many IT firm and agency projects, the test book is produced directly, preceded by a few lines of framing.
When should the acceptance test book be written?
As soon as the specification is stable, not at the end of development. Writing the cases in parallel brings out the ambiguities of the specification early, while they are still cheap to resolve.
How many test cases are needed?
There is no universal number. The minimum goal is that every requirement is covered by at least one case; then add boundary and error cases on critical functions. Prioritising the cases lets you run the essentials if time runs short.
Can an acceptance test book be generated with AI?
Yes. Spec2Sign extracts the requirements from a specification and writes the matching test cases, each linked to its source section. The result remains a proposal that a human must review and validate before using it for acceptance.