Die Komplexität der Integration

Der Duden definiert Integration als “(Wieder)herstellung einer Einheit (aus Differenziertem); Vervollständigung” und somit ein großes Ziel, auf das dieser Prozess zusteuert. Die konkreten Ausprägungen gerade in der Softwareentwicklung, könnten unterschiedlicher kaum sein: horizontal, vertikal, Microservices, APIs, lose gekoppelt, Schichten, Silos, eng verzahnt, als Integrationsplattform oder dateibasiert, Kapselung usw. – die Integration dessen hat umso mehr Ziele, da hier zusätzlich noch integrationsspezifische Aspekte wie die Integrationsstrategie inklusive Anforderungen an die Testumgebung hinzukommen.

Um hier den Überblick zu behalten, braucht es Struktur. Und wir möchten an dieser Stelle ein paar Dimensionen aufzeigen, die bei der Klassifikation der eigenen Integrationstests oder bei der Prüfung auf weitere notwendige Dimensionen helfen können.

Dimension: Testziele

Ein typisches Testziel des Integrationstests ist der Nachweis der korrekten Kommunikation zwischen den zu integrierenden Objekten. Dabei geht es, wie so oft, vorrangig um die Minimierung des Risikos unentdeckter Fehler und um das frühzeitige Finden von Fehlerwirkungen.

Meist stehen die funktionalen Aspekte im Vordergrund. Aber auch nicht-funktionale Aspekte spielen eine wesentliche Rolle: Zuverlässigkeit, Gebrauchstauglichkeit, Informationssicherheit (Security), Kompatibilität, Übertragbarkeit, Änderbarkeit, Performanz/ Effizienz (siehe ISO 25010). Je nach Branche, Anwendungszweck und Kundenwünschen können die nicht-funktionalen Aspekte mehr und mehr in den Fokus rücken und sollten entsprechend berücksichtigt werden.

Dimension: Testobjekte

Das zu prüfende Testobjekt beeinflusst maßgeblich die Ausgestaltung der Tests und der Testumgebung: Schnittstellen, Services, APIs, Datenbanken, Subsysteme, aber auch Infrastruktur und Hardware.

Wesentlich für den Erfolg der Integrationstests ist, dass die einzelnen Integrationsobjekte unabhängig von der Kommunikation an den Schnittstellen bereits als Produkt oder Teilsystem getestet wurden. Ansonsten lässt sich im Fehlerfall nicht feststellen, ob die Probleme von für Schnittstellen relevanten oder irrelevanten Fehlern herrühren. So kann viel Zeit für die Fehlersuche eingespart werden.

Dimension: Testebene

Je nach Testobjekt spielt der Integrationstest auf einer anderen Ebene, auf einem anderen Abstraktionsniveau:

• Units: Hier gibt es meist eine gute Test-Unterstützung durch die Entwicklungsumgebung bzw. durch das Framework.
• Systemkomponenten: Eingebundene Bibliotheken oder Datenbanken unterstützen den Test.
• Systeme: Selbst wenn Schnittstellen von Softwaresystemen gut dokumentiert sind, ist die Integration komplex und fehleranfällig.
• Integration von Software und Hardware: Hier besteht für Tests eine besondere Herausforderung, auch nicht-funktionale Aspekte zu berücksichtigen.
• Integration von Software und Daten: Beide beschreiben Informationen, die zusammenpassen müssen. Meist beschreibt Ersteres einen generischen Teil und Letzteres den projektspezifischen Teil. Hier ist der Spagat zwischen allgemeingültiger und projektspezifischer Prüfung wichtig.

Auch ebenenübergreifend kann es komplex werden: Findet die Integration auf der Systemebene (oftmals Black Box) statt, fokussiert aber auf Eigenschaften, die nur bei einer White-Box-Betrachtung erkennbar sind, ist dieser Spagat für viele Entwicklungsteams eine besondere Herausforderung.

Auf jeden Fall müssen bei der Integration verschiedene Teams von verschiedenen Ebenen mit verschiedenen Betrachtungswinkeln zusammenspielen, um die effiziente Integration zu ermöglichen.

Dimension: Testbasis

Als Testbasis können zum Beispiel dienen: Schnittstellenspezifikationen, Definitionen von Kommunikationsprotokollen, Sequenzdiagramme, Modelle wie Zustandsdiagramme, Architekturbeschreibungen, Software- und Systementwürfe, Workflows, Anwendungsfälle oder Beschreibungen von Datenstrukturen.

Generell gilt: Je höher der Grad der Formalisierung, desto eher kann man sich auf die Ergebnisse verlassen. Wenn wir sicher sein können, dass die Schnittstellenspezifikationen der kommunizierenden Produkte konsistent zueinander sind, dann ist bereits viel gewonnen.

Dimension: Typische Fehler

Mit Integrationstests können viele verschiedene Arten von Fehlern entdeckt werden, zum Beispiel: falsche Datenstrukturen, fehlerhafte Schnittstellen, falsche Annahmen zu den übergebenen Daten, fehlende Daten, Probleme bei der Performanz oder der Sicherheit (Verschlüsselung).

Diese Dimensionen können in fast beliebiger Kombination betrachtet werden und spannen somit ein großes Feld an möglichen Integrationstests auf. Während Komponenten- oder Systemtests eher homogen sind, ist dieses Feld der Integrationstests sehr unterschiedlich in Umsetzung, Technologie und Methodik. Viele Tests, insbesondere nicht-funktionale, sind nur automatisiert sinnvoll testbar. Die hier beschriebene Menge an Kombinationsmöglichkeiten, die auf den Test durchschlagen, legt die Notwendigkeit der Effizienzsteigerung über Testautomatisierung ebenfalls nahe.

Und auch in dem Etablieren der Testautomatisierung selbst liegt eine große Herausforderung, da dieser Schritt oft Anpassungen in den Frameworks oder die Entwicklung eigener Testwerkzeuge benötigt – ein Aufwand, der nicht zu unterschätzen ist.

Fazit

Erschlagen von der Fülle der Möglichkeiten möchte man als Testmanager oder Tester fast den Kopf in den Sand stecken. Aber lassen Sie sich nicht entmutigen und fangen einfach klein an: Spannen Sie ein Feld mit den wichtigsten Dimensionen auf und prüfen Sie, wo Sie Integrationstests bereits gut umgesetzt haben, wo vielleicht noch Lücken sind und weitere Tests einen echten Mehrwert bringen würden, und starten Sie danach die Verbesserung. Viel Erfolg dabei!