Antwort.

Manuelles Integrationstest ist ein wichtiger Schritt im Lebenszyklus von Software, der nach den Modultests durchgeführt wird. Sein Ziel ist es, sicherzustellen, dass einzelne Module oder Komponenten des Systems korrekt miteinander interagieren.

Hintergrund der Frage: Ursprünglich wurde Software schrittweise getestet: Zuerst wurden einzelne Module (Unit-Tests) überprüft, dann das gesamte System. In der Praxis stellte sich jedoch heraus, dass die meisten kritischen Fehler gerade an den Schnittstellen zwischen den Modulen auftraten. Es entstand der Bedarf an Integrationstests, die manuell Inkonsistenzen im Verhalten verschiedener Teile des Systems aufdecken.

Problem: Die Hauptschwierigkeit besteht in der unzureichenden Ausarbeitung von Interaktionsszenarien zwischen den Modulen und vergessenen Abhängigkeiten. Dies führt zu „unsichtbaren“ Bugs: Bei isoliertem Testen funktioniert alles korrekt, doch nach der Integration treten Fehler auf (z. B. falsche Datenverarbeitung zwischen API und DB).

Lösung: Eine korrekte Organisation des manuellen Integrationstests umfasst:

Analyse der Systemarchitektur und Erstellung einer Interaktionskarte der Komponenten.
Entwicklung von Integrationstestfällen basierend auf Benutzerszenarien und Grenzdaten.
Modellierung von teilweise Ausfällen (z. B. Ausfall eines Dienstes) und Bewertung der Reaktion des gesamten Systems.
Dokumentation der Ergebnisse und Feststellung der Abhängigkeiten zwischen den Bugs.

Wesentliche Merkmale:

Aktualisierung des Architekturschemas.
Berücksichtigung aller versteckten und offensichtlichen Abhängigkeiten zwischen den Teilen des Systems.
Besonderes Augenmerk auf die Szenarien der Datenübertragung und -verarbeitung an den Schnittstellen der Module.

Fangfragen.

Was ist der Unterschied zwischen manuellem Integrations- und Systemtest?

Der Integrationstest konzentriert sich auf das Testen von Verbindungen zwischen bestimmten Modulen, während der Systemtest das gesamte System aus Sicht seiner Geschäftslogik überprüft.

Sollte bei Integrationstests echte externe Dienste oder genügen Emulatoren verwendet werden?

Für kritische Integrationen ist eine reale Umgebung bevorzugt, aber man kann mit Emulatoren (Mock/Stub) beginnen. Die abschließenden Tests sollten in einer Umgebung stattfinden, die der PROD-Umgebung am nächsten kommt.

Kann man alle Integrationsfehler nur durch Automatisierung aufdecken?

Nein: Einige Defekte werden nur manuell entdeckt, wenn der Tester unauffällige Probleme in der Geschäftslogik des Datenaustauschs oder in den Benutzerszenarien, die nicht von der Automatisierung abgedeckt sind, bemerkt.

Typische Fehler und Anti-Pattern

Fehlender klarer Katalog der Integrationspunkte.
Durchführung von Tests ohne Isolation der Umgebung.
Unzureichende Detailgenauigkeit der Testfälle für die Integration.

Beispiel aus dem Leben

Negativer Fall

Das Testen der Integration zwischen dem Zahlungsmodul und dem Bestellmodul wurde nur nach Beendigung aller anderen Tests und ohne separate Dokumentation durchgeführt.

Vorteile:

Zeitersparnis bei der Vorbereitung von Testfällen.
Schneller Teststart ohne aufwendige Koordination.

Nachteile:

Auftreten ernsthafter Bugs in der Produktion, die mit doppelten Abbuchungen verbunden sind.
Verzögerungen beim Release zur Behebung der zuletzt gefundenen Fehler.

Positiver Fall

Die Integrationsszenarien wurden von Anfang an festgehalten, und die Testdaten wurden den realen Benutzeraufgaben so nahe wie möglich gebracht.