Maintaining Testable Requirements and Acceptance Criteria
Once a testable requirement or acceptance criteria have been “created,” there is a tendency to assume that the task can be considered completed. Because that may or may not be true, it is better to continue to pay attention to testability.
The process for maintaining testable requirements can include:
1. Create a prototype of the user interface
The best communicator of intentions is to show the stakeholders a static mock-up of the future user interface (UI). This also needs to be managed, as every time stakeholders look at a UI, they will identify more improvements. When the prototype is “good enough,” baseline the UI and record further feedback for future versions.
2. Plan for test implementation with a test matrix
A test matrix is a list of the testable requirements with a basic technique identified for each. The basic techniques are: black box, white box, code inspection, independent analysis, or not testable. If acceptance criteria are available, list them instead of the techniques. If they are not available, created them from the additional descriptive information in the requirements documentation.
If a tester cannot choose one or more basic technique, then they know where they need more information. The test matrix can also be used as the start of the requirements verification matrix, if requirements are to be traced later to test cases for a completeness check.
3. Utilize a requirements management tool
The tool can be specific to requirements, part of a test management tool, a spreadsheet, or even just a Word table. Having a tool makes maintenance much easier because it supports the collection of useful metrics (e.g., scope creep: . A high percentage of requirements added after the baseline is a sure sign stakeholders don’t really know what they want.) and can be the basis for tracing into test cases for a test coverage completeness check.
4. Maintain testable requirements as they change over time
As obvious as this sounds, maintenance is sometimes dumped in an effort to get more out the door quickly. Skipping this step will always cost in the long run (e.g., when there is staff turnover) if not done successfully.
In IT, success is hard to gain and easy to lose. Continuing to pay attention to maintaining testable requirements will keep a project on the pathway all of the way to successful deployment to production.
