...
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.
...
| Anchor | ||||
|---|---|---|---|---|
|
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."
| Anchor | ||||
|---|---|---|---|---|
|
Examples
The examples included here, except where otherwise noted, are drawn from the retired article Acceptance Criteria, Test Scripts & Testing, by Nora Roggeveen-Sams.
...