Integration Testing Tips

Author: Gagan Talwar

Introduction: Integration testing is the phase in software testing in which individual software modules are combined and tested as a group. It occurs after unit testing phase and before system testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups.

Integration testing identifies problems that occur when units are combined. By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis.

Need of integration testing: The need 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. 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 assemblages.

Approaches used in Integration testing: There are 4 approaches used in Integration testing.

  1. Big Bang Testing
  2. Top-Down Testing
  3. Bottom-Up Testing
  4. Sandwich Testing

Big Bang Testing: 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.

Top-Down Testing: In this approach, the highest-level modules are tested first and progressively lower-level modules are tested after that.

Bottom-Up Testing: Bottom-up integration testing begins with unit testing followed by higher level combinations of units called modules. 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.

Sandwich Testing: This is an approach to combine top down testing with bottom up testing.

From above mentioned approaches only Top-Down & Bottom-Up are used mostly. So the main advantage of bottom-up approach is that bugs are more easily found as compared with top-down approach, it is easier to find the missing branch link and show the whole software process to user early.

Steps to perform integration testing:

Step 1: Create a Test Plan
Step 2: Create Test Cases and Test Data
Step 3: Once the components have been integrated execute the test cases
Step 4: Fix the bugs if any and re test the code
Step 5: Repeat the test cycle until the components have been successfully integrated

Essentials of Effective Integration testing:

There are various factors that affect Software Integration and hence Integration Testing:

1. 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 versions 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.

2. Automate Build Process where necessary: A Lot of errors occurs because the wrong versions of components were sent for the build or there are missing components. If possible write a script to integrate and deploy the components this helps reduce manual errors.

3. 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.

4. 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.

Some keynotes on need of integration testing:

  • More stable than GUI tests
  • Useful in writing precise component level tests.
  • Drives better code design
  • Tester understands the internal working of application allowing better writing of test cases
  • Easy to integrate in a continuous integration environment

 

Use of Stubs and Drivers in Integration Testing

While doing an Integration testing, if we don’t have all the modules ready and need to test a particular module which is ready then we use Stubs and Drivers.

Stubs and drivers are used for a Top down Integration testing and Bottom up Integration Testing.

For e.g.: If we have Modules X, Y and Z. X module is ready and we need to test it, but it calls functions from y and z (which are not yet ready). To test at such a module, we write a small dummy piece a code which Simulates Y and Z and which will return values for X. This piece of dummy code is called Stub in a Top down Integration Testing.

So Stubs are called Functions in Top down Integration.

Similar to the above: If we have Y and Z modules ready and x module is not ready, and we need to test Y and Z modules which accepts values from X, So to get the values from X We write a small piece of dummy code for X which returns values for Y and Z. So this piece of code is called Driver in Bottom up Integration testing.

So Drivers are calling Functions in Bottom Up Integration.

Difference between System Integration Testing and Integration Testing

System integration testing takes multiple integrated systems that have passed system testing as input and tests their required interactions. Following this process, the deliverable systems are passed on to acceptance testing.

Integration testing is the phase in 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.

 

