While development, a software application is divided into different logical or functional modules for better management. When each module is developed, it is also tested for functionality known as Unit testing. Once all modules are developed and they are integrated and Integration testing is carried out to discover the issues which arise as different modules are interacting with each other. Generally speaking, this phase is also called the System Integration Testing.

There are several kinds of testing that involve or overlap or may even be synonymous with integration testing, like regression testing, system testing, compatibility testing, platform testing, risk-based testing, etc. Most testing, in fact, no matter what it’s called, is also integration testing.
Here is my definition of integration testing, based on my own analysis -

What is integration testing?

Testing performed to expose defects in the interfaces and in the interactions between integrated components or systems. The purpose of integration testing is to verify the functional, performance, and reliability between the modules that are integrated. Integration of individual modules and integration of all the systems making up the products's ecology both are scoped in for Integration testing.

Why Integration Testing is important part of testing?

We feel that System Integration is complex and requires some development and also analysis and logical skill. That’s true! Therefore integration testing becomes pivotal part of testing strategy.

Here are some reasons:

  • In real world, when applications are developed, it is broken down into smaller modules and individual developers are assigned 1 module. The logic implemented by one developer is quite different from other developer, so it becomes important to check whether the logic implemented by a developer is as per the expectations and renders correct value in accordance to the prescribed standards.
  • Many a times the face or the structure of data changes when it travels from one module to another. Some values are appended or removed, which causes issues in the later modules.
  • Modules also interact with some third party tools or APIs which also need to be tested that the data accepted by that API / tool is correct and that the response generated are also as expected.
    -A very common problem in testing – Frequent requirement change! :)

The three main integration testing strategies are as follows:

Big Bang: Involves integrating the modules to build a complete software system. This is considered a high-risk approach because it requires proper documentation to prevent failure. Nowadays industries are preferring agile approach instead of big-bang as it comes with some disadvantages like - It is harder to track down the causes for the errors since all the modules, and thus complexity, are added at once. For instance, if a transaction is not processing correctly, you may have to track back through 10 modules to determine the cause.
But in agile, when developed and applied diligently, Continuous Integration has proven itself time and time again to keep ever-changing code bases tame as they are evolving. It is especially fruitful when multiple teams are integrating multiple changes to add new features and fix defects identified along the way.

Bottom-Up: Involves low-level component testing, followed by high-level components. Testing continues until all hierarchical components are tested. Bottom-up testing facilitates efficient error detection.

Top-Down: Involves testing the top integrated modules first. Subsystems are tested individually. Top-down testing facilitates detection of lost module branch links.

Finally, in conclusion some steps to kick off Integration tests

1.Understand the architecture of your application.

2.Identify the modules

3.Understand what each module does

4.Understand how the data is transferred from one module to another.

5.Understand how the data is entered and consumed into the system ( entry point and exit point of the application)

6.Logical grouping of modules to suite your testing needs.

7.Identify and create the test conditions which will cover all validation paths.

8.Business relevancy / case