Der Integrationstest ist gar nicht so leicht zu fassen, denn vieles lässt sich integrieren. Module, Komponenten, Schichten, Services oder ganze Systeme. Hier unterscheiden sich die Integrationstests in einigen Aspekten voneinander. Unterschiedliche Testumgebungen, Tester, Testdaten oder auch die Testbasis. In der Praxis des Software-Testens lassen sich grob zwei Integrationsarten unterscheiden:
Auf die Spezialitäten dieser zwei Teststufen gehe ich gesondert ein. Hier gebe ich zunächst einen Überblick, was alle Integrationstests gemeinsam haben und was beachtet werden sollte. Da Integration mindestens zwei oder mehrere Teile umfasst, sind häufig auch unterschiedliche Entwickler, Teams oder Stakeholder betroffen. Unterschiedliche Verantwortlichkeiten erhöhen dadurch den Abstimmungs- und Koordinationsaufwand fürs Testen. In der Praxis erlebe ich immer wieder, dass deswegen der Integrationstest ignoriert und zu lange aufgeschoben wird. Zudem entsteht in diesem Kontext gerne eine Art Schockstarre: Wer soll beginnen? Wer hat den Hut auf? Wo fangen wir an? Aus diesem Grund habe ich diesem Thema auch ein ganzes Buch gewidmet: “Der Integrationstest – Von Entwurf und Architektur zur Komponenten- und System-Integration”.
Dem Integrationstest wurde eine immense Bedeutung zuteil, als die Objektorientierung Fahrt aufgenommen hat. Die Integrations- und Testmöglichkeiten sind auf einmal sprunghaft angestiegen.
Das ISTQB definiert Integrationstest als: “Eine Teststufe mit dem Schwerpunkt auf dem Zusammenwirken zwischen Komponenten oder Systemen”, und unterscheidet weiter zwischen Komponenten-Integrationstest und System-Integrationstest.
Ich finde diese Unterteilung sehr passend, da hier schon zwei große Bereiche abgedeckt sind. Aber es ist dennoch unerlässlich, im eigenen Kontext zu schauen, welche Integrationen noch wichtig sind: Umgebungen, Datenbanken, Infrastruktur, Daten, Schichten, etc. Und diese natürlich auch zu definieren: Was bedeutet denn Umgebungsintegration für uns?
Als Testbasis für den Integrationstest dienen alle Informationen, die das Zusammenspiel von den Einzelteilen beschreiben: Schnittstellenspezifikationen, Sequenzdiagramme, Anwendungsfälle, UseCases,…
Auch hier gilt es zu beachten, dass es auch nicht-funktionale Aspekte gibt: Wie schnell soll der Austausch sein? Wie viel Last liegt auf der Kopplung? Wie robust ist die Verbindung? Ein Beispiel dazu aus einem meiner Projekte: Dort wurden drei Systeme unterschiedlicher Hersteller gekoppelt. Um Aufwand zu sparen, wurden die Schnittstellen sehr offen umgesetzt. Das macht die Integration einfach, weil nicht viel abgestimmt werden muss. Es führt aber auch dazu, dass Fehler in den Daten und Strukturen einfach weitergegeben werden, eventuell auch ans nächste und übernächste System. So war es auch hier und die Fehlersuche wurde unheimlich aufwendig.
Für die Testfallerstellung eignen sich strukturierte Testfallentwurfsmethoden wie Äquivalenzklassenbildung, Grenzwertanalyse, Entscheidungstabellen oder zustandsbasierter Test. Hier können aus der Beschreibung der Schnittstellen und des Zusammenspiels der Teile sehr viele Testfälle abgeleitet werden.
Ein besonderes Augenmerk verdienen hier Negativtests, d.h. Testfälle, die falsche Strukturen oder Daten nutzen. Denn diese können eine Schnittstelle oder einen Workflow schnell zu Fall bringen.
Bei der Testfallerstellung werden zwangsläufig Lücken in der Spezifikation sichtbar und Fragen auftauchen. Diese sind schnell mit den Software-Architekten, Entwicklern oder fachlichen Bereichen zu klären.
Das Testobjekt für den Integrationstest sind mindestens zwei integrierte Teile des Ganzen. In der Praxis gibt es verschiedene Integrationsvorgehen, z.B. Top-Down oder Bottom-Up. Je nach gewählter Strategie müssen fehlende Teile simuliert werden, damit die Tests durchführbar sind.
Ziel des Integrationstests ist es, das Zusammenspiel der Teile über Schnittstellen oder Workflows zu prüfen. Dabei betrachtet man primär: Sind die Daten korrekt? Sind die Strukturen korrekt? Sind die nicht-funktionalen Aspekte korrekt?
Die Testumgebungen unterscheiden sich bei den verschiedenen Integrationstests. Komponenten-Integrationstests können vielleicht noch in der Entwicklungsumgebung laufen, für System-Integrationstests benötigt man eine dezidierte Testumgebung wie z.B. beim Systemtest.
Ein wichtiger Aspekt dabei ist die Überwachung bzw. das Monitoring. Um die Kommunikation zwischen Teilen zu analysieren, benötigt man Werkzeuge, die diese sichtbar machen. Hier steckt auch eine potentielle Gefahrenquelle drin, nämlich dass diese Werkzeuge die Kommunikation verändern. Vielleicht nicht inhaltlich, aber eventuell die Laufzeit.
Auch das Testdatenmanagement ist stark von der Integrationsebene abhängig. Für Komponenten-Integrationstests kann man sich hier an den Unittests orientieren. Für System-Integrationstests an den Systemtest-Daten.
Testautomatisierung bei den entwicklungsnahen Integrationsteststufen ist ein No-Brainer. Hier gibt es Unmengen an Tools und Werkzeugen, die hier unterstützen. Schwieriger sieht es auf höheren Integrationsebenen wie z.B. dem System-Integrationstest aus. Denn hier müssen mindestens zwei verschiedene Systeme automatisiert werden. Wenn diese sich auch noch technologisch unterscheiden, kann das massive Auswirkungen auf den Aufwand zur Testautomatisierung haben.
Ein paar Ideen dazu finden sich auch in meinem Buch “Basiswissen Testautomatisierung”.
Das Modell der Teststufen kommt aus einer Zeit lange vor agilen Projekten. Und wird deswegen in Scrum und Co gerne ignoriert. Aber schauen wir mal genauer auf das Modell, dann sehen wir, wie wichtig die Ideen und Aspekte der Teststufen natürlich auch in agilen Kontexten sind. Und gerade die Integrationstests sind extrem wichtig. Sie helfen Robustheit im Kleinen (bei den Komponenten) und im Großen (mit anderen Services, Systemen) sicherzustellen. Der Integrationstest taucht auch in Varianten der Testpyramide immer wieder auf.
Wenn ich neu in ein Projekt hinzu komme, gibt es oft ein Problem in Bezug auf Integrationstests:
Unit-, System-, Abnahme- oder Akzeptanztests finden sich in verschiedensten Ausprägungen wieder. Aber die Integrationstests häufig nur als Teil der Unit- oder Systemtests- oder gar nicht. Hier ist auf jeden Fall mehr Bewusstsein nötig.
Wenn Integrationstests existieren, ist das größte Problem meist die Organisation: Wer ist für die Integration verantwortlich? Dieses oder jenes System? Dieses oder jenes Projekt? Dieser oder jener Entwickler oder Architekt? Wurde das nicht entschieden, führt es dazu dass sich niemand verantwortlich fühlt und dementsprechend auch kein Fokus auf diesem Thema liegt. Einige meiner Kunden definieren da gerne auch einen eigenen Testmanager für Integrationstests, was dem Thema schon mehr Bedeutung gibt.
Integrationstests sind essentiell und werden künftig noch mehr an Bedeutung gewinnen. Die immer größere Vernetzung von Systemen und Komponenten, das Bereitstellen von Services und APIs- all das trägt auch dazu bei, immer effizienter testen zu können. Im Alltag ist das nicht immer so einfach, da Infrastrukturfragen und Verantwortlichkeiten zu klären sind. Aber durch dieses Tal der Tränen muss man durch.
Die Werkzeuge, die hierbei unterstützen, werden immer besser. Entwicklungsnah gibt es eine Fülle an Möglichkeiten. Durch die Verwendung von standardisierten Schnittstellenframeworks lassen sich auch Integrationen über Systeme heute besser durchführen und testen.
Es gilt nur Eines zu vermeiden: keine Integrationstests zu machen.