Integration testing whitepaper by ashrafp


                Integration Testing
                  WHITE PAPER                 1


1. Introduction……………………………………………… 3

2. Purpose of Integration Testing…………………………...3

3. Integration testing Definition …………………………….3

4. Types of Integration testing ………………………………3

5. Integration Testing in Software Development Life Cycle..5

6. The prerequisites for Integration Testing …………………5

7. Steps needed to do Integration Testing ……………………5

8. How to write a Integration Test Case ……………………..5

9. Working towards Effective Integration Testing …………..6

10. Integration Testing Procedures ……………………………7

11. Entry Criteria ………………………………………………8

12. Exit Criteria …………………………………………………8

13. References ……………………………………………………8                                          2


Integration Testing is the activity of software testing in which individual software
modules are combined and tested as a group. It occurs after unit testing and before system
testing. Integration testing takes as its input modules that have been unit tested, groups
them in larger aggregates, applies tests defined in an integration test plan to those
aggregates, and delivers as its output the integrated system ready for system testing.

Purpose of Integration Testing

The purpose of integration testing is to verify functional, performance, and reliability
requirements placed on major design items. These "design items", i.e. assemblages (or
groups of units), are exercised through their interfaces using Black box testing, success
and error cases being simulated via appropriate parameter and data inputs. Simulated
usage of shared data areas and inter-process communication is tested and individual
subsystems are exercised through their input interface. Test cases are constructed to test
that all components within assemblages interact correctly, for example across procedure
calls or process activations, and this is done after testing individual modules, i.e. unit
testing. The overall idea is a "building block" approach, in which verified assemblages
are added to a verified base which is then used to support the integration testing of further

Integration testing Definition

When one piece of code, or a unit, needs to interact with another, it's an interface. When
we are working on interfacing the two units, we are integrating them. Testing this
integration is called an integration testing. It follows unit testing and is before system
testing. Therefore it is primarily a white box technique.

Types of Integration testing

The following examples are different types of testing that should be considered during
Integration testing:

      Big Bang
      Top Down and Bottom Up                                                                        3

Although different testing organizations may prescribe different tests as part of
Integration testing, this list serves as a general framework or foundation to begin with.

Big Bang

In this approach, all or most of the developed modules are coupled together to form a
complete software system or major part of the system and then used for integration
testing. The Big Bang method is very effective for saving time in the integration testing
process. However, if the test cases and their results are not recorded properly, the entire
integration process will be more complicated and may prevent the testing team from
achieving the goal of integration testing.
 A type of Big Bang Integration testing is called Usage Model testing. Usage Model
testing can be used in both software and hardware integration testing. The basis behind
this type of integration testing is to run user-like workloads in integrated user-like
environments. In doing the testing in this manner, the environment is proofed, while the
individual components are proofed indirectly through their use. Usage Model testing
takes an optimistic approach to testing, because it expects to have few problems with the
individual components. The strategy relies heavily on the component developers to do the
isolated unit testing for their product. The goal of the strategy is to avoid redoing the
testing done by the developers, and instead flesh out problems caused by the interaction
of the components in the environment. For integration testing, Usage Model testing can
be more efficient and provides better test coverage than traditional focused functional
integration testing. To be more efficient and accurate, care must be used in defining the
user-like workloads for creating realistic scenarios in exercising the environment. This
gives that the integrated environment will work as expected for the target customers.

Top-down and Bottom-up

Bottom Up Testing is an approach to integrated testing where the lowest level
components are tested first, then used to facilitate the testing of higher level components.
The process is repeated until the component at the top of the hierarchy is tested.
All the bottom or low-level modules, procedures or functions are integrated and then
tested. After the integration testing of lower level integrated modules, the next level of
modules will be formed and can be used for integration testing. This approach is helpful
only when all or most of the modules of the same development level are ready. This
method also helps to determine the levels of software developed and makes it easier to
report testing progress in the form of a percentage.
Top Down Testing is an approach to integrated testing where the top integrated modules
are tested and the branch of the module is tested step by step until the end of the related
The main advantage of the Bottom-Up approach is that bugs are more easily found. With
Top-Down, it is easier to find a missing branch link.                                                                         4

