OLE QA Guide - Writing Acceptance Criteria
- Jain Waldrip (Unlicensed)
Writing Acceptance Criteria
It is your duty as a tester to review the Acceptance Criteria section, signing off on the document only when it meets your approval. This article offers an introduction to the process of writing acceptance criteria and ensuring that all the needs presented in a given Functional Specification document are represented in the Acceptance Criteria section.
It may be the case that you are testing a Functional Specification with pre-written acceptance criteria. If this is the case, please use this article as a general guide to ensuring that the criteria as written provide full coverage of the needs expressed in the Functional Specification document. Â Additional concerns can be directed to the Testing Coordinator or the Functional Specification team, who will make a decision concerning whether an Enhancement (non-PP) should be created to establish additional functionality.
Purpose
The purpose of the Acceptance Criteria section is to ensure that all functionality requested in a Functional Specification document are collected into quantifiable statements. Acceptance criteria should summarize all the operations requested from the software.
General Structure
The Acceptance Criteria section of a Functional Specification document generally consists of a bulleted or numbered outline. The outline generally follows the requirements of the Workflow section of the Functional Specification document.
The individual criteria are expressed in direct, clear statements of what the system should do at each outlined step in the workflow. These statements generally refer directly to what a user should be able to do (e.g., "A user must be able to resubmit a purchase order to the vendor.").
Subsections are generally included to indicate what additional steps a user might take, or what output should be expected from the system (e.g., "The system must transmit an EDI file to the vendor containing the changes to be made to the purchase order.").
Coverage
User Stories
It is important that the acceptance criteria completely address the needs of the system. The first section to cover with acceptance criteria is the User Story section, which should consist of statements of a library staff role followed by a necessary duty to be performed by that staff member (e.g., "As a Unit Manager/Supervisor, I process payment of invoices and apply to individual order records.").
Workflow
The acceptance criteria should also cover any specific, explicit requirements of the Workflow section of the Functional Specification document. The Workflow section is meant to contain a narrative description of the process being established by the document, and so may vary in form and content. It should, however, always contain statements describing actions to be taken by staff members of various roles throughout the workflow. These statements must be collected and distilled in the Acceptance Criteria section.
Implicit Criteria
The acceptance criteria must also cover any implicit requirements in the specification. If, for example, a Functional Specification document says, "A user with adequate permissions should be able to receive a purchase order containing an item in hand," then the acceptance criteria statement will begin with a statement like, "A user in the receiving role must be able to initiate receipt of a purchase order." That statement will be the heading of a section which should also include the implied acceptance criterion, "A user who does not belong to the receiving role must not be able to initiate receipt of a purchase order."
Examples
The examples included here, except where otherwise noted, are drawn from the retired article Acceptance Criteria, Test Scripts & Testing, by Nora Roggeveen-Sams.
Example 1
User Story: | Acceptance Criteria: |
|---|---|
As a Data Creator, I create purchase orders for a resource linked to a bib and/or item record (create PO). |
|
Example 2
User Story: | Acceptance Criteria: |
|---|---|
As a Selector, I need a holding area for items for potential future actions (Order Holding Queue). |
|
Operated as a Community Resource by the Open Library Foundation