Antwort.

Manuelles Testing von Integrationen ist der Prozess der Überprüfung der Interaktion zwischen verschiedenen Modulen, Diensten oder externen Systemen manuell, ohne automatisierte Skripte.

Geschichte der Frage:

In den Anfangstagen der IT-Produkte wurden alle Systeme monolithisch erstellt, aber mit dem Wachstum des Unternehmens und der Anzahl der externen Dienste wurden Integrationstests wichtig. Tester begannen sich zu fragen: Wie kann man sicherstellen, dass Daten und Aktionen korrekt zwischen den Systemen übertragen werden – beispielsweise dass eine erfolgreiche Zahlung sowohl in der Abrechnung als auch im Buchhaltungssystem reflektiert wird.

Problem:

Die größte Schwierigkeit ist das Fehlen einer voll funktionsfähigen Umgebung: Integrationen können von externen Diensten, instabilen APIs oder externen Einschränkungen abhängen. Darüber hinaus kann manuelles Testing an jedem Integrationstreifen sehr arbeitsintensiv sein, wodurch leicht ein Fehler in der Schrittfolge auftreten oder eine wichtige kaskadierende Folge übersehen werden kann.

Lösung:

Verwenden Sie Testumgebungen mit „Stubs“ (mock/stub), um die Wiederholbarkeit des Tests zu gewährleisten.
Strukturieren Sie Testfälle, dokumentieren Sie schrittweise Überprüfungen von Nachrichten, Logs, Status.
Überprüfen Sie zunächst Grenzfälle, Timeouts, Wiederholungsversuche von Integrationsaufrufen, die Reaktion des Systems auf Fehler.

Schlüsselfunktionen:

Notwendigkeit des Verständnisses der Geschäftslogik beider integrierter Seiten.
Berücksichtigung der Asynchronität und Fehler bei der Zustandsübertragung.
Unterstützung der Stabilität bei teilweisen Ausfällen.

Fragen mit einem Haken.

Was sind Test-Doubles und wofür werden sie beim manuellen Testing von Integrationen benötigt?

Test-Doubles sind Simulationen von Integrationskomponenten (z.B. mock, stub, fake). Beim manuellen Testing werden sie benötigt, um Szenarien zu durchlaufen, in denen das echte externe System nicht verfügbar ist oder deren Aufrufe kostenpflichtig sind.

Kann man eine Integration als getestet betrachten, wenn die Testfälle nur den Happy Path abgedeckt haben?

Nein. Es ist unbedingt erforderlich, auch Edge Cases zu testen: Verbindungsprobleme, falsche Datenformate, Timeouts, unerwartete Antworten.

Reicht es aus, nur den Versand/Empfang von Daten zu überprüfen, oder ist noch etwas anderes notwendig?

Es ist wichtig, die Korrektheit des INHALTS der Daten, deren Transformation und das Verhalten des Systems bei verschiedenen Fehlern an den Schnittstellen zu überprüfen.

Typische Fehler und Anti-Patterns

Nur mit dem "eigenen" Teil des Systems arbeiten, ohne das Verhalten auf der Partnerseite zu überprüfen.
Negative Szenarien ignorieren.
Logs nicht analysieren oder keine Historie von Integrationsfehlern sammeln.

Beispiel aus dem Leben

Negativer Fall

Ein Tester überprüft die Integration zwischen CRM und Abrechnungssystem nur auf die erfolgreiche Bestellung. Er überprüft nicht die Synchronisierungsfehler und versäumte Transaktionen.

Vorteile:

Schnelle Abdeckung der Hauptszenarien.

Nachteile:

Fehler bei einer Integrationsstörung wird erst mit echten Daten entdeckt.

Positiver Fall

Ein Tester erstellt einen Testsatz mit dem Unterbrechen und Wiederherstellen der Internetverbindung, mit der Verwendung ungültiger Token. Er validiert die Protokolle beider Seiten.