Integration Testing in Software Development Life Cycle

Even if a software component is successfully unit tested, in an enterprise n-tier
distributed application it is of little or no value if the component cannot be successfully
integrated with the rest of the application.
Once unit tested components are delivered we then integrate them together.
These “integrated” components are tested to weed out errors and bugs caused due to the
integration. This is a very important step in the Software Development Life Cycle.
It is possible that different programmers developed different components. A lot of bugs
emerge during the integration step. In most cases a dedicated testing team focuses on
Integration Testing.

The prerequisites for Integration Testing

Before we begin Integration Testing it is important that all the components have been
successfully unit tested.

Steps needed to do Integration Testing

Integration Testing typically involves the following Steps:

Step 1: Create a Test Plan

Step 2: Create Test Cases and Test Data

Step 3: If applicable create scripts to run test cases

Step 4: Once the components have been integrated execute the test cases

Step 5: Fix the bugs if any and re test the code

Step 6: Repeat the test cycle until the components have been successfully integrated                                                                         5

How to write a Integration Test Case

Simply put, a Test Case describes exactly how the test should be carried out.
The Integration test cases specifically focus on the flow of data/information/control from
one component to the other.
So the Integration Test cases should typically focus on scenarios where one component is
being called from another. Also the overall application functionality should be tested to
make sure the app works when the different components are brought together.
The various Integration Test Cases clubbed together form an Integration Test Suite
Each suite may have a particular focus. In other words different Test Suites may be
created to focus on different areas of the application.
As mentioned before a dedicated Testing Team may be created to execute the Integration
test cases. Therefore the Integration Test Cases should be as detailed as possible.
The format of the Integration Test Cases may be like all other Test cases as illustrated
      Test Case ID
      Test Case Description:
      What to Test?
      How to Test?
      Input Data
      Expected Result
      Actual Result
      Pass/Fail
      Remarks

Working towards Effective Integration Testing

There are various factors that affect Software Integration and hence Integration Testing:
Software Configuration Management: Since Integration Testing focuses on Integration
of components and components can be built by different developers and even different
development teams, it is important the right version of components are tested. This may
sound very basic, but the biggest problem faced in n-tier development is integrating the
right version of components. Integration testing may run through several iterations and to
fix bugs components may undergo changes. Hence it is important that a good Software
Configuration Management (SCM) policy is in place. We should be able to track the
components and their versions. So each time we integrate the application components we
know exactly what versions go into the build process.
Automate Build Process where Necessary: A Lot of errors occur because the wrong
version of components were sent for the build or there are missing components. If                                                                       6

possible write a script to integrate and deploy the components this helps reduce manual
 Document: Document the Integration process/build process to help eliminate the errors
of omission or oversight. It is possible that the person responsible for integrating the
components forgets to run a required script and the Integration Testing will not yield
correct results.

 Defect Tracking: Integration Testing will lose its edge if the defects are not tracked
correctly. Each defect should be documented and tracked. Information should be captured
as to how the defect was fixed. This is valuable information. It can help in future
integration and deployment processes.

Integration Testing Procedures

The purpose of integration testing is to verify functional, performance, and reliability
requirements placed on major design items.

                       Creating Test Plans
                       Creating test data
                       Conducting tests according to the Integration Test Plan
                       Reporting and reviewing the results of the test

Documents Required

The following documents provide information required to create the Integration Test Plan
and is recommended reading before starting the planning phase.

      High Level Design overview
      Problem Report Analysis Report
      Database Design Report
      FRAM
      Requirements Reports
      Change Requests
      Appropriate 3rd Party Interface Specifications                                                                      7

Entry Criteria
Main entry criteria for Integration testing is the completion of Unit Testing. If individual
units are not tested properly for their functionality, then Integration testing should not be

Exit Criteria
Integration testing is complete when you make sure that all the interfaces where
components interact with each other are covered. It is important to cover negative cases
as well because components might make assumption with respect to the data.

Software Testing by Paul Jorgensen

Software Testing and Analysis

Fundamentals of Software Integration                                                                           8

To top