PDTPRO

Another important but difficult term to clarify is what is meant by a testable condition.

In order to be able to assess if an output meets or exceeds a given expectation, an expectation itself must be stated in testable terms. This means that when the characteristics of an output under test are compared against the expected characteristics, they can be matched in a clear and unambiguous way. You would not request that the answer to a calculation of(l + 4) is to be an “appropriate” amount. To be testable, you would specify the answer as a single value like 5 or as a range between 0 and 10 if the exact answer is not known. If the result of the test were anything other than 5 or a number within the specified range, the test would unequivocally fail and you would record the variance. The example, of course, is trivial but it serves to illustrate the point.

While you may strive to have requirements stated in testable terms, it may not always be possible. The required level of detail when you document and test the requirements may not yet be available. The process of requirements specification and external design should evolve the functional request from a collection of imprecise statements of user needs to testable user specifications. Even though the root of the word specification is specific, achieving specific requirements is an extremely challenging exercise. At every point in the specification process, you can check the “testability” of the requirement or specification by ensuring it is S.M.A.R.T..

This acronym stands for:

• S - Specific
• M - Measurable
• A - Attainable or Achievable
• R - Realistic
• T - Timely

These specifications will form the basis for the criteria upon which the system is tested and ultimately accepted by the system purchaser and end-user.