In many ways, bottom-up testing is the opposite of top-down approach of testing; while the advantages of top-down testing become disadvantages of bottom-up testing and, conversely, the disadvantages of top-down testing become the advantages of bottom-up testing. With this in mind, we will briefly discuss the bottom-up testing strategy.
This process starts with terminal modules within the software app (i.e., modules that do not invoke other modules). As before, after testing the modules, there is no eligible procedure for defining the module to be tested in increments. The only rule is that the next module calls the previously tested modules.
If we look at the Figure above, then the first step is to test several or all E, J, G, K, L and I modules in series or in parallel. Each of them requires its own driver module, that is, the module that contains the fixed test data, calls the module under test and displays the output results (or compares the actual output with the expected results).
Unlike stubs, there is no necessity with multiple versions of a driver, so it can iteratively call the module under test. In most cases, drivers are easier to develop than stubs.
As in the previous case, the factor that affects the sequence of testing is the critical nature of the module. If we decide that the modules D and F are the most critical, then the intermediate state will correspond to the Figure above. The next steps may be to test Module E, then Module B, combining B with the pre-tested modules E, E ‘, J.
The disadvantage of this strategy is that it lacks concept of a run-time program’s structure at an early stage of the testing. Indeed, there is no work program until the last module is added (in the example, module A), and this is a complete program. Although I / O functions can be checked before the entire program has been assembled (the I / O modules used are shown in the Figure above), the advantages of early skeletal program are absent.
There are no problems related to the impossibility or difficulty of creating all the test situations in the top-down model. The driver as a test tool is applied directly to the module being tested; there are no intermediate modules to be concerned about. Analyzing other problems that arise in top-down testing approach, you can notice that with top-down testing, you are unable to make an unreasonable decision to overlap testing and design processes, since bottom-up testing cannot be started until the lower-level modules are designed.
There is something that may be of interest to you and the issue is a cost-effective app testing service from third-party partners. It can be useful to find lots of errors in the program being developed before it is made live.