Requirement testability

How can you say whether a requirement is a testable or not?Please answer my question.

Well, in my opinion, if the Client has a requirement that they feel needs to be tested, no matter how broad it is, you have to find a way to test it and deliver results. Sometimes you have to divide their requirements into child requirements to efficiently drive your test effort and sometimes you have to clarify its significance with the SMEs or at times, the Client itself.

Hi Kavitha,

In General, when clients are providing the requirements it will be prepared and analyzed by the subject matter expertise before it goes to the Design team. So, it has a very very minimal chance to say that the requirement is not testable. As the design and coding were done based on the requirement hence the testing can also be done.

But to answer your question, we can say a requirement is not testable if we are not able to generate or identify test scenarios out of it.

Regards,
Ganesan

Thankyou ganeshan

Most requirements should be testable. If this is not the case, another verification method should be used instead (e.g. analysis, inspection or review of design). Testable requirements are an important component of validation.

Certain requirements, by their very structure, are not testable. These include requirements that say the system shall never or always exhibit a particular property. Proper testing of these requirements would require an infinite testing cycle. Such requirements are often rewritten to state a more practical time period.

Un-testable non-functional requirements may still be kept as a documentation of customer intent; however they are usually traced to process requirements that are determined to be a practical way of meeting them. For example, a non-functional requirement to be free from backdoors may be satisfied by replacing it with a process requirement to use pair programming. Avionics software with its complicated safety requirements must follow the DO-178B development process.

Testability is essentially a form of clarity, which indeed is necessary but can divert attention from other important issues. A requirement can be testable yet incorrect; and assessing testability often will not detect incorrect requirements. Moreover, testability is totally irrelevant with regard to a requirement which has been overlooked. Mere analysis, inspection, or review alone will find some of these issues but generally is far weaker than usually is realized. There are more than 21 more powerful ways to test or evaluate requirements adequacy and more than 15 ways to strengthen