The incremental test process assumes that the modules are not tested separately from each other, but each module is examined individually, then modules are integrated one by one and testing is carried out at each step, namely the system undergoes testing after the components are subsequently integrated.
The incremental process can be performed heap of times, so it is early to consider a particular step-by-step procedure for the program shown in the Fig below. The key aspect is whether we should start testing – at the top or bottom of the program. However, let us assume that testing starts from the bottom level modules. Initially, it is possible to perform the testing of the E, C and F modules sequentially or in parallel (for example, three people can do it). For each module, the driver must be created; stubs are not needed in this case. The next step is testing of modules B and D, but not independently, but in conjunction with the E and F modules, respectively. In other words, to test the module B, a driver is developed, and the pair B-E is tested. The step-by-step process is carried out until the last module, in this case module A, is added to the set of tested modules. Note that this procedure can be performed from top to bottom.
If you are tired of paying much for local qa services it is time to choose outsourced testing which is cost effective and works really well!
Already at this stage we can make some generalizations:
- Integration testing is time and labor-consuming work. For the program shown in the Fig above, you need to create five drivers and five stubs, taking into account that the high level module does not need a driver. In bottom-up incremental testing, only five drivers are required, and in top-down approach you need only five stubs. Labor costs are reduced due to the fact that when using top-down approach, the tested modules function as stubs, and in bottom up testing they function as drivers.
- In step-by-step testing, errors in the interfaces between modules are detected earlier, since the program is assembled early. In contrast to this, in integration testing, the modules “do not see each other” until the last phase of the testing process.
- In step-by-step testing it is easier to debug programs. If there are errors in the intermodule interfaces, and usually it happens, then in integration testing, they can be detected only when the program is completely assembled. At this point, it is enough to localize the error. It is difficult to do, because an error can be anywhere in the program. On the contrary, in step-by-step testing, these types of errors are caused by the module that is lastly added to the integrated and tested modules.
Add Comment