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.

Top of Page
Top of Section

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.

Top of Page
Top of Section

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.").

Top of Page
Top of Section

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.").

Top of Page
Top of Section

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.

Top of Page
Top of 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."

Top of Page
Top of Section

Examples

The examples included here, except where otherwise noted, are drawn from the retired article Acceptance Criteria, Test Scripts & Testing, by Nora Roggeveen-Sams.

Top of Page

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).	A user must be able to allocate multiple fund codes across line items and within each line item being ordered. An Item record is created for every PO line item. I must be able to place orders to vendors in USD or foreign currency.

Top of Page
Top of Section

Example 2

User Story:	Acceptance Criteria:
As a Selector, I need a holding area for items for potential future actions (Order Holding Queue).	A selector must be able to search Requisitions, and then select requisitions to calculate totals across multiple requisitions selected. A selector with proper permissions should be able to "take" or "assign" requisitions to Selectors.

Top of Page
Top of Section

< Back

Home

Next >

Browser not supported