What Is Integration Testing in Software Testing 

Integration testing is a type of software testing where testing the interface to expose problems in the interaction between various software modules. Elements are integrated one after the other and analyzed as a single piece. Usually, the procedure is executed by a team of testers.

Do you want to know, what is integration testing with example in simple words?

The ultimate goal of integration testing is to review the interfaces between various elements and the connections and communication between them. How well do units in the code link with each other? For example, you have a login module, a user account module, and a membership module that are dependent on each other. They should be checked in a group to confirm the proper connection inside a system. 

Let’s clarify what are the key objectives of integration testing and what is the principal value of it?

Key Objectives of Integration Testing and Its Focus Areas

• To ensure elements behave together as designed.
• To expose problems related to the interface.
• To maximize test coverage.
• To improve the response of a system in accordance to how it is created and confirm that recently added elements are not affected.

This is why integration testing is required for effective software behavior. By doing it, you get an advanced type of system that operates well not only under ordinary but also under unusual conditions at a much lower cost than you might have with extra requirement testing. In complex projects that involve big teams and a number of modules created by different developers, integration testing is a necessary step to avoid miscommunication and mismatch during the development process. Additionally, requirements are frequently updated and new pieces of code are added. When they are grouped, they have to be verified all over again.

Further let’s define what are the types of integration testing and what kind of benefits do they provide?

Main 4 Types of Integration Testing

There are four ways QA engineers undertake integration testing:

• big-bang;
• bottom-up (BUA);
• top-down (TDA);
• mixed (sandwich).

Big-bang technique covers components, which are incorporated and analyzed simultaneously. The functionality is confirmed after the testing of each and every one is over. It is a challenging strategy because it is not easy to figure out what has caused the bug when all elements are reviewed at the same time. For example, there are ten components in a system. You wait until all are developed and combined to conduct Integration testing. Of course, it saves a lot of time and suits smaller systems, but you cannot start the process until each component is 100% ready. The procedure of finding the cause of the bug is demanding; critical pieces are not prioritized.

Pros: saves time, useful for small projects.

Cons: the key element is not prioritized.

Bottom-up (BUA) technique starts from the lowest modules, gradually moving up to higher ones. Low-level pieces are always analyzed first. Then you work on the upper-level elements and integrate everything to see whether the program operates as it is supposed to. The possibility that high-level elements are not prepared at the moment low-level ones are being tested is high. For this purpose, something called “drivers” is employed. Drivers take the place of high-level components (if they are not yet completed) while the bottom-level pieces are being verified. The indicated technique does not require much effort to create testing conditions, but it needs drivers for the process to move on. Fixing critical bugs is a priority.

Pros: testing conditions are easy to create.

Cons: drivers are necessary.

Top-down (TDA) technique is the opposite of BUA. It is conducted by starting from the top elements and gradually moving to the bottom set. For example, you have seven modules. Module 1 is the highest one. Before diving deep into Integration testing, each of the modules undergoes a unit checkup for testers to ensure they operate well. A concept of stubs is introduced instead of the components that are not ready yet. The main advantages of following this specific approach are that stubs are less time-consuming to write (it takes longer to create drivers) and that testing critical modules first helps to identify major bugs at the early stages. But the basic functionality is reviewed late, which is a downside for a certain category of projects.

Pros: faster than BUA, critical elements are reviewed first.

Cons: basic functionality bugs are not a priority.

That is what is meant by integration testing from the perspective of a single approach. But you can also combine two of them to get more advanced results.

Mixed (or sandwich) strategy represents a mixture of BUA and TDA. According to this technique, the software is a three-level unit, where the first layer is the target layer. It is suitable for large, complex projects and tasks, which can be split into smaller ones. The sandwich approach has the best of both worlds; it has the advantages of both BUA and TDA. The main downsides are the cost (which rises because of considering both approaches) and the experience of a team that has to understand how to adapt to such a comprehensive technique correctly.

How to Do Integration Testing

Integration testing is carried out during the development phase. Therefore, not every element is available for testing at the same time. This makes the process even more challenging than it is. But what is the main purpose of integration testing and how does it guide the process?

Error identification in the interconnection between various components in the same system and its compliance with requirements are the reasons why specific components are required even though they may not be ready yet. In case specific sections are not available, temporary pieces (stubs and drivers) are deployed. If you want to examine functionality that is supported by other functionality that is not finished yet, you have to employ a dummy page instead. The dummy page has the characteristics of the original page. The checkup can be accomplished without delay. You do not need to stop the process until every separate section is finished. A calling program or a driver is reversed to a stub, which is a called program.

The process does not drastically differ from how other ways of testing are usually organized, though it has its specific aspects. First of all, testers define a module and a strategy to pursue. Each of the elements is checked to see whether they have undergone unit testing. Then, they are deployed together and reviewed. The results are analyzed, summarized, and communicated. A summary report is prepared and shared with the rest of the team.

Integration Testing vs. Unit Testing

Let’s talk about whether these two types have something in common. And how is integration testing different from unit testing in the first place?

Unit testing represents a manageable form of evaluating a software product or application, with a function that is verified in full isolation from other parts of the code. It is executed to ensure a specific function performs as expected on its own while being completely isolated from the environment. Integration testing differs. First of all, it is not isolated. It is integrated. Secondly, it covers the entire system, not just a single function. It is concerned about the entirety of a product. And that is why it is more complicated and harder to prepare and perform.

Here is a comparison table of Integration testing and Unit testing performance.