Warum Integrationstests darüber entscheiden, was nach dem Go-live ausfällt
Eine Integration ist eine Verbindung, die Datensätze zwischen zwei Systemen überträgt, die nie dafür konzipiert waren, miteinander zu kommunizieren. Eine Bestellung in einem Adobe Commerce-Shop muss in SAP als etwas ankommen, das die Finanzabteilung fakturieren kann. Ein Lagerbestand in SAP muss den Shop erreichen, bevor ein Kunde etwas kauft, das nicht mehr vorrätig ist.
Integrationstests prüfen, ob dieser Austausch funktioniert, bevor er echte Bestellungen verarbeitet. Es sieht aus wie gewöhnliches Software-Testen mit mehr beweglichen Teilen, aber die meisten dieser Teile gehören jemand anderem.
Wenn ein Team diesen Schritt überspringt, bemerkt es die IT-Abteilung nicht als Erste. Das Lager, der Service-Desk und die Finanzabteilung am Monatsende bemerken es:
- Eine Bestellung, die der Ablauf noch nie gesehen hat: Eine Gutschrift oder Teillieferung erreicht SAP in einer Form, die das Mapping nicht erwartet. Der Ablauf stoppt, und der Kunde wird nicht fakturiert, bis es jemand bemerkt.
- Ein Bestandsabgleich, der unbemerkt fehlschlägt: Der Shop zeigt zwanzig Minuten lang die Verfügbarkeit von gestern an, und die Kommissionierer suchen nach Artikeln, die bereits verkauft sind.
- Ein Marktplatz, der ein Feld geändert hat: Amazon verlangt plötzlich ein Attribut, das die Produktdaten nie gesendet haben, lehnt die Angebote ab, und die Produkte verschwinden aus dem Kanal.
- Eine Lastspitze, für die niemand dimensioniert hat: Ein Ablauf, der auf zehn Bestellungen pro Stunde getestet wurde, trifft am ersten großen Verkaufstag auf viertausend und überschreitet das Zeitlimit, während die Bestellungen in einer Warteschlange landen, die niemand überwacht.
Nichts davon ist exotisch. Jeder dieser Fälle hätte im Voraus getestet werden können. Die meisten Teams versuchen es nicht, weil die Hälfte der beteiligten Systeme ihnen nicht gehört und sie dort nicht experimentieren können.
Warum Integrationen nicht wie gewöhnliche Software getestet werden können
Die Sandbox des Lieferanten existiert möglicherweise gar nicht. Falls doch, enthält sie unter Umständen drei Jahre alte Daten, die mit dem aktuellen Betrieb nichts mehr zu tun haben. Sandbox-Tests in einer Umgebung, die sich von der Live-Umgebung unterscheidet, sind weniger aussagekräftig, als es den Anschein hat.
Integrationen verändern bei ihrer Ausführung auch die Gegebenheiten. Der erste Test erstellt eine Bestellung, verwendet eine fortlaufende Nummer oder bewegt Lagerbestände, sodass derselbe Test nicht einfach erneut ausgeführt werden kann. Eine Wiederholung erfordert entweder das Zurücksetzen der Systeme, was meist unmöglich ist, oder die Generierung neuer Daten bei jedem Durchlauf. Die Bedingungen, die am wichtigsten zu testen wären, sind zudem oft die, die niemand gewährt. Ein Lieferant wird sein System nicht offline nehmen, nur damit das Team die Fehlerbehandlung testen kann. Ein Transportdienstleister wird eine API nicht auf Anfrage drosseln. Solche Pfade werden daher simuliert oder ganz übersprungen.
Eine Bedingung lässt sich überhaupt nicht testen. Ein Lieferant kann ein Feld ändern, ohne jemanden zu informieren – und diese Änderung ist zum Zeitpunkt der Erstellung des Testplans noch gar nicht eingetreten. Um dies abzufangen, benötigt das Team Monitoring und Logging. Tests validieren einen Prozess vor dem Go-Live. Monitoring zeigt dem Team, wie sich der Live-Traffic danach darauf auswirkt. Alles dazwischen hängt von einer einzigen Frage ab: War die Testumgebung nah genug an der Produktionsumgebung, um ihr vertrauen zu können?
Warum die Testumgebung der Flaschenhals bei Integrationstests ist
Der größte Aufwand bei Systemintegrationstests entfällt auf die Umgebung, nicht auf die Tests selbst. Wenn jede Verbindung aus benutzerdefiniertem Code besteht, bedeutet eine Testumgebung, eine zweite Kopie dieses Codes auszuführen, die auf die verfügbaren Lieferanten-Sandboxes verweist und synchron zur Produktion gehalten werden muss, während sich beide Seiten ständig ändern.
Dieser Wartungsaufwand führt dazu, dass Testumgebungen driften. Die getestete Version stimmt nicht mehr mit der laufenden Version überein, und die Tests verlieren ihre Aussagekraft.
Die Konfiguration der Abläufe auf einer gemeinsamen Integrationsschicht löst dieses Problem. Dieselbe Ablaufdefinition läuft in beiden Umgebungen. Sie verweist in der einen auf Test-Endpunkte und in der anderen auf Live-Endpunkte; nur die Konfiguration unterscheidet sich. Die Lieferanten-Sandboxes werden dadurch zwar nicht besser, aber das Team stellt nicht mehr etwas anderes bereit, als das, was es getestet hat.
Teams gehen heute auf drei Arten damit um. Sie bauen eine vollständige parallele Umgebung auf, was gründlich, aber teuer in der Pflege ist. Sie testen in der Produktion mit sorgfältig ausgewählten Datensätzen, was so lange funktioniert, bis sich herausstellt, dass ein ausgewählter Datensatz doch kritisch ist. Oder sie simulieren jedes externe System, was schnell geht, aber nur das testet, was das Team vom Lieferanten erwartet. Eine Integration Platform-as-a-Service (iPaaS) ist die vierte Option – und die einzige, die das Umgebungsproblem beseitigt, anstatt es nur zu umgehen.
Wie eine Integrationsplattform Integrationstests unterstützt
Eine iPaaS ist eine zentrale Plattform, mit der sich jedes System einmal verbindet, anstatt direkt miteinander zu kommunizieren. Sie enthält die Abläufe, die Daten zwischen den Systemen bewegen und transformieren. Da jeder Ablauf an einem zentralen Ort liegt, kann ein Team ihn auf Test- oder Live-Endpunkte ausrichten, ohne etwas neu programmieren zu müssen.
Das ermöglicht auf der Alumio-Integrationsplattform vier Dinge:
- Ein Ablauf, zwei Umgebungen: derselbe konfigurierte Ablauf läuft gegen Test-Endpunkte in einer Testumgebung und gegen Live-Endpunkte in der Produktion, sodass das Team genau das bereitstellt, was es geprüft hat
- Detailtiefe auf Nachrichtenebene: die Alumio iPaaS protokolliert, was jede Nachricht enthielt und wo sie gestoppt wurde, sodass das Team den tatsächlichen Fehler beheben kann, anstatt zu raten
- Wiederholung (Replay): Die Speicherung innerhalb der Alumio iPaaS bewahrt diese Nachrichten auf, sodass ein korrigierter Ablauf erneut mit der Bestellung ausgeführt werden kann, die den Fehler verursacht hat
- Kontrollierte Bereitstellung: Versionskontrolle und gestaffelte Bereitstellung sorgen dafür, dass Änderungen gezielt in die Produktion übernommen werden, anstatt das laufende System direkt zu bearbeiten.
Die Alumio iPaaS bietet zudem ein Inspektionstool. Es stellt die Ein- und Ausgabedaten jedes Transformationsschritts direkt gegenüber, sodass ein Team einzelne Teile eines Ablaufs testen kann, ohne die gesamte Integration ausführen zu müssen. Diese Funktionen arbeiten bei jedem Ablauf identisch, wodurch der Testansatz der ersten Integration nahtlos auf die zweite übertragen werden kann.
Was ehrliche Integrationstests einem Unternehmen bringen
Vollständige Abdeckung ist nicht erreichbar; ein Testplan, der dies vorgaukelt, ist entweder unehrlich oder wird nie fertig. Das sinnvolle Ziel ist eine klare Liste: Welche Pfade wurden vom Team gründlich geprüft, welche nur simuliert und welche konnten überhaupt nicht erreicht werden? Ein Team, das seine ungetesteten Pfade kennt, kann diese gezielt überwachen und bei Problemen schnell reagieren – das ist weitaus besser, als sich in der falschen Sicherheit zu wiegen, alles sei getestet.
Eine Integrationsplattform macht es möglich, diese Liste zu führen. Sie speichert den zu testenden und den bereitzustellenden Ablauf am selben Ort, protokolliert die Verarbeitung jeder Nachricht und ermöglicht es, Korrekturen anhand der tatsächlich fehlerhaften Bestellung zu überprüfen.
Das Unternehmen profitiert von Go-Lives mit weniger Überraschungen, Fehlern, die anhand von Protokollen statt durch nachträgliche Rekonstruktion erklärt werden, und der Sicherheit, vernetzte Systeme ändern zu können, ohne dies als Projektrisiko einstufen zu müssen.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
