The integration testing is not so easy to grasp, because many things can be integrated. Modules, components, layers, services or entire systems. Here the integration tests differ in some aspects from each other. Different test environments, testers, test data or also 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 what 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 see time and again that integration testing is ignored and postponed for too long because of this. In addition, a kind of shock paralysis tends to arise in this context: Who should start? Who is wearing 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. The integration and testing possibilities 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 to see which integrations are still important: Environments, databases, infrastructure, data, layers, etc. And to define these, of course: 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,...
Here, too, it is important to note that there are also non-functional aspects: How fast should the exchange be? How much load is on the coupling? How robust is the connection? Here is 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. But it also means that errors in the data and structures are simply passed on, possibly to the next system and the one after that. This was also the case here, and troubleshooting became 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. There is also a potential source of danger here, namely that these tools change the communication. Perhaps not in terms of content, but possibly in terms of 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 provide support here. 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 the like. But if we take a closer look at the model, 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 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 a wide variety of forms. But the integration tests often only as part of the unit or system tests-or not at all. More awareness is definitely needed here.
When integration tests exist, the biggest problem is usually the organization: Who is responsible for the integration? This or that system? This or that project? This or that developer or architect? If this has not been decided, it 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 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 possibilities close to development. The use of standardized interface frameworks also makes it easier to carry out and test integrations across systems today.
There is only one thing to avoid: not doing integration tests.