Warum es nicht reicht, Software bis zur Schnittstelle zu testen – Die Bedeutung von Integrationstests

Wie sich Testautomatisierung in agilen Projekten sinnvoll umsetzen und in die Deployment-Pipeline einbinden lässt, hat mein Kollege Simon Damrau in seinem Beitrag beschrieben. In diesem zweiten Teil geht es um die Bedeutung von Integrationstests in agilen Projekten. Erfahren Sie mehr über Komponentenintegrationstests und Systemintegrationstests und die wichtigsten Anforderungen an die Unterstützung durch ein Automatisierungstool. 

Prozessorientierte Sichtweise

Als Freizeitsportler und Materialwart im Alpenverein bestelle ich häufig Ersatzteile und Material bei verschiedenen Onlineshops. In den letzten Jahren habe ich unterschiedliche Entschuldigungsmails bekommen, zu Bestandsabweichungen, zu Ware, die irrtümlich zweimal versendet wurde (großzügigerweise durfte ich das zweite Exemplar behalten), zu einem nicht erfolgten Lastschrifteinzug (über ein Jahr nachdem die Ware angekommen war) und einmal zu einer fehlenden Zuordnung der Bestellung zu Kundendaten. Erst aufgrund einer Nachfrage konnte der Händler die Bestellung wieder meinem Konto zuordnen.

Solche Fehler kosten den Unternehmen wertvolle Zeit und Geld und sie führen zu kritischen Bewertungen. Für eine erfolgreiche Durchführung des Bestellprozesses muss der Bestellvorgang auf der Seite des Online-Shops in Zusammenspiel mit der Lagerhaltung, dem Versand, der Rechnungserstellung sowie dem Zahlungsverkehr und der Buchhaltung funktionieren.

In Bezug auf die Qualitätssicherung bedeutet das, dass automatisierte Tests der einzelnen Systeme die Basis für eine gute Testabdeckung und somit unabdingbar sind. Die Einbindung der Tests in die CI/CD Abläufe ist Stand der Technik. Darüber hinaus sind Integrationstests erforderlich. Aus unserer Projekterfahrung wissen wir, dass Fehler häufig an den Schnittstellen zwischen verschiedenen Systemen auftreten und diese Fehler oft gravierend und damit aufwendig zu beheben sind.

Klassischerweise wurden und werden hierzu in vielen Organisationen vor festen Release-Terminen (üblicherweise zwei- bis viermal im Jahr) umfangreiche Integrations- und Systemtests durchgeführt. Über mehrere Wochen werden die beteiligten Systeme in Interaktion miteinander teils manuell und teils automatisiert getestet. Mit dem Wunsch nach schnellen Reaktionen auf Entwicklungen im Markt und kurzen Release-Zyklen wurden lange Testphasen immer mehr zum Hindernis.

Werden jetzt einzelne oder mehrere Systeme agil weiterentwickelt, können mit jedem Inkrement neue Konstellationen entstehen, die Nebenwirkungen und Folgen mit sich bringen können: sowohl innerhalb der eigenen Anwendungen als auch im Zusammenspiel mit anderen Systemen. Spätestens wenn diese Konstellation auftritt, wird eine neue Teststrategie benötigt.

Erfolgreiche Integration durch Zusammenarbeit

Es ist verständlich und auch richtig, dass Entwicklungsteams sich primär auf die Umsetzung der Anforderungen im eigenen System konzentrieren und hier über detaillierte Kenntnisse verfügen. Gleichzeitig ist eine Kooperation mit anderen Teams erforderlich.

Die Umsetzung der Anforderungen im eigenen System gemäß Spezifikation hat sich in der Praxis als nicht ausreichend erwiesen. Oftmals führen unberücksichtigte Konstellationen, Änderungen in Nachbarsystemen oder schlicht Missverständnisse zu Inkompatibilitäten. Das Prinzip „Ein jeder kehre vor seiner Tür“ ist meistens wenig hilfreich, um solche Fälle zu lösen. Stattdessen sind Zusammenarbeit und praktikable Lösungen gefragt.

Im Testumfeld ist die einfachste Lösung, gemeinsam mit den direkten Nachbarteams Tests durchzuführen. Somit ist in den Testteams tiefes Wissen zu den Systemen vorhanden und müssen die Beteiligten nicht die gesamte Prozesskette kennen. In großen Organisationen empfiehlt es sich, zusätzlich unabhängige Tester mit einem übergreifenden Blick auf Prozessketten einzusetzen.

Koordination mehrerer Teams als Herausforderung

In größeren Organisationen werden agile Teams fast immer Abhängigkeiten zu anderen Teams haben. Arbeiten die Nachbarteams ebenfalls agil, stellt sich die Frage nach der Koordination bei der Umsetzung von Anforderungen. Der Kundennutzen wird dann erreicht, wenn die Anforderung in allen beteiligten Systemen umgesetzt und produktiv geschaltet wird. Hier helfen scaled agile Methoden wie Less, Nexus oder SAFE.

Nach der Studie „Status Quo (scaled) agile 2019/20” nutzt die Mehrheit der Anwender agiler Ansätze diese selektiv oder in einer Mischform. In diesen Fällen arbeiten agile Teams mit anderen agilen Teams sowie mit solchen zusammen, die einer klassischen oder hybriden Vorgehensweise folgen. Wartung und Weiterentwicklung sind manchmal in DevOps Teams vereint, oft auch separaten Teams in der Linie und in Projekten zugeordnet.

