The integration testing is not so easy to grasp. Because many things can be integrated. Modules, components, layers, services or entire systems. Here integration tests differ from each other in some aspects. Different test environments, testers, test data or even the test basis. In the practice of software testing, a rough distinction can be made between two types of integration:
- Component integration: Integration within the system, e.g. frameworks, modules, data management, etc.
- System integration: Integration of the system with other systems, e.g. via interfaces, data exchange, etc.
I will discuss the specialties of these two test levels separately. Here I first give an overview of what all integration tests have in common and should be considered. Since integration involves at least two or more parts, different developers, teams, or stakeholders are often involved. Different responsibilities increase the coordination effort for testing. In practice, I experience time and again that the integration testing is ignored and postponed for too long because of this. In addition, a kind of paralysis of shock tends to arise in this context. Who should start? Who wears the hat? Where do we start? For this reason, I have dedicated an entire book to this topic: "The integration testing - From Design and Architecture to Component and System Integration".
The integration testing became immensely important when object orientation took off. Here, the integration and testing possibilities had suddenly increased by leaps and bounds.
Definition integration testing
The ISTQB defines integration testing as: "A test level focusing on the interaction between components or systems." And further distinguishes between component-integration testing and system-integration testing.
I find this subdivision very appropriate, since two large areas are already covered here. But it is still essential to look in your own context, which integrations are still important: Environments, Databases, Infrastructure, Data, Layers, etc. And of course to define them: What does environment integration mean for us?
All information describing the interaction of the individual parts serves as a test basis for the integration testing : interface specifications, sequence diagrams, use cases,...
Again, please pay attention to this: There are also non-functional aspects here: How fast should the exchange be? How much load is on the coupling? How robust is the connection? An example from one of my projects: Three systems from different manufacturers were coupled there. To save effort, the interfaces were implemented very openly. This makes integration easy because not much coordination is required. However, it also leads to the fact that errors in the data and structures are simply passed on, possibly also to the next system and the one after that. This was also the case here and troubleshooting was incredibly time-consuming.
Test case creation for integration tests
Structured test case design methods such as equivalence class formation, limit value analysis, decision tables or state-based testing are suitable for test case creation. Here, a large number of test cases can be derived from the description of the interfaces and the interaction of the parts.
Negative tests, i.e. test cases that use incorrect structures or data, deserve special attention here. Because these can quickly bring down an interface or a workflow.
During test case creation, gaps in the specification will inevitably become visible and questions will arise. These must be quickly clarified with the software architects, developers or specialist areas.
The test object for the integration testing is at least two integrated parts of the whole. In practice, there are different integration approaches, e.g. top-down or bottom-up. Depending on the chosen strategy, missing parts must be simulated so that the tests are feasible.
Test objectives of the integration test
The aim of the integration test is to check the interaction of the parts via interfaces or workflows. The primary considerations are: Are the data correct? Are the structures correct? Are the non-functional aspects correct?
Test environment for integration tests
The test environments differ for the various integration tests. Component integration tests can perhaps still run in the development environment, but for system integration tests you need a dedicated test environment such as with the system testing.
An important aspect of this is monitoring. In order to analyze the communication between parts, you need tools that make it visible. This is also a potential source of danger, namely that these tools change the communication. Maybe not in terms of content, but possibly the runtime.
Test data management is also strongly dependent on the integration level. For component integration tests, the unit tests can be used as a guide. For system integration tests, use the system testing data.
Test automation of the integration test
Test automation at the development-related integration test stages is a no-brainer. There are tons of tools and instruments that support this. The situation is more difficult at higher integration levels, such as the systemintegration testing . Here, at least two different systems have to be automated. If these also differ technologically, this can have a massive impact on the test automation effort.
You can also find some ideas in my book "Basiswissen Testautomatisierung".
integration testing in agile projects
The model of test levels comes from a time long before agile projects. And is therefore often ignored in Scrum and Co. But let's take a closer look at the model. Then we see how important the ideas and aspects of the test levels are, of course, also in agile contexts. And especially the integration tests are extremely important. They help to ensure robustness on a small scale (with components) and on a large scale (with other services, systems). The integration testing also appears again and again in variants of the test pyramid.
When I'm new to a project, there's often an issue around integration testing:
- There isn't.
Unit, system, acceptance or acceptance tests can be found in various forms. But integration tests are often only part of the unit or system tests. Or not at all. In any case, more awareness is needed here.
When integration tests exist, the biggest problem is usually the organization: Who is responsible for the integration? One system or the other? One project or the other? One or the other developer or architect? Not deciding this leads to the fact that nobody feels responsible and therefore there is no focus on this topic. Some of my customers like to define their own test manager for integration tests, which gives the topic more importance.
integration testing in practice
Integration tests are essential and will become even more important in the future. The ever-increasing networking of systems and components, the provision of services and APIs. All of this also contributes to being able to test more and more efficiently. In everyday life, this is not always so easy, as infrastructure issues and responsibilities have to be clarified. But you have to get through this valley of tears.
The tools that support this are improving all the time. There is a wealth of development-related options. Through the use of standardized interface frameworks, integrations across systems can also be better implemented and tested today.
There is only one thing to avoid: not doing integration tests.