Integration Testing

Integration Testing: What is, Types, Top Down & Bottom Up

What exactly is meant by “integration testing”?
In the context of software testing, the term “integration testing” refers to a type of testing in which individual software modules are tested collectively after being logically combined. A typical software development project will involve multiple software modules, each of which will be programmed by a different developer. This level of testing is performed with the intention of identifying flaws in the interaction that occurs between the various software modules after they have been integrated.

The goal of integration testing is to ensure that all of these modules can communicate effectively and exchange data with one another. Because of this, it is also known as “I & T” (which stands for “Integration and Testing”), “String Testing,” and occasionally “Thread Testing.”
Why Should We Perform Integration Tests?
Examination of Integration

Why do Integration Testing?

Despite the fact that every software module is subjected to unit testing, there are still bugs in the software due to a number of factors including
An individual software developer, whose comprehension and programming logic may differ from those of other programmers, is responsible for the design of a Module in the broadest sense. Testing is required for integration to ensure that all of the software components function as intended.
There is a high probability that the requirements laid out by the customers will shift while the module is still being developed. Because it is possible that these new requirements will not pass unit testing, system integration testing will need to be performed.

Example of Integration Test Case

There is a possibility of errors occurring at the interfaces between the software modules and the database.
There is a possibility that any external hardware interfaces will be flawed.
Problems could arise from insufficient attention being paid to exceptions.

Test Case ID Test Case Objective Test Case Description Expected Result
1 Check the interface link between the Login and Mailbox module Enter login credentials and click on the Login button To be directed to the Mail Box
2 Check the interface link between the Mailbox and Delete Mails Module From Mailbox select the email and click a delete button Selected email should appear in the Deleted/Trash folder

If you are unable to view the video, please click here.
Example of a Case Studied for Integration Testing
The Integration Test Case is distinct from the other test cases in that its primary emphasis is placed on the interfaces and the flow of data and information between the modules. When it comes to this particular aspect, the integrating links should be given priority over the unit functions that have already been tested.

Approaches, Strategies, Methodologies of Integration Testing

Examples of Integration Test Cases for the Scenario Following: The application consists of three distinct sections, namely the “Login Page,” the “Mailbox,” and the “Delete Emails” sections, all of which are logically connected to one another.

The testing of the Login Page should not take up too much of your attention here because it has already been completed in the Unit Testing phase. Examine the way in which it is connected to the Mail Box Page.
Integration Testing Approaches, Strategies, and Methodologies
Software Engineering specifies a variety of methods to carry out integration testing, including but not limited to.

Big Bang Testing

Both the Big Bang Approach and the Incremental Approach can be further broken down into the following categories.
Sandwich Approach – a Combination of the Top-Down and Bottom-Up Methods Top-Down Approach Bottom-Up Method Sandwich Approach
The various strategies, the manner in which they are carried out, as well as the benefits and drawbacks of each are outlined below.
Big Bang Testing
The testing strategy known as “Big Bang Testing” is a form of integration testing in which all of the system’s components or modules are brought together all at once and then tested collectively. During testing, this assembled collection of individual components is treated as if it were a single entity. The integration process will not be carried out if any of the individual components that make up the unit are not finished.


Convenient for small systems.

Incremental Testing

It can be difficult to localise the fault.
Because there are so many interfaces that need to be tested using this methodology, it is possible that some of the interface links that need to be tested will be forgotten.
As a result of the fact that integration testing cannot begin until “all” of the modules have been designed, the testing team will have significantly less time for execution during the testing phase.
All of the modules are tested at the same time, so high-risk critical modules are not separated out and tested separately on a priority basis. It is also not possible to isolate and prioritise testing for peripheral modules that are concerned with user interfaces.
Testing Done in Increments
Testing is carried out using the incremental testing strategy by first integrating two or more modules that are logically related to each other, and then testing the application to ensure that it is functioning correctly after each integration. After that, the integration of the remaining related modules occurs in stages, and the process is repeated as necessary until all of the logically related modules have been successfully integrated and tested.

The Incremental Approach, on the other hand, can be implemented using one of two distinct Methods:

First the bottom, then the top.
Tickets and their Drivers
When performing integration testing, stubs and drivers are the names given to the fake programmes that are used to help facilitate the software testing activity. These programmes serve as replacements for the models that were not present during the testing. During the testing phase, they do not actually implement all of the programming logic of the software module; rather, they simulate data communication with the module that is calling them.

