software testing strategies in software engineering

Software Testing Strategies

Software testing strategy provides a road map for the software developer, quality assurance organization, and the customer.

A strategy must provide guidance for the practitioner and a set of milestones for the manager. Progress must be measurable and problems must surface as soon as possible. 

Common characteristics of software testing strategies include the following:

Testing begins at the module level and works outward toward the integration of the entire system.

Different testing techniques are appropriate at different times.

Testing is conducted by the developer and, for large projects, by an independent test group.

Testing and debugging are different activities, but debugging must be accommodated in any testing strategy.

In order to conduct a proper and thorough set of tests, the types of testing mentioned below should be performed in the order in which they are described.

  • Unit Testing
  • Integration Testing
  • Functional Testing
  • System and Acceptance Testing

Unit Testing

The unit testing procedure utilizes the white-box method and concentrates on testing individual programming units. These units are sometimes referred to as modules or atomic modules and they represent the smallest programming entity.

Unit testing is essentially a set of path tests performed to examine the many different paths through the modules. These types of tests are conducted to prove that all paths in the program are solid and without errors and will not cause abnormal termination of the program.

Integration Testing

Integration testing focuses o testing multiple modules working together. Two basic types of integration are usually used.

  • Top-down Integration
  • Bottom-up Integration

1.Top-down Integration

As the term suggests, starts at the top of the program hierarchy and travels down its branches. This can be done in either depth-first or breadth-first.

The main advantage of this type of integration is that the basic Skelton of the program/system can be seen and tested early.

The main disadvantage is the cause of program stubs until the actual modules are written. This basically limits the up-flow of information and therefore does not provide for a good test of the top-level modules.

2.Bottom-up Integration

This type of integration has the lowest level modules built and tested first on individual bases and in clusters using test drivers. This ensures each module is fully tested before it's utilized by its calling module.

This method has a great advantage in uncovering errors in critical modules early. 

The main disadvantage is the fact that most or many modules must be build before a working program can be presented.

Integration testing procedures can be performed in three ways.

  • Top-down Strategy
  • Bottom-up Strategy
  • Big-Bang Strategy
  • Sandwiched Strategy

Top-Down Strategy

Top-down integration is basically an approach where modules are developed and tested starting at the top level of the programming hierarchy and continuing with the lower levels.

It is an incremental approach because we proceed one level at a time. It can be done in either "depth" or "breadth" manner.

Depth means we proceed to form the top level all the way down to the lowest level. 

Breadth, on the other hand, means that we start at the top of the hierarchy and then go to the next level. We develop and test all modules at this level before continuing with another level.

Either way, this testing procedure allows us to establish a complete Skelton of the system or product.


Having the skeleton, we can test major functions early in the development process.

At this time, we can also test any interfaces that we have and thus discover any errors in that area very early on.

The major benefit of this procedure is that we have a partially working model to demonstrate to the clients and the top management. This of course builds everybody's confidence not only in the development team but also in the model itself.


Using stubs doesn't permit all the necessary upward data flow.

There is simply not enough data in the stubs to feedback to the calling module. As a result, the top-level modules can not be really tested properly and every time the stubs are replaced with the actual modules, the calling modules should be re-tested for integrity again.

Bottom-Up Strategy

The bottom-up approach is the opposite of the Top-down method.

This process starts with building and testing the low-level modules first, working its way up the hierarchy.

Because the modules at the low levels are very specific, we may need to combine several of them into what is sometimes called a cluster or build in order to test them properly.

Then to test these builds, a test driver has to be written and put in place.


There is no need for program stubs as we start developing and testing with the actual modules.

Starting at the bottom of the hierarchy also means that the critical modules are usually built first and therefore any errors in these modules are discovered early in the process.


In order to test the modules, we have to build test drivers that more complex than stubs. And in addition to that, they themselves have to be tested. So more effort is required.

No working model can be presented or tested until many modules have been built. This also means that any errors in any of the interfaces are discovered very late in the process.

Big-Bang Strategy

The Big-Bang approach is very simple in its philosophy where basically all the modules build are constructed and tested independently of each other and when they are finished, they are all put together at the same time.

The main advantage of the approach is that it is very quick as no drivers or stubs are needed, thus cutting down on the development time.

However, as with anything that is quickly slapped together, this process usually yields more errors than the other two. Since these errors have to be fixed and take more time to fix than errors at the module level, this method is usually considered the least effective.

Because of the amount of coordination that is required it is also very demanding on the resources.

Another drawback is that there is really nothing to demonstrate until all the modules have been built and integrated.

Sandwiched Strategy

The sandwiched strategy is the most widely used integration strategy as this strategy aims at overcoming the limitations of both top-down adn bottom-up and bottom-up strategies. This strategy is a mixture of both top-down and bottom-up approaches.

Similar Articles

Post a comment