TOP-DOWN SOFTWARE TESTING TECHNIQUE

Concepts: Top-down software testing is an incremental unit testing method which begins
by testing the top level module, and progressively adds in lower level
modules, one at a time.
The idea is simple. Begin with the highest-level module, using stubs to
stand in for any module it invokes. For the next test, add in any module
which satisfies the following rule:
THE GOLDEN RULE OF TOP-DOWN SOFTWARE TESTING
In order to test a unit, you must first have tested at least one module
which calls it. (Exception: the top-level unit, which is not called by any
module.)
In other words, you've done top-down testing correctly, if you never
have to write a driver.
ADVANTAGES
All the advantages listed for incremental testing apply. As well:
	There is less overhead than with the big bang method: No
drivers need to be written when top-down testing is used.
	Top-down testing provides an early working model of the
program. This model can be presented to the user for an early test of
the system. Design flaws can thus be detected early and corrected.

 DISADVANTAGES
	Stubs still have to be written. While automated tools do exist
which ease the writing of both stubs and drivers, stub tools are harder
 to find. As well, stubs are difficult to write since they must simulate
the setting of output parameters in a way meaningful enough to avoid
 introducing new errors yet simple enough to be a stub and not the real
thing.

	It is hard to farm out top-down software testing to independent testing
teams. Why? Each module can only be tested after a module that
invokes it has been tested.

Nevertheless, top-down software testing is a popular methodology and works quite
well. And it meshes well with other top-down portions of the SDLC. For
example, if the programmers are writing the code in a top-down
sequence, as is often the case, each module could be tested as soon as
 coding is complete.


THE STEPS OF TOP-DOWN SOFTWARE TESTING

 To perform top-down software testing, follow this procedure:

1) Start with the top-level module. Create a test system consisting of the
top module and stubs for all the modules it invokes (those attached below it in the structure chart). 
Test this system. Do not proceed until all errors have been removed.

2) Next, choose any of the modules invoked by the top module just
tested. To create the next test, begin with the system you created in
the last test. But replace the stub of the chosen module with the real
module. As well, add in stubs for any modules invoked by the chosen
one. Run this test system. If any errors occur, they will be due to the
 new module's internal logic or its interface with the module that invoked it.

3) Choose the next module to test. This may be another module invoked
 by the top module or a module invoked by the one just tested in step
2. (Guidelines for selecting a module when a number of modules are
 possible, are discussed below.) Replace the chosen module's stub
 with the real thing. Next, add in stubs for any modules invoked by
the chosen one. Test this system.

 4) Continue incrementally adding and testing modules following the rule
 for top-down testing until all modules have been tested.


GUIDELINES
In steps 2 and 3, the software tester could choose from a number of modules that
satisfy the rules of top-down testing. The following guidelines should be
applied:
A) Test critical modules as soon as possible. A critical module might
be an unusually complex one, one that incorporates some new technology, or one that is similar 
to a module that has caused problems in the past.
B) Test I/0 (input/output) modules as soon as possible. The tests will be difficult to
run if I/0 modules are not incorporated early into the test system.
The sooner you incorporate input modules, the sooner your test will
be able to handle real records. Likewise, the sooner you incorporate
output modules, the sooner you will be able to easily observe the
effects of your test. Examples of I/0 modules are ones which read
records from a file, get input from the user, write information to disk,
or print information on reports.

On this page I put DESCRIPTION OF TOP-DOWN SOFTWARE TESTING TECHNIQUE FOR testers.