In many interviews, this question is asked frequently. So I am writing the answer which I believe is correct.
Testable Requirements: A requirement which is unambiguous and clearly specifies the behavior.
Non-Testable Requirements: A requirement which is very interpretive and do not specify exact behavior of the software .
Examples of Testable & Non-Testable Requirements:
1. All Users are allowed to post Only 5 Questions per day in this Forum - Clearly specifies the Limit allowed Whereas Users Reply to a question is made visible to all board members as soon as possible - Does not state Where/How it will be made visible and does not specify a "value" instead of "as soon as possible".
2. Consider the Application "X" which have A,B,C modules which makes the Full application "X". All the requirements are mentioned in the Design documents. When Developers start working on the module A and the build A is availble for testing, then Module A is Testable and we can't test module B or C, so based on the development plan QA Analyst will prepare Test Strategy document and will give clear details on what requirements need to be tested and what should not.
3. The user interface must look modern and attractive. The application must be fast. The user interface must be very responsive and so on.
The way many people write performance requirements are untestable (think - "performance shall be fast", "shall be google speed", "easy to use", etc). These can be fixed by the addition of detailed fit criteria to clarify how you will test them.
Testable Requirements: A requirement which is unambiguous and clearly specifies the behavior.
Non-Testable Requirements: A requirement which is very interpretive and do not specify exact behavior of the software .
Examples of Testable & Non-Testable Requirements:
1. All Users are allowed to post Only 5 Questions per day in this Forum - Clearly specifies the Limit allowed Whereas Users Reply to a question is made visible to all board members as soon as possible - Does not state Where/How it will be made visible and does not specify a "value" instead of "as soon as possible".
2. Consider the Application "X" which have A,B,C modules which makes the Full application "X". All the requirements are mentioned in the Design documents. When Developers start working on the module A and the build A is availble for testing, then Module A is Testable and we can't test module B or C, so based on the development plan QA Analyst will prepare Test Strategy document and will give clear details on what requirements need to be tested and what should not.
3. The user interface must look modern and attractive. The application must be fast. The user interface must be very responsive and so on.
The way many people write performance requirements are untestable (think - "performance shall be fast", "shall be google speed", "easy to use", etc). These can be fixed by the addition of detailed fit criteria to clarify how you will test them.
