Integration testing is an essential aspect of software testing that is designed to assess how efficiently different applications integrate together.
Most contemporary businesses rely on multiple different software modules every day, and integration allows these applications to work together to improve efficiency and streamline workflows.
Integration testing is important because smooth integration is what makes software modules effective. When each software module is programmed by a different developer using an entirely different programming logic, there’s no reason to think that separate modules will integrate smoothly from the beginning.
Integration testing allows IT specialists to evaluate how well different modules are working together and implement changes to increase their effectiveness
What is integration testing?
The integration testing meaning refers to the process of testing the interfaces between two components or software modules to assess how data is transferred between them.
Integration testing strategies allow development teams and IT specialists to detect defects that may be introduced when two or more software modules are integrated, as well as to evaluate the overall fit and function of the combined software elements.
Integration testing usually occurs after unit testing, which involves the testing of individual modules and units. Once it’s been determined that each unit works in isolation, integration testing assesses how all units work when combined.
Integration testing is an incremental process, usually requiring testers to integrate modules one by one and carry out testing each step of the way.
Integration tests are dependent on a well-defined interface specification between components being tested. These tests should be automated as much as possible so they can be run frequently, to catch problems early before they become complex issues that take time and resources to fix later on in development.
Why perform integration tests?
Integration testing is a type of software testing that ensures that all components of the applications work together as expected.
The objective of integration testing is to verify whether or not the integration of various modules and components in an application meets the requirements of the user as well as the technical and performance requirements of the organisation.
Some of the reasons why system integration testing is commonplace today include:
• Different developers use different logic when they’re developing modules even for the same software application. Integration testing is the only way to ensure that separate modules work together as they should.
• When data travels from one module to another, the structure of that data might change, and some values can be removed. This can cause significant issues in the operation of the modules.
• Modules interact with third-party tools and APIs. It is important to test integration to ensure that the data accepted by the API or third-party tool is correct and generated responses are also in line with expectations.
• If a developer deploys changes without unit testing, integration testing is essential to assess the effectiveness of the changes.
Ultimately, integration testing is necessary to ensure that multi-module software applications work together as expected, meet the requirements of users, and adhere to the technical specifications laid out at the beginning of a project.
The benefits of integration tests
There are lots of benefits to performing integration testing immediately after unit testing software modules.
Integration testing can help development teams to identify and fix issues early and maximise application performance and user satisfaction in an efficient and effective way.
1. Identify integration issues between modules
Integration testing is the most accurate and efficient way to identify issues in communication and data exchange between two or more modules within an application.
Even if every module works perfectly in isolation, if they don’t run smoothly together, a software application isn’t fit for purpose. This means that integration testing is an essential step in the testing process for most software teams.
2. More comprehensive than unit tests
Integration tests are more comprehensive than unit tests because they offer insights into how modules work together as well as apart.
Unit tests focus on the smallest unit of code in an application, such as a class or a method, while integration tests take a broader approach.
3. Resolve bugs early
Bugs found during the integration testing stage are usually easier to resolve than bugs found later, during system and acceptance testing stages.
This is because integration tests focus on fewer modules at a time, involving fewer variables.
Additionally, when a bug is found during integration testing, it can be addressed while the components are still fresh in the minds of developers and testers.
4. Improve test coverage and reliability
Integration testing improves test coverage and provides an additional level of reliability to software modules and applications.
Integration testing is capable of identifying bugs which are more difficult to detect during unit testing.
Integration testing also identifies any gaps, or missing functionality, between various software components before system testing.
Challenges and limitations in integration testing
Integration testing is an essential step for most development teams, but that doesn’t mean it is 100% perfect. It’s a complex process that can be time-consuming, which means that it is essential to plan and coordinate integration testing carefully, involving relevant departments where necessary.
Integration testing can be especially challenging when working on agile projects the development of multiple features at once is standard.
Integration testing can pose many challenges to software teams, some of which are covered below.
1. Integration testing is resource-intensive
Integration tests are resource-intensive. They may involve running several different tests simultaneously against several copies of production code or data.
In addition, due attention must be paid to making sure that each test does not negatively impact performance on its own or interfere with any other ongoing tests running simultaneously in parallel threads. This dependency on a variety of resources can increase the complexity of a test suite and make it difficult to consistently reproduce results in later stages of development.
2. It’s difficult to perform
Integration testing can be a complex process, especially when testing the integration of many different systems including databases, platforms, and environments.
As well as being resource-heavy, integration testing requires experience and technical expertise as well as an understanding of project goals and objectives.
It is one of the most intensive types of testing that software teams carry out, especially when opting for manual integration testing as opposed to automated testing.
3. Integration testing takes time
Another concern with manual integration testing is the sheer amount of time it takes.
Manual testing is done in increments, with testers adding each new module one by one and testing the functionality and performance of every module at each stage of the testing process.
This takes time, and for some development teams, it may feel like time they don’t have to spare, especially if early testing doesn’t indicate any issues.
4. Fixes aren’t always easy
Perhaps one of the most difficult challenges that development teams face during the process of integration testing is the stage of fixing the issues that arise during testing.
This can be particularly challenging when working with legacy systems, which may be very difficult to integrate with more modern applications. Successful changes ensure that both systems work properly in conjunction with one another and the influence of either system does not create any issues for the other. Achieving this isn’t easy.
Types of integration testing
There are different ways to approach integration testing, each of which has its own benefits and drawbacks. The type of integration testing that is most appropriate for one team or project depends on the requirements of the project.
Generally speaking, it is possible to separate integration testing into two primary categories: incremental integration testing and big bang integration testing.
Incremental integration testing is the most common type of testing, but some teams opt for big bang testing when working on smaller projects.
1. Incremental integration testing
Incremental integration testing is the process of testing software modules one by one. The incremental approach is popular because it allows development teams to test for defects in stages, each broken up into smaller units. This makes it easier to identify and locate bugs when they arise and hastens the bug fixing process.
Incremental integration testing uses stubs and drivers to set up the transmission. These are duplicate programmes which effectively emulate the communication between two modules.
There are three different approaches to integration testing, each of which will be explained below: top-down integration testing, bottom-up integration testing, and sandwich integration testing.
2. Big bang integration testing
Big bang integration testing is a type of integration testing that software teams can perform only after all individual modules have been developed.
When carrying out big bang testing, all of the modules are coupled to form a single software system and tested simultaneously, contrasting with the one-at-a-time structure of incremental integration testing.
Big bang integration testing suits smaller systems where, if a bug arises, there is less room for confusion regarding the bug’s location and cause.
The primary disadvantage of big bang integration testing is that, during the course of testing, some of the team’s resources will be unproductive because it is necessary to wait for all modules to be developed before testing can start. This means that big bang testing isn’t always the most efficient and fast method of testing, though it can still save time in the long run for some teams.
Approaches to incremental integration testing
There are three distinct approaches to incremental integration testing. Each of these approaches carries its own advantages and disadvantages, and it is important for development teams to identify the approach that is going to work best for their project before testing begins.
The most popular approaches in incremental integration testing are top-down testing, bottom-up testing, and sandwich testing.
Let’s explore each of these types of integration testing individually.
1. Top-down integration testing
Top-down integration is a testing approach in which the integration test is performed from the top of the system stack through each layer of the software architecture. The control flow of the test moves from the top to the bottom, starting with the user interface (UI) and ending at the software database.
This method of integration testing is suitable for use with both web applications and software architectures with multiple layers.
The advantage of using the top-down integration testing approach is that it is relatively simple to implement and has minimal dependencies on other parts of your application.
The top-down approach uses stubs, which are generally easier to implement than drivers. The simple and incremental nature of the top-down approach makes it easy to identify interface errors quickly, although some critics of this module say that it results in inadequate testing of lower-level modules.
2. Bottom-up integration testing
Bottom-up integration testing is a process in which individual components are tested and integrated starting from the lowest module in the architecture and working upwards.
Bottom-up integration testing allows teams to begin testing when high-level modules are still in development.
This approach is most commonly used when teams are trying to integrate off-the-shelf components with existing products.
Bottom-up integration testing has high success rates and is a relatively fast and efficient form of integration testing. Because bottom-up integration testing tests lower modules first, testing teams can ensure that an application’s most important and foundational models run smoothly together before moving on to testing higher-level modules.
One of the biggest drawbacks of bottom-up testing is that it is impossible to observe system-level functions until the last test driver is in place.
3. Sandwich integration testing
Sandwich integration testing is a methodology that combines the approaches of both top-down and bottom-up testing.
In sandwich integration testing, a system is separated into three layers: a middle layer, a top layer, and a bottom layer. Testers start testing modules from the middle layer and proceed upwards and downwards, ensuring that both top level and bottom level modules are prioritised. Sandwich integration testing uses both stubs and drivers to test modules at all levels.
Sandwich integration testing is particularly useful in the case of large-scale projects that can be separated into multiple sub-projects, or when testing software modules that are themselves extremely large.
However, sandwich testing can be extremely time-consuming. This form of testing also doesn’t provide opportunities to test modules that form sub-divisions before final integration, which can cause serious issues if these modules are overlooked.
What do we test in integration testing?
The objective of integration testing is to ensure that there are no communication issues or data transfer issues between different modules working within the same application.
Integration tests are performed after unit tests and before acceptance tests, and they ensure that all parts of a system work correctly when it is assembled as a cohesive whole.
The purpose of integration testing is to test:
• Whether software modules work well when you integrate them together
• Whether there are interface errors in a software’s interface
• Whether modules are synchronised and can function simultaneously without errors
• Whether an application is vulnerable to exception handling defects
How to perform integration tests
Integration testing is carried out after unit testing. The precise methodology for conducting integration testing depends on whether you choose to use the incremental testing or big bang testing type, and what approach you take to your integration testing.
1. The relevant steps in any integration test are:
• Prepare an integration test plan
• Decide what approach you’re going to take to testing
• Design test cases, test scenarios, and test scripts
• Deploy chosen modules together and run your tests
• Track identified bugs and record test results
• Fix bugs and implement changes
• Repeat the steps above until your tests are complete
Perhaps the most complex step of this testing process is creating an integration test plan. It is essential to understand what an integration test plan is and how to create one in advance of beginning integration testing.
2. Create an integration test plan
The first stage of running integration tests is always creating a thorough integration test plan. An integration test plan contains test cases, scenarios, and environment details, and lays out how the integration testing will be carried out.
A test plan is clear, detailed, and easy to follow, effectively detailing all aspects of an integration test for all involved parties and stakeholders.
Purpose and scope
The test plan lays out the purpose and scope of your integration test, outlining which software components you are testing and what you’re testing them for.
Most integration testing projects will have relatively short sectioning outlining purpose and scope, but these are still useful as reference tools for staff members involved in the testing process.
Integration Test plan
The test plan section of your document outlines what you are testing and how.
This part of your test plan should detail the modules you are testing, and which features specifically you plan to test. It also outlines the order of integration testing if you’re using an incremental testing approach.
The test plan might also outline test deliverables that are necessary before, during, and after integration testing takes place. This section also outlines the tasks necessary for testing and any specific environmental needs that need to be considered during the test process.
Integration Test case specifications
Test case specifications lay out all of the individual tests between modules and outline the input specification, output specification, and environmental needs for each test.
This section of the integration test plan should be clear, concise, and unambiguous, making it easy for staff members to follow set test cases with little decision-making involved.
Integration Test procedures
The test procedures section of the test plan outlines all of the procedures you will use in your integration test, as well as the purpose of each procedure and the steps involved.
Alongside the test case specifications and test plan, this section should help stakeholders and testers to understand exactly how each integration test is to be conducted.
Integration Test results
Leave space at the end of a test plan to record test results once integration testing is complete.
For each test case outlined earlier, include the date on which the test took place and details of the test results as per the objectives of each outlined test.
Entry and exit criteria for integration tests
Entry and exit criteria for integration tests define when it is possible to begin integration tests and when integration tests are fully complete.
• Integration test plan document is signed off
• Integration test cases are fully prepared
• Test data has been created
• Unit testing of all modules is complete
• Critical and high-priority defects have been fixed
• The test environment is ready for integration
• All of the integration tests are complete
• All critical and priority defects have been closed
• Test report has been prepared
Integration test cases
When you are writing an integration test plan, you will include integration test cases in this document.
Integration test cases focus on the interface between two modules, including integrated links and data transfer between the modules or systems.
1. What is an integration test case?
An integration test case is a particular set of instructions that outlines a test between two or more modules within an integration test.
The test case defines the objective of each integration test, a description of how to carry out this test, and details of the desired outcome.
Most integration testing projects involve a long list of test cases to be carried out on various modules across a software application.
2. Things to keep in mind when writing integration test cases
When you are writing integration test cases for a test plan document, consider the following tips:
• Integration test cases should be written from the perspective of the user
• Write test cases for all interface features
• Don’t forget about UI elements that might be affected by changes in another part of your system
• Write test cases in clear language that is easily understood by the entire testing team
• Keep relevant project documentation nearby when writing test cases
Examples of integration tests
Integration testing examples are an effective way to illustrate the processes involved in a typical integration test.
Below are two examples of integration tests and how a testing team might approach testing.
Example one: Online shopping software
An IT company is asked to create an online shopping application for a website that sells sporting goods. Modules coded for the application include modules on user registration, billing, and payments. After each module is developed separately, unit testing is performed to ensure that each module works as it should. After unit testing, integration testing takes place.
An integration test plan is written up containing a number of test cases that outline which functionality requires testing and how.
An example of a test case in this document is:
Test case ID: 1
Test case objective:
Check the interface link between the login and checkout modules.
Test case description:
Enter log-in details, add items to the basket, and proceed through the checkout process.
Test case desired outcome:
Items in the basket are retained, payments are taken, and the checkout process completes successfully.
Once the testing team carried out all of the integration test cases listed in the test plan, identified bugs were fixed and the test report was written up.
Example two: Online communication platform
An IT company is asked to create an internal social media platform that can be used for communication between colleagues and staff members within an organisation.
Modules coded for the application include modules on user registration, mailbox, and forums.
The following is an example of a test case that might be included in the integration test plan for this project:
Test case ID: 1
Test case objective:
Test the interface link between the log-in and mailbox modules.
Test case description:
Enter login credentials and click log-in, check the mailbox.
Test case desired outcome:
Mailbox directs the user to their personal mailbox, where all mail is present.
If the desired outcome isn’t realised, the testing team report a defect and this can then be fixed in development before the test report is concluded.
Integration testing best practices
Following best practices when carrying out integration testing can help testing teams to increase the accuracy of their tests and ensure that no serious or high-priority defects are overlooked.
1. Determine test data correctly
It is essential that test data is accurate to create relevant testing scenarios that can be reused in the future.
2. Identify critical units prior to integration testing
Identifying those units that are most critical to your software application prior to testing makes it easy to focus more of your efforts on critical modules, especially if resources are low.
3. Use an automation tool
Using integration test automation software can save time and money and make it easy to carry out fully comprehensive integration testing even with relatively few resources.
4. Run tests across all relevant devices
If your software is meant to run across multiple devices, including PCs, tablets, and smartphones, carry out thorough integration testing across all devices before signing off on the software.
Checklist for integration testing implementation
Before you start integration tests, check that you have carried out every item on this checklist first.
• Create a suitable test environment
• Choose a testing approach
• Define the scope of the tests
• Write a thorough test plan document
• Outline detailed test cases
• Identify objectives and expected outcomes
• Outline entry and exit criteria for the tests
• Define an issue triage process to use when issues arise
• Establish a communication plan between teams
Integration testing tools
Using automated integration testing tools can make integration testing simpler, more effective, and less time-consuming, especially for testing teams that are already stretched.
Integration testing tools can automate part or all of the testing process, and offer features including automated logging and monitoring, automated test case creation and test result analysis and reporting.
Integration test automation tools are available online for free or under paid enterprise models. There are benefits and limitations to both free and enterprise testing tools, and which is better for your organisation ultimately boils down to the needs of your team and the resources at your disposal.
1. Free integration testing tools
Free integration testing tools are available for download online across the web. Free tools are offered by software vendors who either want to increase their visibility by offering free apps or make money via in-app purchases.
Some of the benefits of opting for free testing tools include:
• If they are not useful to your organisation, you haven’t lost any money
• Free tools are available to assist with almost any aspect of integration testing
Some of the drawbacks of free integration testing tools include:
• You can waste a lot of time looking for the best tools
• The quality of most free tools is difficult to verify
• Most free tools are limited in terms of support and capabilities
• Free tools may include additional features that you have to pay for
• Free tools may require you to register with the vendor and agree to share your data
2. Enterprise integration testing tools
Enterprise integration testing tools like ZAPTEST are a more expensive option, but theyoffer more advanced, powerful, and scalable functions.
Enterprise integration testing tools offer superior customization options and are backed up by professional support from the software vendor.
Some of the benefits of using enterprise integration testing tools include:
• Customise your functionality to your organisation’s needs and workflows
• Enterprise software offers superior data security
• More scalability included in the software
• Enterprise software offers verifiable quality and performance
• Usually includes technical support and troubleshooting
The main limitation of enterprise testing software include:
• Not all enterprise software will be exactly what you’re looking for…some tools like ZAPTEST, offer full stack testing suite with both low code and coded options, while other tools are far from offering the rich functionality required by a complex organization
• Enterprise software costs money. In addition, unlike ZAPTEST, which offers unlimited licenses for a fixed fee, most Enterprise level integration testing tools will limit the number of licenses. This means that as the company scales, so does your costs of integration testing.
3. When should you use enterprise vs free integration testing tools?
If you are weighing up whether free tools or enterprise tools are the best choices for your organisation, it is important to factor in the needs of your team and the resources you have to work with.
Follow the tips below to make the decision that is best for your organisation when deciding between free vs enterprise integration testing tools.
• What can your organisation afford? Will enterprise tools fit into your budget?
• What do you want testing tools to do for you, and do any free tools offer this functionality?
• How capable is your team, and will they need extra technical support?
• How much could a mistake cost your organisation?
• How important is data security within your organisation?
• Will your organisation’s needs scale up in the future?
If you are not sure, you could try out free testing tools first before moving on to enterprise tools later, or you could look for enterprise testing tools that offer free trials to try before you buy. ZAPTEST, for example, offers both free and paid for plans for your integration testing needs.
Offering customisable functionality that scales with your business, ZAPTEST is perfect for small, medium, and large businesses wanting to simplify integration testing without compromising on quality. Book your demo today to find out more about ZAPTEST