Integration Testing: Ousting Term Confusion
Integration Testing: Ousting Term Confusion
All things have to work together for the overall good of the program. But let's be clear: integration testing isn't as cut and dry as it may seem.
Join the DZone community and get the full member experience.Join For Free
Sensu is an open source monitoring event pipeline. Try it today.
Imagine you bought a beautiful house, but upon moving in you find out that it is not suitable for living. The walls are covered with thin and barely visible cracks, raindrops drip through the freshly painted ceiling, and you cannot even make a cup of tea to warm yourself because of the power line misconnection. This is what happens when the components of a house are not integrated properly.
Software products are in a way similar to buildings. They consist of building blocks (modules) that should be seamlessly interconnected, and the whole system should be integrated with other systems to enable the product to perform its functions. Quality integration testing examples illustrate the paramount importance of this type of testing. Yet, the specialists’ views on the definition of integration testing sometimes differ. Let’s have a closer look and find out the truth.
What Is Integration Testing? The Two Ws
What? Why? Two main definitions of integration testing answer these questions differently.
The popular definition puts it quite simply. It speaks about integration testing for “individual software modules that are combined and tested as a group.” But is this product viable? You never know until you see how it works in real life where it has to interact with a number of external systems. The interaction with outer systems should also be tested.
Another definition, a comprehensive one, is provided by ISTQB. It divides integration testing efforts into two types according to their scope. These types are:
- Component integration testing that checks interconnections between various components of a system.
- System integration testing that verifies seamless interconnection between various independent systems, including hardware and software.
The table below sums up the differences between the two definitions:
To expose faults in the interaction between integrated components.
To expose faults in the interfaces and in the interactions between integrated components or systems.
Individual software modules combined as a group.
- Interfaces between components.
- Interactions between different parts of the system.
- Interfaces between systems.
As we can see, the two definitions are not diametrically opposed. The comprehensive definition comprises the popular one, specifically mentioning components.
However, software functionality isn’t always assured by seamless interconnection between components. Software has to be coherent and come together as a product someone would want to use. Then that product will also need to play well with the outside world: be it a closed corporate portal or a multi-user game open to anyone, it only works successfully when integrated with other systems. All things considered, the ISTQB definition offers a complete picture of integration testing efforts, so we’ll stick to it further on.
The why and what covered, we have yet another important question to answer: how to perform integration testing effectively?
Integration Testing: How-Tos
As the two types of integration testing are different, they require different testing approaches. Let’s consider them.
Component Integration Testing
There are three main techniques used in component integration testing
Bottom-up approach. Testing teams first test the lowest level of the system. Once the level modules are tested and coupled, the team proceeds to the next level modules. When all levels are integrated, the testing team tests the whole system. This approach works when most of the modules of the same development level are ready.
This approach enables detecting and correcting a major fault, if any, at the lowest unit of the program. But as the main program appears only when the last module is integrated and tested, the higher level design flaws can be detected only at the end.
Top-down approach. Testing teams first test the topmost module; then the modules of lower levels are integrated and tested one by one. Stubs (code fragments) replace the modules that are not yet fit for integration. When all the modules are integrated, the team tests the whole system. This technique concentrates on interconnections between the modules.
This approach enables a very consistent product, and writing stubs requires less time. However, in this case, basic functionality is tested at the end of the cycle.
- Big bang approach. Developers couple the bulk of the system, and QA engineers test it.
This approach is controversial. On the one hand, testers have a complete system and its components to test at their disposal, no surprises involved. On the other hand, testing may detect many critical bugs, including those hampering the development environment. As development is finished before integration testing starts, it is difficult to trace the cause of failures.
System Integration Testing: Effective Approach
The simplest and yet effective way to conduct system integration testing (SIT) is data-driven approach, which checks how the data is rendered in the dataflow from system to system. Applying this approach, testing engineers inspect data on three levels:
- Integration level (a web service or middleware)
- Database level
- Application level
Data should remain unchanged throughout the transition process. Besides, the processes involving several systems should run smoothly, data changes should be shown in all the systems involved and both systems should detect erroneous data when it is sent. Besides, performing SIT, testing engineers rely on product specifications and various technical documents describing work processes of the other system or systems. Ensuring efficient communication with experts working on the other system is the best strategy in this case.
Wrapping It Up
Software products, especially complex ones, can never be jointless. They usually consist of several layers of modules that should be seamlessly integrated with one another. Software integration test verifies the quality of these interconnections.
Software testing engineers have different approaches to integration testing. The most popular one discusses integration of modules within a system and various techniques to implement it. However, it says nothing about system integration, which is a prerequisite for successful product work in real life.
ISTQB offers another definition of what is integration testing. Speaking about component and system integration testing, this approach recognizes the two-fold nature of this type of testing and stresses the importance of data integrity during transitions from system to system. This definition is more comprehensive, and we stick to it in our testing practice.
Opinions expressed by DZone contributors are their own.