Requirement Level Testing


[ * HOME * ][ * PAGE UP * ]

A good requirement document will range from abstract general requirements to very specific requirements. The latter are easy to test, the answer is usually binary. The former are a challenge because they are subjective, and define the spirit of the project. E.g. performance speed is an example for a specific requirement that can be checked in an objective manner. A requirement to have "an easy and appealing user's experience" is a subjective requirement.

Specific requirements may be tested either manually or by testing automata. A typical requirement will define the communication throughput of the system. Such throughput should be measured over time and averaged. So a testing plan should measure the throughout over sufficient span of time and then compute a representative average.

Abstract requirements are often a matter of judgment and are best handled by having several opinion sources. These diverse opinion sources must be combined in a smart way. The BiPSA system was developed for this purpose. It is described in the book "The Unending CyberWar" (see See Prof. Gideon's books .)

Most test programs go no further. Alas, experience teaches us that requirement documents for serious software should also be tested versus the higher up goal of the stakeholders. E.g. an election software was rejected when it was determined that the integrity of the elections could not be verified by average people, only computer specialists could do it, and it was judged to be too restrictive.