system verification in software testing
The purpose of verification is to verify that the product works according to the specifications produced in the feasibility study and the phase.
There are essentially two ways to accomplish this:
- Testing the system, i.e., running the system on certain inputs and observing the behavior of the system.
- Proving the correctness of the system.
The first method can’t ensure the correctness of the system. However, if a problem is found, one can be certain that is not correct.
The second method is able to ensure the correctness of the system. Unfortunately, it requires a formal specification of what the system is supposed to do. Such a specification is likely to be as large and as error-prone as the system itself. The specification itself thus needs verification.
Testing although unable to cover all possible cases is able to make sure that a large subset of casework, thus increasing our confidence that the system works as specified.
Providing the correctness of the program is transformed into increasing the confidence in the structure of the system needs to be done in a well-disciplined and structured way. Therefore, the verification activity must be prepared during the specification and coding activities. It’s hard, if not impossible, to have any level of confidence in a product that is badly structured.
Finally, Verification is used in order to verify other aspects of the system, e.g. performance. This aspect is particularly important in real-time systems where performance may determine whether the system is correct or not.
Verification must be an integral part of the design and coding activities. However, there are tasks that can be thought of as particular to the verification activity.
Two major tasks are involved in verification.
Testing the program is a pure verification activity. In order for tests to be useful, they must be put in the system. It is not sufficient to try a few cases and conclude that it works. On the other hand, it is impossible to cover all possible cases. A practical rule is the following:
Make sure each statement of the system has been executed at least once by at least one test case.
Clearly, if this is not the case, one can’t pretend to have tested the system.
But even if you have executed every statement in the system, it is not clear that the system corresponds to the specification. For instance, if some cases simply are not treated at all, though specified in the requirements specification, then executing all statements will not help, since no statement treating the omitted case is present in the code. Therefore, the test must always be a combination of testing the code present in the system and testing the system with respect to the requirement specification.
Testing can be done on each separate module of the system. In that case, it is called module testing.
It can also be done on the entire system. In that case, it is called system testing.
System testing often involves putting together a few modules at a time and making sure that the subsystem is tested before a new module is added. For that reason, system testing is sometimes referred to as Integration.
An error discovered during the module test usually indicates an error during the coding phase. Errors of this sort are in general not too hard to correct. An error discovered during integration sometimes indicates a design problem and may be extremely hard to fix.
Testing methods fall into two categories. black-box testing and white box testing.
Black-box testing is done without the knowledge of the internal structure of the system and only external behavior is tested.
White-box testing means the structure of the product is taken into account when the tests are constructed. That way the hope is to discover cases that are hard for the system to handle.
Black-box & white-box testing may be applied both to module and system tests.
Originally published at https://www.csmates.com.