Stubs and Drivers

Stub is a function that is called by the Module under Test.

Calls the Module that is going to be tested. Driver.

Bottom-up Examination of Integration
Bottom-up During integration testing, the lower level modules are the ones that are tested first as part of the strategy. These modules that have been tested are then put to use in an effort to simplify the testing of modules at a higher level. The process will carry on until all of the modules at the top level have been evaluated. The subsequent level of modules won’t be formed until after the modules at the lower level have been validated and incorporated.

a representation in the form of a diagram:

The Big Bang, the Top Down, and the Bottom Up: An Integration Testing Tutorial Advantages:

Locating the source of the problem is simpler.
In contrast to the big bang method, there is no time lost waiting for all of the modules to be developed.

Top-down Integration Testing

The most important modules, which are located at the highest level of the software architecture and are responsible for controlling the flow of application, are tested very last and may contain errors.
It is not possible to create an early prototype.
Testing from the Top Down for Integration
Top Down Integration Testing is a method that involves carrying out integration testing in the reverse order of how a software system is controlled, beginning at the very top and working its way down. In order to verify that the software is functioning properly, the higher-level modules are tested first, followed by the lower-level modules, which are then tested and integrated. When certain modules are not yet ready for testing, stubs are substituted for their functionality.

a representation in the form of a diagram:

The Big Bang, the Top Down, and the Bottom Up: An Integration Testing Tutorial Advantages:

The process of fault localization is simpler.
The opportunity to obtain an early version of the product.
The most important modules are tested first, and any major design flaws that are discovered are addressed immediately.

Top-down Integration Testing

Needs a large number of Stubs.
Les modules located at a lower level receive insufficient testing.
Sandwich Testing
The testing method known as “sandwich testing” involves testing higher-level modules with lower-level modules at the same time that the lower-level modules are integrated with the higher-level modules and tested as a system. Because it incorporates aspects of both the top-down and bottom-up testing methodologies, it is known as “Hybrid Integration Testing.” It makes use of stubs as well as drivers to accomplish its goals.

Integration Testing Guide: Big Bang, Top Down, and Bottom Up Big Bang, Top Down, and Bottom Up
Tests of Integration: How Should They Be Done?
The Integration test procedure, which remains the same regardless of the Software testing strategies (which were previously covered):

Sandwich Testing

Put together a plan for the integration tests.
Create the test scenarios, cases, and scripts for the tests.
Putting the test cases through their paces and then reporting any issues that arise.
Monitoring and performing additional testing on the defects.
Steps 3 and 4 are carried out multiple times until the Integration process is successfully finished.
A Concise Explanation of the Integration Test Plans:
The following characteristics are included in it:

How to do Integration Testing?

Various testing strategies and methods (as discussed above).
Those Within and Those Beyond the Scopes Items of consideration for integration testing.
Roles and Responsibilities.
The necessary components before beginning integration testing.
Testing environment.
Risk Assessment and Prevention Strategies.
Criteria for Entry and Exit into the Integration Testing Procedure
Any software development model should have clearly defined criteria for entering and leaving the integration testing phase.

Brief Description of Integration Test Plans:

Admission Requirements:

Tested Individually Components and Modules
All high-priority bugs have been fixed, and the issue has been closed.
All of the Modules must have their coding finished, and the integration must go smoothly.
Evaluations of integration It is necessary to document and sign off on the plan, test case, and scenarios.
Integration testing calls for the setting up of the required test environment.
Exit Criteria:

Entry and Exit Criteria of Integration Testing

The testing of the integrated application was successful.
Executed Test Cases are documented
All high priority bugs have been fixed, and then the next step will be to submit the technical documents, and then the release notes.
Recommended Procedures and Operating Principles for Integration Testing
Determine first the Integration Test Strategy that might be utilised, and only after that start preparing the test cases and test data in the appropriate manner.
Conduct research into the Architecture design of the Application and determine which Modules are Crucial. These have to be examined in order of priority.
Obtain the designs for the interfaces from the Architectural team, and then construct test cases to verify each of the interfaces in more depth. It is necessary to conduct in-depth testing of the interface to the database, external hardware, and software application.
After the test cases, the test data are the ones that play the most important role in the process.
Always ensure that the mock data is prepared before beginning the execution. During the course of the execution of the test cases, do not select any test data.