¶ … top-down and bottom-up programming, testing in these two specific situations is obviously adapted to the specifics of each type of programming.
In this sense, because top-down programming implies that the initial program's functionality is divided into a series of subroutines and each further divided into sub-functions until the smallest remaining unit, testing in this case will be applied to each component in part and will address the functionalities of each unit. The tester, in many cases assimilated to the programmer here, will check that the graph he has designed actually reflects the mathematical requirements or that the Save button actually does what it is supposed to.
On the other hand, because of the particularities of bottom-up programming, bottom-up testing will comprise the entire system's functionality, being referred to, in this case, as integration testing
. In my opinion, such testing may prove more difficult because of the encompassing view it needs to have. In this sense, the tester is not interested only in discovering the particular components' functionality, but also needs to see how these components fit together in the overall functionality of the application. The second type of testing may, in this sense, include the first.
A test script is a most helpful element in both cases, but particularly in the latter. Indeed, this points out to...
It is also a simple way to keep track of things that work or those that may not and follow through on the debug.
2. In order to best address this question, we need to point out that, in theory, there is a large spectrum of programming errors, ranging from errors in the computer code (compilation and linking errors, execution time errors), truncation errors, resolution errors, round-off errors or data errors
In the case of to-down testing or component testing, the fact that each component's functionality is verified implies that compilation errors are easiest to discover and later correct. Indeed, any syntax error in the modules is equivalent to a compile-time error, at which point the programmer will not be able to complete an executable that can be used.
In the case of bottom-up testing or integrated testing, the fact that the entire functionality of the program is verified means that the compile-time error is probably among the last things one may consider in the case of a malfunction and will proceed to checking overall problems that may have appeared.
On the other hand, the data errors may seem more likely to be discovered earliest in the case of bottom-up programming. In my opinion, the reason for this is closely linked to the overall functionality.
Indeed, if there is…
