Creating Testable Requirements and Acceptance Criteria
Testable requirements, or acceptance criteria, are the successful communication of an expectation between its originator and the potential stakeholders.
Creating testability is iterative. The steps can be conducted informally, such as in a Scrum meeting, with minimal documentation for a stable project (when the stakeholders all know each other and the application well), or with more formal reviews and documentation (like for projects that will be audited in the future).
Follow these steps to facilitate a successful process.
1. Identify all stakeholders
This first step is often the most neglected, leading to problems downstream. A list of potential stakeholders can include:
- Developers, so that they know what to build
- All independent test teams, including quality assurance, user acceptance testers, performance, and security
- Managers, who need accurate assessments of “passing” for tests to make informed decisions to deploy to production
- Auditors, who, like the managers, need an accurate definition of “passing” for tests
2. Determine the level of detail each stakeholder needs
The required level of detail depends on multiple factors, including the certainty of the originator and the degree of mutual understanding between the originator and each stakeholder. Create the level of detail that is specific enough to support the most demanding stakeholder. If stakeholders need different levels of detail, the requirements can be separated into multiple levels.
A common practice is to have two levels, e.g., “business” and “technical” requirements levels, or “requirements” and “derived requirements.” They do not need to be recorded in the same medium. The business processes can be documented using flowcharts in Visio with swim lanes for each type of user. The detailed requirements in a requirements specification can be included later in an automated tool. For an agile project, the business requirements can be in the use cases, and the derived requirements can be the acceptance criteria.
3. Create drafts
Next, create a first draft for each type of requirements documentation. They do not need to all be done at once. Individual use cases can be created before acceptance criteria, and business requirements can be detailed before technical requirements.
4. Conduct reviews, adding clarity as needed
Each stakeholder must judge what is enough information to support testability. Testability usually requires the addition of specifics and quantification, such as exact numbers and particular browsers to be supported. Reviews can be done by peers through a defined process, an informal walk-through of user stories, or emailed questions and comments.
Because it is normal to go forward without having all questions answered, the recognized unknowns can be identified in the documentation. One possibility is to use “TBD” (to be developed) in the text of the document. Another is to have an Open Issues table listing the issues, date of origination, who opened the issue, resolution, and date of closure. This table will serve to document the issues that never got resolved.
Many testers struggle with the starting point of creating testable requirements and acceptance criteria. But once you succeed, you know the processes that can build and test a system implementing “good” requirements.
Claire Lohr will be the instructor for the Software Tester Certification—Foundation Level training class at STARWEST, in Anaheim, CA, October 12–17, 2014.
