Characteristics of Testable Requirements

In my career I've seen many projects fail in the testing phase. In many of these cases failures were unjustly attributed to testing teams, rather than a requirements management process that failed to consider the importance of building testable requirements using proven structured disciplines.

Building testability into requirements should begin with the business definition of the requirements. Software modeling techniques have proven helpful in this respect in projects that I've managed. The discipline and structure imposed by modeling helps minimize the risk of requirements deficiencies and contradictions. The actions, behavior rules, and usage rules of modeling can be described utilizing:

·        Natural Language

·        Logic Tables

·        State Models

·        Structured English

·        Cause and Effect diagrams

When reviewing a well-documented requirement for testability, the tester determines if each requirement can be tested objectively by answering the following questions:

 Who

- initiates an action?

- is notified of the conclusion of an action?

What

- triggers an action?

- happens when the trigger is received?

- what is produced as an output?

Where

• does the output go?
• does the input come from?
• does the trigger come from?
• is the action performed?

When

• does the input arrive (and how often)?
• does the action get performed after the input received?
• does the output get produced?
• does the output get delivered?
• does the action not occur?

How much

• accuracy is required in the outputs?
• precision is requested in the calculations?
• precision is in the input?
• times can occur before output is produced?

Why

• is the input necessary?
• is the output necessary?

How

• is the output to be completed?
• how is the output trigger initiated?

When reviewing requirements for testability, the following characteristics should be considered:

•  Unambiguous - The requirement has the same interpretation for the client, the requirements determiners, and the requirements recipients. Even though the requirement is stated in natural language, it is important to ensure that the requirements have the same meaning to all stakeholders. 
• Correct - The requirement accurately describes a feature of the project’s product. The content and grammar of the statement is correctly phrased. Each item is error-free.
• Complete - The requirement is a complete thought that can stand-alone and does not depend on other requirements. It needs no further explanation and includes all essential functionality.
• Consistent - The requirement does not duplicate or contradict another requirement. Contradictions are issues that must be resolved by the client.
• Feasible/Achievable - The requirement is achievable at a cost that is within the project budget and other known constraints. 
• Modifiable - Changes to requirements are processed easily and completely using change control methods. Change control ensures that modifications are evaluated and implemented in a consistent manner. 
• Prioritized - The requirements are evaluated and assigned a relative and explicit importance. Relative importance rates each requirement against the others, based on criteria defined by the client, for example cost, duration, risk, and business benefit. Prioritizing the requirements will enable risk based testing (I have another article on this in my blog) to take place so that in the event that testing must complete before all cases have been exercised the high and then medium and then low priority case will have been run according to priority.
• Traceable - The requirement is recorded in such a manner as to make it traceable.  Traceability to test cases and test results is necessary to ensure all requirements are being covered by the test.
• Verifiable - It is possible to determine that the requirement correctly and completely meets client specifications. Acceptance criteria is established for each requirement to state how the requirement has been met, what method will be used, and who performs the verification. Client sign-off of the requirements statement, acceptance criteria, design, acceptance test results, and implementation ensures the client has confirmed the satisfactory completion of the requirements.

In summary, improving the overall quality of a requirement improves its testability and the overall cost-effectiveness and value of the testing lifecycle. Speed to market is important, but not by cutting corners in the requirements and testing process.