Integration Test Plan Template

  1. Introduction
    1. Revision History. Record all revisions to the document.
    2. Purpose and Scope. State the purpose and scope of the document.
    3. List of Reference Documents

      List all reference documents; the minimum are those listed here plus documentation on tools and test equipment, integration station, etc. For instance:

    • Product Architecture Document
    • High Level Software Design
    • High Level Hardware Design
    • Hazard Analysis
  2. Integration Strategy
    1. Entry Criteria: Specify the criteria that must be met before integration of specific elements may begin (e.g., functions must have been unit
    2. Elements to be Integrated: Identify all the elements to be integrated by subsystem into which they will be integrated.
    3. Integration Strategy: Describe the integration approach (top-down, bottom-up, functional groupings, etc.) and the rationale for the choosing that approach.
    4. Sequence of Feature/Function and Hardware/Software Integration
      1. Software Integration Sequence. For each subsystem: Identify the sequence in which the software code functions and modules will be integrated. Relate this sequence to any product features/functions that are being built up. Specify any hardware dependencies for early software integration activities.
      2. Hardware Integration Sequence. For each subsystem: Identify the sequence in which the hardware elements will be integrated. Specify any software dependencies for early hardware integration activities.
      3. Full Hardware/Software Integration Sequence. For each subsystem: Identify the sequence of integrating software build(s) with the hardware modules. Identify the product features/functions that are being built up at each step.
      4. Subsystem Integration Sequence. Identify the order in which subsystems will be integrated.
  3. Individual Steps and Test Description: For each step of the integration process identified above, describe the type of tests that will be used to verify that the elements integrated in this step perform as expected. Describe in general the expected results of the test set. At the lower levels, these tests will focus on direct testing of interfaces between software functions and modules, between software functions or modules and specific electronics, etc. As more of the system is put together, tests will continue to be concerned with verifying interfaces, but will include more of a "functional test" flavor. At each step, specify where re-running of tests from previous steps may be required to verify that integrating this new element has not caused previously tested functions to fail.
    1. Software Integration Test Description
    2. Hardware Integration Test Description
    3. Hardware/Software Integration Test Description
    4. Subsystem Integration Test Description
    5. Final Functional Tests: Describe the set of functional tests to be run at the end of integration to verify the basic functionality of the system. This test is intended to confirm that the system has been successfully integrated and is now ready for full System Test by Engineering.
  4. Tools and Test Equipment Required: Identify all tools and test equipment needed to accomplish the integration. Examples are computer workstations, oscilloscopes, meters, host operating systems, etc. Specify revision levels or version numbers where necessary. The integration protocols will specify in detail all configuration information, set-up procedures, parameters, environmental conditions (lighting, humidity, etc.), etc. necessary for the integration testing. In this plan summarize any significant configuration efforts, special environmental requirements, etc.
  5. Program Stubs and Test Data Required: Based on the testing strategy and test design, identify any program stubs or special test data required for each integration step.
  6. Responsibilities and Schedule: Identify all personnel skill types and quantities, define the responsibilities assigned to each and develop a schedule which shows the sequence of major test set execution and the amount of time estimated for that test set. Identify known risks and any assumptions. NOTE:  If any of this information is included in the project plan instead, reference the section in that document.
    1. Roles and Responsibilities
    2. Key Dependencies: Define key dependencies in the schedule (people or equipment resources, availability of other hardware or software under development, etc.)
    3. Risks and Assumptions
    4. Schedule
  7. Problem Recording and Resolution: Define the mechanism to be used for problem recording and resolution, including any necessary rework of documents, software or hardware elements, test plan or procedures. Include (or reference) any forms. Reference any standard problem tracking procedures that will be used.
  8. Rework, Review, and Retest Procedures: Define the process for rework, review, and retest of any element needing modification. This process must include sufficient retest to verify that any modifications have not impacted other functions already tested. This process must also define the project guidelines for how related design and requirements documents will be updated as changes are made. Change management processes for this phase must be defined and followed.
  9. Suspension, Restart, and Exit Criteria: Define criteria for a) suspending testing before completion (for instance, the discovery of major problems with a certain feature; b) criteria for restarting testing following such a suspension; and c) the criteria for determining that integration test is complete and system test can begin.

Conclusion: Integration testing is a phase of testing. Once Modules are developed and tested, all components are grouped together to check the functionality of System as a whole. All modules are coupled together to check the functionality i.e. know whether system breakdown at some point, whether data is moving properly from one module to dependent module, etc. In Organizations there is a separated Integration testing team who test the system as whole. If done properly it can reduce the risk of defect leaking, also it can reduce the risk of defects to be caught by client during UAT phase. Thus, integration plays an important role in testing cycle.