Test acceptance workbook: free template to fill in, example and method

A test acceptance workbook is the document that lists the test cases the customer uses to check that delivered software does what was ordered. Each row describes one check: the requirement covered, the steps to follow, the data to enter, the expected result, then the actual result and a status (Pass, Fail, Blocked). This guide shows you how to structure it, with a filled-in example, and gives you a free Excel template, ready to fill in.

What is a test acceptance workbook?

In IT projects, acceptance testing is the phase during which the customer checks that delivered software matches the order before accepting it. The test acceptance workbook (called cahier de recette in French projects) gathers the checks to carry out during this phase, then keeps a record of them: who tested what, when, and with what result.

In international testing vocabulary (that of the ISTQB), this phase corresponds to acceptance testing, and more precisely to user acceptance testing. The workbook is its operational form: a suite of executable test cases, not a statement of principle.

Factory acceptance, VABF and VSR

In French projects, especially public-sector or fixed-price ones, acceptance is often split into successive stages:

• Factory acceptance (recette usine): the supplier tests its own software, in its own environment, before delivering it.
• VABF (vérification d'aptitude au bon fonctionnement, a check of fitness for correct operation): the customer checks, in an environment close to production, that the software meets the functional requirements. This is where the workbook is used the most.
• VSR (vérification de service régulier, a check of regular service): the software runs in production, in real conditions, for a period defined in the contract. Its stability is observed before final acceptance is declared.

Not every organisation uses these acronyms. In an agile team, acceptance is often done sprint by sprint, on the completed user stories. The need stays the same: a clear list of what must be verified and an honest record of what has been verified.

Acceptance testing and other testing: what is the difference?

Unit, integration and system tests are run by the team building the software, to find defects as early as possible. Acceptance testing is run from the customer's point of view, to decide whether the software can be accepted. The two overlap: a good share of acceptance test cases look like system tests. The difference lies in the question asked. The team's tests ask "does it work?", acceptance testing asks "is this what we ordered?".

Who writes the test acceptance workbook?

The workbook belongs to the customer, since the customer is the one who declares acceptance. In practice, it is written by the business-side project manager (often called MOA in France), the Product Owner or key users, frequently with the help of a software tester or a QA consultant who masters test design techniques. The supplier may propose a first version, but the customer reviews and validates it: otherwise, the supplier decides what it will be judged on.

Ideally, writing starts as soon as the requirements are stable, well before delivery. Writing test cases early exposes vague or contradictory requirements at the moment when they cost the least to fix.

The structure of a test acceptance workbook

A test acceptance workbook fits in a table. Here are the columns we recommend, and those of the template to download:

Depending on the project, you add an environment or browser column, or a campaign column when the same workbook is used for several deliveries.

Example of a filled-in test acceptance workbook

Take a simple feature: logging in to a customer area with an e-mail address and password, plus the "forgot password" link. Here are four test cases, as they would appear after a first campaign:

Three lessons from this small extract. Test case TC-002 shows why you test errors: the main path works, but a simple wrong password crashes the application. Test case TC-004 is not a software failure: it is blocked by the environment, and counting it as a Fail would skew the results. Finally, each expected result is verifiable without interpretation: a precise message, a measurable delay.

Method: writing and running acceptance testing step by step

1. Gather the requirements. Specifications, user stories and their acceptance criteria. Number them if that is not already done.
2. Split by business journey. Group test cases by feature or by user journey (order, pay, get a refund) rather than by screen.
3. Write the main-path test cases first, where everything goes well, then the error cases and the boundary cases. Classic techniques help you not to forget anything: equivalence partitioning, boundary values, decision tables.
4. Fix the test data and check that it exists in the acceptance environment before the campaign.
5. Have the business review the workbook: a test case nobody understands will be badly executed.
6. Run and record as you go: actual result, status, date. Never reconstruct a workbook from memory at the end of the day.
7. Open a defect for each Fail, with the steps to reproduce, a screenshot and the severity, then enter its number in the workbook.
8. Rerun after the fix the test case concerned (confirmation testing) and its neighbours (regression testing), then take stock with the summary: progress, pass rate, open defects.

The review is there to support a decision. You set the acceptance criteria in advance, for example "no open blocker or major defect, all priority test cases executed", and you compare the summary with these criteria. This is more solid than a general impression.

Common mistakes

• Steps that are too vague ("test the login"): you cannot know what was really verified.
• A missing expected result, or one written after the fact: you end up validating what the application does, not what was ordered.
• Only main-path test cases: most defects hide in input errors, access rights and boundary cases.
• Free-text statuses ("almost OK", "to review"): no reliable summary is possible.
• Test cases with no link to a requirement: you no longer know whether everything was covered, nor what can be removed.
• A workbook never updated when the requirements change: it ends up testing an application that no longer exists.

From the test acceptance workbook to automation

A well-written test acceptance workbook is also the best starting point for automating tests (FR). Precise steps, fixed data and a verifiable expected result: this is exactly what a test script needs.

Not everything should be automated. The good candidates are stable test cases (the feature no longer changes every two weeks), frequently rerun ones (at every delivery, as regression testing) and high-stakes ones (login, payment, calculations). Test cases that call for human judgement, such as ergonomics or the readability of a document, stay manual.

In the example above, test cases TC-001 to TC-003 turn directly into Playwright tests that run at every delivery, and the server-side checks fall under API tests. To find out whether the effort is worth it on your project, the test automation ROI calculator compares the time spent on manual acceptance testing with the cost of writing and maintaining scripts.

Need a tester to write and automate your acceptance testing? ADC also supports companies with QA tester recruitment: sourcing, technical interview and shortlist.

Frequently asked questions