In der Praxis treffen Iterationen der agilen Teams, üblicherweise im zwei bis vier Wochen-Takt, auf den klassischen Release-Zyklus mit oftmals zwei bis vier Releases pro Jahr. Für agile Teams sollten Tests ein Bestandteil der Entwicklungsaufgaben sein und sollte am Ende jeder Iteration ein potenziell auslieferbares Produktinkrement stehen. Während agile Teams mit jeder Iteration die Inhalte testen und produktiv setzen wollen, haben Nachbarteams andere Prioritäten. In manchen Fällen stehen auch integrative Testumgebungen nicht durchgängig zur Verfügung.

Komponentenintegrationstest

Die erste Stufe der Integrationstests sind die Komponenten-Integrationstests. Diese finden i.d.R. mit wenigen beteiligten Teams und in der eigenen technischen Umgebung statt. Genau wie Modultests lassen sich Komponenten-Integrationstests gut automatisieren und in die CI/CD Abläufe einbinden. In dieser Phase werden meistens synthetische Testdaten genutzt, die während der Testausführung erzeugt bzw. zurückgesetzt werden. Stehen Schnittstellen in der Testumgebung nicht zur Verfügung, lassen sie sich oft simulieren.

Systemintegrationstest

Der nächste Schritt in der Testkette sind die Systemintegrationstests. In der Praxis haben sich End-to-End-Prozesstests mit einem starken Fokus auf die Schnittstellen bewährt. Hiermit werden unerwartete Nebenwirkungen und Folgefehler aufgrund von Änderungen in den beteiligten Systemen schnell erkannt.

Weil das Ziel ist, den Prozessablauf zu testen und zum nächsten Schritt zu kommen, liegt der Schwerpunkt auf den Positivfällen. Werden im Prozessablauf Fehlersituationen überprüft, müssen diese im nächsten Schritt korrigiert werden, was Umfang und Komplexität der Tests in die Höhe treibt. Ein gutes Praxisbeispiel waren Tests bei einem Versicherungsunternehmen, bei welchem jede Nacht ca. 70 Anträge aus dem Außendienstsystem an das Bestandssystem gingen und dort policiert wurden. Im nächsten Schritt wurde die Testkette auch zum Output-Management, In-/Exkasso und Provisionssystem erweitert.

Ein großer Vorteil automatisierter Testabläufe ist, dass für die Testdurchführung keine Beteiligung der Nachbarteams benötigt wird. Stehen automatisierte Tests zur Verfügung, lässt sich das Nachbarsystem als Black Box überprüfen.

Diese Tests können sowohl mit synthetischen als auch mit produktionsnahen Testdaten umgesetzt werden. Bei synthetischen Testdaten können Tester viele Ausnahmefälle wie unplausible Eingaben, leere Attribute, Nullwerte, besonders kleine oder große Werte, negative und positive Werte, Sonderzeichen etc. prüfen. Anonymisierte, produktionsnahe Daten haben oft eine natürliche Varianz, die zu einer guten Testabdeckung beiträgt.

Wenn Schnittstellen im Test nicht zur Verfügung stehen, lässt sich zumindest die Einhaltung der Spezifikation überprüfen. So können auch geplante, zukünftige Änderungen der Schnittstellen bereits frühzeitig getestet und zum Zeitpunkt der Produktivsetzung gemeinsam mit dem Nachbarteam übernommen werden.

Anforderungen an Tool-Unterstützung

Für zuverlässige, automatisierte Tests werden passende Tools benötigt. In der Praxis können folgende Funktionalitäten von Bedeutung sein:

• Alle beteiligten Anwendungen und Technologien werden unterstützt, damit Prozessketten durchgängig getestet werden können. Tools, die an einer bestimmten technischen Umgebung gebunden sind (z.B. Weboberflächen oder SAP) sind dafür nur selten geeignet.
• Die Tools erlauben auch die Prüfung von Datenbankinhalten, Exportformate (z.B. XML / Edifact) und Dokumente (z.B. pdf) für möglichst vollständige Tests der Prozesskette.
• Das Tool erlaubt eine unbewachte Ausführung, z.B. für nächtliche Testläufe oder für eine Testdurchführung parallel zur Erstellung neuer Testläufe.
• Die Testskripte können resilient gestaltet werden, damit beispielsweise Wartezeiten, Systemhinweise und Fokusverlust den Testablauf nicht behindern. Im Fehlerfall wird der Testfall definiert beendet und der nächste Testfall gestartet.
• Die Protokolle enthalten ausreichend viele Details, damit die Testergebnisse nachträglich nachvollziehbar sind.
• Die Trennung der funktionalen Abläufe (in Form von Testskripten / Testroutinen) und Testdaten: Die Trennung ermöglicht die Durchführung der Tests mit einer weiten Varianz in den Testdaten und trägt zu einer guten Testabdeckung bei.
• Prüfen Sie, ob die Tools, die Sie aktuell im Einsatz haben, diese Anforderungen erfüllen. Falls nicht, lohnt sich ein Blick auf unser Testframework mateo.

Das Fazit ist, dass automatisierte Integrations- und Systemtests genau wie automatisierte Modultests eine wesentliche Voraussetzung für eine gute Reaktionsfähigkeit in der Entwicklung sowie für kurze Release-Zyklen sind. Im Artikel haben wir gezeigt, wie Sie sinnvolle erste Schritte machen und damit bereits einen konkreten Nutzen erreichen können.

In seinem Blogbeitrag “Warum agile Software-Entwicklung Testautomatisierung braucht” hat mein Kollege Simon Damrau beschrieben, wie sich Testautomatisierung in agilen Projekten sinnvoll umsetzen und in die Deployment-Pipeline einbinden lässt.