Integration Test Objectives.
Integration testing is generally done incrementally, as discussed earlier. Therefore Test Engineering and Software Engineering need to understand what needs to be accomplished at each increment. Each increment repeats the same set of activities.

1. Verifying
   1. Functionality allocated to the component or configuration item. As
   integration test incrementally builds to larger and larger logical groupings (i.e, components and configuration items), the overall functionality should be retested.
   2. Interface compatibility. Verifies the appropriate level of interfaces.
   Figures 1, 2, and 3 illustrated this concept.
   3. Error handling & recovery. May want to tie this in with functional
   threads; component (and configuration item) inputs and outputs, etc.
2. Test coverage.
   Integration test proceeds based on the "building block" approach and that unit test successfully met the test coverage (statement, decision, or logic) guidelines. The focus here changes to executing functional threads through the system.
3. Other considerations. Two definitions:
   1. Deterministic means when you are able to duplicate the "exact" situation.
   2. Non-deterministic means when the software has actions on different levels and you cannot repeat/duplicate the situation Test Engineering needs a strategy for testing reasonable combinations of events. A good suggestion is to design software that is not non-deterministic.

Testing Planning.
The following activities are coordinated between the integration test team members. The Test team is made up of Software Engineering and Test Engineering. Some of the activities will be discussed in detail in the next unit. The activities are:

1. Determine approach.
   1. Responsibility of team leader. One of the issues is who will be responsible for the various phases of the integration test. The team leader could be chosen from the Software Manager or the Integration Manager, based on the increment of integration test.
   2. Objectives. The integration test objectives were addressed in the previous paragraphs. These should be well defined and available to all team members involved with integration test.
   3. Top-down, bottom-up, or hybrid testing. These will be discussed in the next set of paragraphs.
   4. Identify defect resolution procedures. This topic will be discussed in the next unit.
   5. Determine re-test, regression test procedures. Determine what tests the team will need to re-run to ensure baseline functionality has not been altered by fixes or requirement changes. This topic will be discussed in the next unit.
   6. Determine metrics collection plan. The test team needs to know what metrics to collect, how they will collect them and, how they will be displayed. This topic will be discussed in the next unit.
2. Identify test platform. The test platform is something else that may vary depending on which increment of integration test is being planned or conducted. For example, both unit-to-unit and component-to-component may be conducted on the development platform; and configuration item-to-configuration item may be conducted on the target platform. The following may affect these decisions:
1. Availability of hardware
2. Availability of hardware during a specific time frame. For instance Government Furnished Equipment (GFE) or hardware built for or tailored to the specific environment may not be available until the latter stages of a project.
3. Design integration tests. Logically group the CSC's and CSCI's to form a deliverable set of tests to perform to meet an achievable milestone.
4. Design integration test cases. Necessary for peer reviews, repeatability and for documentation of results.
5. Execute test cases. This will be discussed in detail in the next Unit.
6. Report on integration test. This will be discussed in the next Unit.

Integration Test Approaches. The Top-Down, Bottom-Up and Hybrid Approaches for integration testing are defined and their advantages and disadvantages discussed.

The definition for the Top-Down Approach is to start at the highest level, the executive is written first with stubs for the unwritten modules. Stubs are usually just "write" statements (a stub for module X might output a statement "module X called"). Stubs are then replaced with actual modules and tests are re-run.

Advantages

1. Stubs are easier to construct than drivers
2. Exposes the conditions of program control to as many variations as possible (upper modules get more exercise)
3. Lends itself more easily to production of incremental builds
4. Supports early definition of interfaces
5. Supports parallel testing at several levels

Disadvantages

1. Can be difficult to provide desired test conditions
2. Takes a long time to get to the newly added stub replacement

The definition for the Bottom-Up Approach is to start at the bottom and write units, compile them and, write higher level drivers to test their interaction. Then, move up to the next level. This a building block approach, where individual modules are integrated with other modules.

Advantages

1. Can place emphasis on exercising computational modules at the bottom of the structure. This subjects the hierarchically low modules to new input stimuli each time a relevant module at a higher level is introduced. The same is true of critical or complex modules.
2. A certain amount of bottom-up testing is inherent if reused or re-engineered modules form part of the program.
3. Allows early testing of critical or complex modules
4. Can take advantage of reused and re-engineered modules or code.

Disadvantages

1. Devising drivers is initially more work than replacing stubs in the top-down approach, since the drivers change significantly from level to level.
2. Requires a new set of tested top-level control functions each time a new performance capability is delivered.
3. There is a risk that previous builds have to undergo a complete re-test as a result of upper tier changes.

The definition of the Hybrid Approach is to do both top-down and bottom-up, choosing which approach to implement is based on what the test team wants to stress with their testing. The hybrid approach is to start with critical and complex bottom level modules. Code and integrate them as early as possible. They would be tested out using drivers. Meanwhile, top-down testing is continuing with stubs being created as needed. When the top-down approach meets the bottom-up approach, stubs will be replaced with modules that have been written and unit tested.

Advantages

1. Rigorously test critical and complex software early (benefit of bottom-up).
2. Minimizes development of test software by using high level drivers and previously tested system software to perform test(advantage of top-down).
3. Testers can tailor their approach to concentrate on the items of high concern (high risk, etc.).
4. Supports rapid prototyping (concentrating on key functional areas).

Disadvantages

1. Require both stubs and drivers to be developed.
2. Can be more difficult to manage and track progress.
3. Requires greater discipline and control than just one pure approach, test team must be carefull to keep track of where they are in the process. They must know what they have drivers for, what stubs they have and, what real modules are ready to be inserted.

Integration Exercise
This is the sample system for an integration exercise.

Problem 1. For top-down, you would want to test the Executive first. Next, modules A through G would be tested. Then, modules X and Y, Q and R, and M and N would be tested. Finally, K and L, and S and T would be tested. Stubs would be needed. When testing module B, stubs would be needed for X and Y. When testing module C, stubs would be needed for modules Q and R, etc.

Problem 2. For bottom-up, start by testing modules K and L and S and T. Then a driver must be written to test their interaction (basically a Q driver and an N driver). Next module Q & R, module M & N, and module X & Y would be written. To test these will require drivers (which will be replaced by modules B, C, and F). Next, modules A - G would be tested. Finally the executive would be tested. Drivers would be needed. When testing K and L, a driver would be needed (which would be replaced by module Q). To test S and T, a driver is needed for module N. To test Q and R, a driver is needed, etc.

Problem 3. A hybrid approach should be used, because you can test your low-level modules (S and T) and your higher modules (B and C). You would test your executive, test B and C, stub out A, D, E, and G. You would test S and T, writing a driver to take N’s place. F would also have to be a driver of some sort.

In Unit 8 the student was given a background in the process of software component testing, software configuration item testing, and the two associated kernels within the Example Software Development Process, integration test objectives, test planning, and integration test approaches.

Note: Please click the Quiz on your left navigation.