INTEGRATION TESTING AND SYSTEM TESTING

Read Time:7 Minute, 51 Second

INTEGRATION TESTING

Integration testing is carried out after all or at least some of the modules have been unit tested.

Successful completion of unit testing, to a large extent, ensures that the unit or module as a whole works satisfactorily.

In this context, the objective of integration testing is to detect the errors at the module interfaces (call parameters).

For example, it is checked that no parameter mismatch occurs when one module invokes the functionality of another module.

Thus, the primary objective of integration testing is to test the module interfaces, i.e., there are no errors in parameter passing, when one module invokes the functionality of another module.

The objective of integration testing is to check whether the different modules of a program interface with each other properly.

During integration testing, different modules of a system are integrated in a planned manner using an integration plan.

The integration plan specifies the steps and the order in which modules are combined to realise the full system.

After each integration step, the partially integrated system is tested. An important factor that guides the integration plan is the module dependency graph.

A structure chart (or module dependency graph) specifies the order in which different modules call each other. Thus, by examining the structure chart, the integration plan can be developed. Any one (or a mixture) of the following approaches can be used to develop the test plan:

Big-bang approach to integration testing

Top-down approach to integration testing

Bottom-up approach to integration testing Mixed (also called sandwiched ) approach to integration testing

Big-bang approach to integration testing

Big-bang testing is the most obvious approach to integration testing.

In this approach, all the modules making up a system are integrated in a single step.

In simple words, all the unit tested modules of the system are simply linked together and tested.

However, this technique can meaningfully be used only for very small systems.

The main problem with this approach is that once a failure has been detected during integration testing, it is very difficult to localise the error as the error may potentially lie in any of the modules.

Therefore, debugging errors reported during big-bang integration testing are very expensive to fix. As a result, big-bang integration testing is almost never used for large programs.

Bottom-up approach to integration testing

Large software products are often made up of several subsystems.

A subsystem might consist of many modules which communicate among each other through well-defined interfaces.

In bottom-up integration testing, first the modules for each subsystem are integrated. Thus, the subsystems can be integrated separately and independently.

The primary purpose of carrying out the integration testing of a subsystem is to test whether the interfaces among various modules making up the subsystem work satisfactorily.

The test cases must be carefully chosen to exercise the interfaces in all possible manners.

In a pure bottom-up testing no stubs are required, and only test-drivers are required.

Large software systems normally require several levels of subsystem testing, lower-level subsystems are successively combined to form higher-level subsystems.

The principal advantage of bottom- up integration testing is that several disjoint subsystems can be tested simultaneously.

Another advantage of bottom-up testing is that the low-level modules get tested thoroughly, since they are exercised in each integration step.

Since the low-level modules do I/O and other critical functions, testing the low-level modules thoroughly increases the reliability of the system.

A disadvantage of bottom-up testing is the complexity that occurs when the system is made up of a large number of small subsystems that are at the same level.

This extreme case corresponds to the big-bang approach.

Top-down approach to integration testing

Top-down integration testing starts with the root module in the structure chart and one or two subordinate modules of the root module.

After the top-level ‘skeleton’ has been tested, the modules that are at the immediately lower layer of the ‘skeleton’ are combined with it and tested.

Top-down integration testing approach requires the use of program stubs to simulate the effect of lower-level routines that are called by the routines under test.

A pure top-down integration does not require any driver routines.

An advantage of top-down integration testing is that it requires writing only stubs, and stubs are simpler to write compared to drivers.

A disadvantage of the top-down integration testing approach is that in the absence of lower-level routines, it becomes difficult to exercise the top-level routines in the desired manner since the lower level routines usually perform input/output (I/O) operations.

Mixed approach to integration testing

The mixed (also called sandwiched ) integration testing follows a combination of top-down and bottom-up testing approaches.

In topdown approach, testing can start only after the top-level modules have been coded and unit tested.

Similarly, bottom-up testing can start only after the bottom level modules are ready.

The mixed approach overcomes this shortcoming of the top-down and bottom-up approaches.

In the mixed testing approach, testing can start as and when modules become available after unit testing.

Therefore, this is one of the most commonly used integration testing approaches. In this approach, both stubs and drivers are required to be designed.

Phased versus Incremental Integration Testing

Big-bang integration testing is carried out in a single step of integration.

In contrast, in the other strategies, integration is carried out over several steps.

In these later strategies, modules can be integrated either in a phased or incremental manner.

A comparison of these two strategies is as follows:

In incremental integration testing, only one new module is added to the partially integrated system each time.

In phased integration, a group of related modules are added to the partial system each time.

Obviously, phased integration requires less number of integration steps compared to the incremental integration approach.

However, when failures are detected, it is easier to debug the system while using the incremental testing approach since the errors can easily be traced to the interface of the recently integrated module.

Please observe that a degenerate case of the phased integration testing approach is big-bang testing.

Integration Testing of Object-oriented Programs

There are two main approaches to integration testing of object-oriented programs:

• Thread-based

• Use based

Thread-based approach:

In this approach, all classes that need to collaborate to realise the behaviour of a single use case are integrated and tested.

After all the required classes for a use case are integrated and tested, another use case is taken up and other classes (if any) necessary for execution of the second use case to run are integrated and tested.

This is continued till all use cases have been considered.

Use-based approach:

Use-based integration begins by testing classes that either need no service from other classes or need services from at most a few other classes.

After these classes have been integrated and tested, classes that use the services from the already integrated classes are integrated and tested.

This is continued till all the classes have been integrated and tested.

SYSTEM TESTING

After all the units of a program have been integrated together and tested, system testing is taken up.

System tests are designed to validate a fully developed system to assure that it meets its requirements.

The test cases are therefore designed solely based on the SRS document.

The system testing procedures are the same for both object-oriented and procedural programs, since system test cases are designed solely based on the SRS document and the actual implementation (procedural or objectoriented) is immaterial.

Types of System Testing

There are essentially three main kinds of system testing depending on who carries out testing:

1. Alpha Testing:

Alpha testing refers to the system testing carried out by the test team within the developing organisation.

2. Beta Testing:

Beta testing is the system testing performed by a select group of friendly customers.

3. Acceptance Testing:

Acceptance testing is the system testing performed by the customer to determine whether to accept the delivery of the system.

In each of the above types of system tests, the test cases can be the same, but the difference is with respect to who designs test cases and carries out testing.

The system test cases can be classified into functionality and performance test cases.

Before a fully integrated system is accepted for system testing, smoke testing is performed.

Smoke testing is done to check whether at least the main functionalities of the software are working properly.

Unless the software is stable and at least the main functionalities are working satisfactorily, system testing is not undertaken.

The functionality tests are designed to check whether the software satisfies the functional requirements as documented in the SRS document.

The performance tests, on the other hand, test the conformance of the system with the non-functional requirements of the system.