Integration Testing: How-to, Examples & Free Test Plan (2025)

Components that work well on their own don't always work well when integrated with each other. That's why integration testing is so necessary in your testing project.

In this article, I'll show you:

• What integration testing is
• Why integration testing is crucial in any testing project
• The different types of integration testing and how to do each of them
• Integration testing best practices

Let's dive in!

What is integration testing? 

Integration testing is a type of testing in which multiple parts of a software are gradually integrated and then tested as a group.

The goal of integration testing is to check if different software components work seamlessly with each other.

Example of integration testing

Let's say that you are testing a software with 10 different modules.

Each of these modules have been unit tested. They all pass, which means they work well individually. That's a good sign. However, can we be sure that those individual parts work well together?

Conflicts can always arise. Just like how people who work well on their own may not always work well as a team.

Once those modules are integrated, things can go wrong in several ways, such as:

• Inconsistent code logic
• Inconsistent data rule
• Conflicts with third-party services
• Inadequate exception handling

That's why testers must perform integration testing to cover those scenarios. Out of the 10 modules, testers can first choose and integrate 2 modules. If these modules interact smoothly, they carry on with another 2 modules, until all modules are tested.

Download the Integration Test Plan Template

Use this Excel sheet to track modules, test data, and results.

The template is now yours! Don't forget to check out other Katalon resources.

By submitting this form, you consent to us using your email address to send the requested download, as well as related updates. You can unsubscribe at any time. See our Privacy Policy for more details.

Approaches to integration testing

There are 2 most common approaches to integration testing:

1. Big Bang Approach
2. Incremental Approach

1. Big Bang integration testing

Big Bang Integration testing is an integration testing approach in which all modules are integrated and tested at once, as a singular entity. AKA, a Big Bang.

Big Bang integration testing is not carried out until all components have been successfully unit tested.

Advantages of Big Bang integration testing:

• Suitable for simple and small-sized systems with low level of dependency among software components.
• Little to no planning beforehand required
• Easy to set up since all modules are integrated simultaneously
• Management and coordination efforts are minimized since there is only one major testing phase

Disadvantages of Big Bang integration testing:

• Costly and time-consuming for large systems with a huge number of units as testers have to wait until all modules have been developed to start testing
• Waiting for all modules to be developed before testing also means late defect detection
• Hard to isolate and pinpoint bugs in specific modules
• Hard to debug due to the complexity of multiple integrated modules

Best Practices when using Big Bang testing:

• Clearly define the interactions between each unit/function before testing to minimize missing defects
• Perform extensive logging for more accurate fault localization
• Perform Big Bang testing for simple applications

📚 Read More: Big Bang Integration Testing: A Complete Guide

2. Incremental integration testing

Incremental integration testing is an approach in which 2 or more modules with closely related logic are grouped and tested first, then gradually move on to other groups of modules, instead of testing everything at once. The process ends when all modules have been integrated and tested.

Incremental integration testing is more strategic than Big Bang testing since it requires substantial planning beforehand.

Advantages:

• Earlier bug detection compared to Big Bang testing since the modules are integrated and tested as soon as they are developed.
• You can identify root cause of bugs more easily since the modules are tested in relatively small groups, and so when bugs surface, you know exactly where to look.
• More flexible testing strategy

Disadvantages:

• In earlier stages of the project, sometimes some components haven't been coded. However, you still need those components to do incremental integration testing. This leads to the creation of stubs and drivers, which are essentially mock components that will be used as substitutes for actual components.
• You also need to have a complete definition and logic of your system before it can be broken down into small units.

Types of incremental integration testing

You can further divide incremental integration testing into 3 smaller approaches:

• Bottom-up approach: you perform testing for low-level components first, then gradually move to higher-level components.
• Top-down approach: you perform testing for high-level components first, then gradually move to lower-level components.
• Hybrid approach: this is where you combine the two former approaches

But what is low-level components and high-level components? The concept of “low” vs “high” here refers to the position of the software component in the system hierarchy when you do integration testing.

• Low-level components perform the most fundamental tasks in the system (data structures, simple functions, etc). These components are specific and low-impact.
• High-level components are more comprehensive and complex. They perform more far-reaching tasks, such as data processing, data management, or security mechanisms. If these high-level modules are malfunctioning, the entire system is affected.
  

If you put that in the context of an eCommerce website, it's going to look like this:

As you can see in this diagram, the lower level components are shirts and polo (specific types of clothes). Shirts and polos fall under the “Tops” category, which falls under the “Men's clothing” category. At the highest and most generic level, they are simply called “Clothing”.

