Requirements / User Stories, Acceptance Criteria and Acceptance Tests
During requirements elicitation, business analysts and testers (possibly together with developers) should begin to create specific acceptance criteria and develop acceptance tests as a joint effort. This ensures that there is a mutual understanding of what “acceptable” means from the business, development, and testing perspectives, right from the beginning of the project.
Acceptance criteria relate directly to a specific requirement or user story. They are either part of the detailed description or an attribute of the related requirement. If user stories are used, acceptance criteria are part of the user story’s definition and extend the story.
In all cases, acceptance criteria are measurable criteria, formulated as a statement (or a set of statements), which can be either true or false. They are used to check whether a requirement or user story has been implemented as expected. Acceptance criteria represent the test conditions which determine “what” to test. They do not contain the detailed test procedures.
In Agile development, the INVEST criteria define a set of criteria, or checklist, to assess the quality of a product backlog item. Product Backlog Item (PBI) may be used in a Scrum backlog, Kanban board or XP project, commonly written in user story format, but not required to be.
| Letter | Meaning | Description |
|---|---|---|
| I | Independent | The PBI should be self-contained, in a way that there is no inherent dependency on another PBI. |
| N | Negotiable | PBIs are not explicit contracts and should leave space for discussion. |
| V | Valuable | A PBI must deliver value to the stakeholders. |
| E | Estimable | You must always be able to estimate the size of a PBI. |
| S | Small | PBIs should not be so big as to become impossible to plan/task/prioritize within a level of accuracy. |
| T | Testable | The PBI or its related description must provide the necessary information to make test development possible. |
The following good practices should be considered when writing acceptance criteria
- Well-written acceptance criteria are precise, measurable and concise. Each criterion must be written in a way that enables the tester to measure whether or not the test object complies with the acceptance criterion.
- Well-written acceptance criteria do not include technical solution details. They concentrate on the question "What shall be achieved?" rather than on the question "How shall it achieved?".
- Acceptance criteria should address non-functional requirements (quality characteristics) as well as functional requirements.
Acceptance test cases are derived from acceptance criteria. These tests specify how the verification of the acceptance criteria should be performed.
0 comments:
Post a Comment