OLE QA Guide - FSPECs and AC
- Jain Waldrip (Unlicensed)
Functional Specifications
What is a Functional Specification?
A Functional Specification is a document that elaborates upon a user-derived story to explain the needs of the OLE application. Functional Specifications begin as user-derived stories about specific software needs. Users try to describe, as accurately and thoroughly as they can, what sort of workflow the software needs to accommodate.
Workflow needs in a Functional Specification are frequently represented in a flow chart, accompanied by a narrative elaboration. Users will also describe the output that needs to be generated by the system upon successful execution of the workflow, as well as alerts and error messages expected upon unsuccessful execution of the workflow. A detailed description of output needs includes the information expected, as well as an indication of where success and failure messages are needed.
Functional Specification Structure
Functional Specifications tend to have a very organic structure. While the OLE Core Team works to encourage standardization and structure in Functional specifications, we also prefer that they be as complete as possible. To that end, there is quite a bit of room for elaboration in a Functional Specification document.
Details are often described in narrative format. Questions are asked and answered in Functional Specifications, and this generally results in extra snippets of information being added to the main body of the document, sometimes with less structure than might be anticipated. Additional diagrams may be added, as well. Although structured, a given Functional Specification tends to grow in an ad hoc manner until it fully summarizes the desired functionality of a given part of the OLE system.
Acceptance Criteria
What are Acceptance Criteria?
Acceptance criteria are statements of what will be tested to ensure that the functionality requested in a Functional Specification is adequately delivered. The Acceptance Criteria section of a Functional Specification generally consists of a series of one-sentence statements explaining, in summary form, what a user must be able to do or not do in order for the software to be considered functional.
Acceptance Criteria Structure
Where the Functional Specification document itself is somewhat organic, and tends to grow in structure and content until it is finalized, the acceptance criteria serve as a rigid cyrstallization of the essence of the Functional Specification document. Acceptance criteria are fixed and definite, and bring a structure through which testers and the QA Team can understand the exact needs of the Functional Specification.
Acceptance Criteria and Test Cases
Test Cases are built around a single assertion from the Acceptance Criteria. More often than not, this means that each sentence in the AC section represents single acceptance criterion, and will generate a single Test Case. This statement of what is to be tested should be included at the beginning of a Test Case's description.
To ensure that all the requirements of a given Functional Specification document have been fulfilled, you may want to compare your Test Cases to the acceptance criteria to see if there are any statements which have not been turned into Test Cases. If not, you have complete coverage of the Functional Specification you are testing.
Operated as a Community Resource by the Open Library Foundation