When using the bottom-up approach for integration testing, we go from the specific modules to more comprehensive modules, or from the “shirt” module to the “clothing” module.

Here is when you should use bottom-up integration testing:

• Complexity is primarily found in lower-level modules (which means bugs are more likely to be found there)
• You team follows incremental development (which means developing lower-level components first before moving to higher-level modules)
• Bug localization is a crucial aspect of the project since the granularity of the bottom-up approach provides more exact bug isolation
• Higher-level modules are still under development or likely to change frequently

📚 Read More: Bottom-up Integration Testing: A Complete Guide

Here's when you should use top-down integration testing:

• When complex workflows are in the higher-level components
• When you want to simulate real-world scenarios and user interactions
• When lower-level modules are more well-defined, stable, and unlikely to change significantly

📚 Read More: Top-down Integration Testing: A Complete Guide

Hybrid integration testing explained

Hybrid Integration Testing is also called Sandwich Testing. It is an approach in which testers perform both top-down and bottom-up testing simultaneously.

Advantages:

• QA teams can tailor their integration testing activities based on project requirements, combining the strengths of different methods.
• More flexibility in terms of using resources
• Ensuring that both the low-level and high-level software components are verified at the same time

Disadvantages:

• Effective communication among team members is crucial to ensure consistency and proper tracking of issues
• Teams may find it challenging to switch between different integration strategies

Integration testing in the test pyramid

If you ever wanted to create a test strategy, test pyramid is a great framework to follow.

The Test Pyramid is a popular framework to illustrate the proportion of different types of tests in a software testing strategy. The idea is to focus resources on automating tests at lower levels (unit tests and integration tests) while minimizing the more expensive E2E tests at the top.

The 3 layers of test pyramid include:

1. Unit Testing: This is the foundation of the pyramid. Unit tests focus on individual components of the software. These tests are quick to write and execute, so they are usually automated to speed up the process.
2. Integration Testing: This is the middle layer of the pyramid. These tests check the interactions between integrated components to ensure that different parts of the system work together as expected.
3. E2E Testing: This is the top layer. These tests focus on verifying that the entire system works together as expected from the user's perspective. These tests are generally fewer in number compared to other types of tests (like unit and integration tests) because they are more complex, slower to run, and can be more brittle.

How to decide the ratio between unit testing, integration testing, and E2E testing?

If you follow The Test Pyramid strategy, usually you'll go with a testing ratio of roughly 70-80% unit tests, 15-20% integration tests, and 5-10% end-to-end (E2E) tests.

The rationale is that:

• Unit tests are fast, easy to maintain. More importantly, they catch bugs early, so we need a lot of unit tests to cover most of the codebase and ensure that components work correctly in isolation. Achieving around 80% coverage is realistic and effective.
• Integration tests and E2E tests are generally more expensive and complex to perform, so it's best to limit them to critical user flows.

Although these ratios are a good guideline, in actual practices, you should vary it based on your team size and resources.

Integration Testing Best Practices

• Ensure that all modules have been unit tested before moving to the integration phase so that the integration test results are reliable
• Develop a comprehensive test plan and strategy that outlines the scope, objectives, test cases, and resources required for integration testing.
• Automate repetitive and complex test cases to improve testing efficiency and maintain test consistency across different test runs.
• Validate the input test data for higher test reliability
• Perform regression testing after each integration to ensure that new changes do not impact previously integrated components adversely.

Katalon for integration testing

The Katalon Platform is a powerful All-in-One platform to help QA teams plan and design test cases in 1 place without having to use any additional tools. Katalon also supports a wide range of application types, including API Testing and UI Testing to cover all of your needs.

1. Increased Test Coverage

A major pain of testers performing UI Testing is the huge number of devices and browsers to test the application on. The UI of an application may look perfectly fine on this device but is messy on another due to differences in screen sizes, resolution, or other technical specifications. Katalon allows you to stay within budget thanks to its cross-platform, cross-browser testing capabilities on cloud environments.

2. Reduce Test Maintenance Effort

Katalon Platform is also built for test maintenance. When an application is updated, testers need to review if their test cases need to be adapted for the code changes. This is a daunting task that Katalon Platform can help you with thanks to its page object design model approach. 

Katalon stores locators across tests in an object repository. When changes occur, locators and artifacts are already grouped together to make updates easily.

Start Integration Testing With Katalon Free Trial