SIT-Testing, kurz für System Integration Testing oder Systemintegrationstest, prüft, ob Ihre Software mit den anderen Systemen, von denen sie abhängt, korrekt zusammenarbeitet, etwa mit einem Zahlungsanbieter, einer Bank oder der Datenbank eines Partners. In der üblichen Reihenfolge folgt diese Teststufe, nachdem Ihr eigenes Produkt den Systemtest bestanden hat, und kommt vor dem Abnahmetest, in dem Fachanwender das gesamte Zusammenspiel ausprobieren.
Auf SIT zu verzichten ist riskant, wenn verschiedene Unternehmen die Bausteine entwickeln und betreiben, auf die Ihr Produkt angewiesen ist. Jedes Team kann seine eigenen Prüfungen bestehen, während die Verbindung zwischen zwei Systemen trotzdem versagt. Dieser Fehler zeigt sich oft zuerst bei den Kunden. Um das zu vermeiden, legen Sie früh fest, wer diese Verbindungen testet, in welcher Umgebung und mit wessen Daten.
Weil diese Prüfungen davon abhängen, dass mehrere Systemverantwortliche zusammenarbeiten, übernimmt die Aufgabe oft ein engagiertes QA-Team, das die Tests mit jedem beteiligten Anbieter koordinieren kann. In diesem Beitrag erklären unsere erfahrenen QA-Ingenieure, was Systemintegrationstests abdecken, wie sich die Methode von Integrationstests und dem User Acceptance Testing (UAT) unterscheidet und bei welchen Projekten sich dieser zusätzliche Schritt auszahlt.
Was prüft SIT-Testing eigentlich?
SIT-Testing betrachtet, wie Ihr Produkt mit externen Diensten verbunden ist. Das International Software Testing Qualifications Board (ISTQB), die internationale Organisation, die Softwaretester zertifiziert, definiert Systemintegrationstests als Prüfung „der Schnittstellen des Testobjekts zu anderen Systemen und externen Diensten“. Einfach gesagt ist eine Schnittstelle die Stelle, an der zwei Programme einander Daten übergeben.
Nehmen Sie einen Onlineshop, der jede Bestellung an einen Zahlungsanbieter, eine Lagerdatenbank und einen E-Mail-Dienst weitergibt. Jeder dieser Dienste kann für sich allein einwandfrei funktionieren. SIT fragt, ob die Bestellung nach jeder Übergabe noch vollständig und korrekt ankommt.
In der Praxis suchen Tester nach vier Arten von Problemen:
- Nicht passende Daten: Ein Dienst sendet ein Datum, einen Preis oder eine Adresse in einem Format, das die Gegenseite anders liest.
- Fehlgeschlagene Übergaben: Eine Nachricht geht verloren, kommt doppelt an oder trifft zu spät ein, um noch nützlich zu sein.
- Nicht behandelte Ausfälle: Wenn der Dienst eines Partners offline geht, friert Ihr Produkt ein, ohne dem Nutzer zu sagen, was passiert ist.
- Abgelehnter Zugriff: Das Sicherheitstoken Ihres Produkts, ein temporärer digitaler Schlüssel, der nachweist, wer Daten anfragt, funktioniert in Ihrem eigenen System, wird aber vom Dienst auf der anderen Seite abgewiesen.
Viele dieser Fehler gehen auf einige wiederkehrende Muster bei Integrationsfehlern zurück, etwa automatische Benachrichtigungen, die nie ankommen, oder Antworten, die Erfolg melden und dabei einen Fehler verbergen.
SIT vs. Integrationstest vs. UAT: Wo jede Stufe hingehört
SIT, Integrationstests und UAT werden oft verwechselt, weil es bei allen dreien um Software geht, die zusammenarbeitet. Der Unterschied liegt im Umfang und in der Frage, die jede Stufe beantwortet. Der aktuelle ISTQB-Lehrplan teilt Integrationstests sogar in zwei Arten auf: den Komponentenintegrationstest für Bausteine innerhalb eines Produkts und den Systemintegrationstest für Verbindungen zwischen Produkten.
Ein Integrationstest bedeutet in der Regel, zwei Bausteine zu prüfen, die Ihre eigenen Entwickler gebaut haben, etwa ein Registrierungsformular und die Datenbank, in der neue Konten gespeichert werden. SIT erweitert den Umfang auf Systeme, die anderen Teams oder Anbietern gehören, zum Beispiel einen Zahlungsanbieter oder den Kartendienst einer Bank. Beim Benutzerakzeptanztest erhalten Fachanwender das fertige, vernetzte Produkt und bestätigen etwa, dass ein Verkaufsauftrag wie erwartet durchläuft.
Die folgende Tabelle stellt SIT und UAT nebeneinander, zusammen mit den beiden vorgelagerten Stufen:
Kernfrage
Arbeiten die Bausteine unseres Produkts zusammen?
Funktioniert unser gesamtes Produkt wie spezifiziert?
Funktioniert unser Produkt mit den Systemen um es herum?
Erfüllt das vernetzte Produkt die geschäftlichen Anforderungen?
Umfang
Bausteine im Code eines Produkts
Ein vollständiges Produkt
Ihr Produkt plus externe Systeme und Dienste
Das gesamte Zusammenspiel in realen Geschäftsszenarien
Übliche Tester
Entwickler
Unabhängige Tester
Unabhängige Tester, gemeinsam mit jedem Systemverantwortlichen
Fachanwender oder Mitarbeiter des Kunden
Beispiel Banking-App
Das Kreditformular speichert Daten in der Datenbank der App
Jede Funktion der App wird gegen die Anforderungen geprüft
Die App tauscht Daten mit dem Kartenprozessor und der Auskunftei aus
Filialmitarbeiter bestätigen, dass der Kreditprozess zu ihrer Arbeitsweise passt
Wann braucht Ihr Projekt SIT-Testing?
Sie brauchen SIT-Testing, wenn Ihr Produkt von Systemen abhängt, die Sie nicht kontrollieren. Am höchsten ist das Risiko in großen Unternehmen, in denen Ihre App Daten mit Werkzeugen anderer Teams austauscht, etwa mit einer Kundendatenbank oder einem ERP-System (Enterprise Resource Planning), der Software für Finanzen, Lagerbestand und Lohnabrechnung. Bezahl- und Identitätsabläufe verlangen dieselbe Sorgfalt, weil Geld oder personenbezogene Daten durch einen Zahlungsanbieter, eine Bank oder einen Verifizierungsdienst laufen.
Auch ältere Software erhöht das Risiko, denn eine neue App muss oft mit einem System zusammenarbeiten, das niemand ändern möchte. Der neueste Fall ist ein KI-Assistent, der Ihren Kalender, Ihre Kundendaten oder Ihre Helpdesk-Tickets aktualisieren kann, denn er ist mit jeder dieser Anwendungen einzeln verbunden, und jede dieser Verbindungen kann ausfallen.
In der EU haben Banken, Versicherer und andere Finanzunternehmen zudem einen rechtlichen Grund, diese Verbindungen zu testen. Nach dem Digital Operational Resilience Act (DORA) müssen solche Unternehmen regelmäßig prüfen, wie ihre Systeme unter Belastung standhalten, und externe Technologieanbieter müssen unter Umständen daran teilnehmen.
Ein einfaches Produkt dagegen, das ein einzelnes Team baut und das nur wenige Drittanbieterdienste nutzt, braucht deutlich weniger von dieser Arbeit. In diesem Fall decken solide Integrations- und Systemtests das Risiko meist ab. End-to-End-Tests, die den realen Weg eines Nutzers durch die App von Anfang bis Ende nachverfolgen, fangen dann auf, was diese beiden Stufen übersehen.
Welchen Platz SIT-Testing in Ihrer Teststrategie hat
SIT findet meist gegen Ende der Testabfolge statt. Das ISTQB beschreibt fünf Teststufen, und die meisten Projekte durchlaufen sie ungefähr in dieser Reihenfolge:
- Komponententest: Entwickler prüfen jedes kleine Codestück für sich.
- Komponentenintegrationstest: Dasselbe Team bestätigt, dass diese Stücke zusammenarbeiten.
- Systemtest: Unabhängige Tester vergleichen das vollständige Produkt mit seinen Anforderungen.
- Systemintegrationstest: Das Testteam verifiziert die Verbindungen des Produkts zu externen Systemen.
- Abnahmetest: Fachanwender bestätigen, dass das Produkt ihre Anforderungen erfüllt.
In realen Projekten überschneiden sich die Stufen. Ein Team kann bereits eine fertige Verbindung prüfen, während andere Funktionen noch im Systemtest sind, wodurch Probleme bei Partnern früher sichtbar werden. Trotzdem spielt die Reihenfolge eine Rolle. Hat Ihr eigenes Produkt noch offene Fehler, kann eine fehlgeschlagene Verbindungsprüfung auf Ihren Code oder auf das System des Partners hindeuten, und niemand kann sagen, auf welches. Dieselbe Verwirrung kann auch von der anderen Seite ausgehen. Bei Granola, einem KI-Notizblock, ließ eine unzuverlässige Google-Anmeldung automatisierte Tests scheitern, obwohl die App funktionierte. Deshalb haben wir eine sichere interne Login-Hilfe gebaut, die diese Fehlalarme aus den Ergebnissen heraushielt.
Eingangs- und Ausgangskriterien: Wann SIT beginnen kann und wann es abgeschlossen ist
Eingangs- und Ausgangskriterien legen fest, was vorhanden sein muss, bevor das SIT-Testing beginnt, und was als abgeschlossen gilt. Wer sich vorab auf beide Listen einigt, erspart sich später Diskussionen zwischen den Anbietern.
Die Tests können beginnen, wenn:
- Die an jeder Verbindung beteiligten Teile Ihres Produkts den Systemtest ohne offene kritische Fehler bestanden haben.
- Jeder Partner eine Sandbox bereitgestellt hat, eine Testkopie, die sich wie der echte Dienst verhält.
- Auf allen Seiten passende Beispieldatensätze vorhanden sind, zum Beispiel derselbe Testkunde in Ihrer App und bei der Bank.
- Jeder Systemverantwortliche einen Ansprechpartner benannt hat, der Fehler auf seiner Seite untersuchen kann.
Die Arbeit ist abgeschlossen, wenn:
- Jede geplante Verbindung getestet wurde, einschließlich dessen, was passiert, wenn ein Partner offline geht.
- Keine kritischen oder hoch priorisierten Fehler mehr offen sind.
- Der Verantwortliche jedes Systems die Ergebnisse für seinen Teil freigegeben hat.
Welche vier Ansätze gibt es beim SIT-Testing?
Jedes SIT-Projekt muss entscheiden, in welcher Reihenfolge die Systeme eingebunden werden. Die Abfolge beeinflusst, wie schnell Probleme entdeckt werden und wie leicht sich jeder Fehler zurückverfolgen lässt. Vier Ansätze werden am häufigsten eingesetzt:
- Big Bang: Alles wird auf einmal verbunden und gemeinsam getestet. Für kleine Umgebungen ist das in Ordnung, doch mit jedem weiteren System wird die Ursache eines Fehlers schwerer zu finden.
- Top-down: Das Team beginnt mit der App, mit der Ihre Nutzer arbeiten, und fügt die dahinterliegenden Backoffice- und Partnerdienste nacheinander hinzu. Bis der nächste Baustein bereit ist, verwenden Tester Stubs, einfache Platzhalter, die vorgegebene Antworten zurücksenden.
- Bottom-up: Die Arbeit beginnt bei den zentralen Backend-Systemen, etwa der Zahlungsabwicklung und Ihrer Hauptdatenbank, und arbeitet sich zu dem vor, was Menschen sehen. Bis die kundenseitigen Apps angebunden sind, verwenden Tester Treiber, kleine Programme, die dieselben Anfragen senden, die später durch Nutzeraktionen ausgelöst werden.
- Sandwich: Teams testen gleichzeitig von oben und von unten und treffen sich in der Mitte, was zu großen Projekten passt, in denen viele Gruppen parallel arbeiten.
Bei einem Projekt mit mehreren Anbietern lohnt sich meist der Top-down-, Bottom-up- oder Sandwich-Ansatz, weil jede neue Verbindung einzeln geprüft wird und so jeder Fehler eine eindeutige Quelle hat. Die meisten Systeme tauschen Daten über Programmierschnittstellen aus, sogenannte APIs (Application Programming Interfaces). Eine API ist ein fester Satz von Anfragen, die ein Programm an ein anderes senden kann, ähnlich wie eine Speisekarte mit den Bestellungen, die eine Küche annimmt. Sobald die Verbindungen stabil sind, kann automatisiertes API-Testen die wichtigsten Szenarien nach jedem Release erneut ausführen.
Wie QAwerk SIT über Teams und Anbieter hinweg durchführt
QAwerk steigt in das SIT-Testing als Teil eines gemeinsamen Teams mit Ihren Entwicklern und Anbietern ein. Der erste Schritt ist eine Übersicht aller Verbindungen, die den Verantwortlichen jedes Systems und die Daten zeigt, die über jede Verbindung fließen. Danach vereinbaren wir mit jedem Anbieter den Sandbox-Zugang, Testkonten und die Beispieldaten, die wir verwenden dürfen. Anschließend decken unsere Ingenieure den normalen Ablauf und auch die Fehlerfälle ab, etwa einen Partner, der langsam antwortet, fehlerhafte Daten sendet oder offline geht. Jeder Fehler geht direkt an das Team, das ihn beheben kann, zusammen mit den Belegen, die zur Reproduktion des Problems nötig sind.
Die Details hängen von den beteiligten Systemen ab. Bei Thirdfort, einer regulierten App für Identitätsprüfungen, haben wir zum Beispiel die Ausweisprüfung auf Basis der Onfido- und ReadID-SDKs getestet, zusammen mit der Verknüpfung von Kontoauszügen, die die Herkunft der Mittel eines Kunden belegt. Onfido kam auch bei ChitChat vor, einer Messaging-App zum Versenden von Geld an Freunde, doch dort drehte sich die Arbeit darum, wie die App Daten mit diesem Dienst und mit Primer, ihrem Zahlungsanbieter, austauschte. Arctype erforderte dagegen eine andere Art von Integrationsarbeit. Für diese App, mit der Entwickler Datenbanken abfragen und verwalten, haben wir die Verbindungen zu fünf Datenbanksystemen getestet: MySQL, PostgreSQL, SQLite, Yugabyte und PlanetScale.
Wir können vor Ihrer ersten Partnerintegration oder mitten in einem Rollout einsteigen. Die Ingenieure von QAwerk bewerten den Projektstand, legen den Umfang fest und liefern sofort umsetzbare Ergebnisse. Bereit für Ihre Systemintegrationstests? Kontaktieren Sie uns noch heute.
Häufige Fragen
Was ist SIT-Testing?
SIT-Testing (Systemintegrationstest) ist die Teststufe, die ein Produkt zusammen mit den daran angeschlossenen externen Diensten prüft, etwa einem Zahlungs-Gateway, einem Versandpartner oder dem Buchhaltungsprogramm eines Unternehmens. Ziel ist es, Fehler zu finden, die nur auftreten, wenn getrennt entwickelte Systeme Informationen austauschen, zum Beispiel eine Bestellung, die die Lagersoftware ablehnt, oder eine Erstattung, die den Kunden nie erreicht.
Kommt SIT vor UAT?
Ja, der Systemintegrationstest (SIT) ist normalerweise abgeschlossen, bevor das User Acceptance Testing (UAT) beginnt, die letzte Prüfung, bei der Fachanwender entscheiden, ob die Software zu ihrer täglichen Arbeit passt. Diese Reihenfolge schont ihre Zeit. Wenn Käufe oder Zahlungen zwischen verbundenen Systemen noch scheitern, protokollieren die Abnahmetester am Ende technische Fehler und können den eigentlichen Arbeitsablauf nicht beurteilen. Eine kurze Überschneidung ist üblich, kritische Integrationsfehler sollten aber vorher behoben sein.
Was ist der Unterschied zwischen SIT und Systemtest?
Der Systemtest blickt nach innen und prüft, ob ein vollständiges Produkt seine Anforderungen erfüllt, oft mit simulierten Partnerdiensten. SIT blickt dagegen nach außen und ersetzt diese Simulationen durch echte Partnersysteme oder realistische Sandboxes. So kann etwa der Checkout eines Onlineshops den Systemtest mit einem simulierten Zahlungsdienst bestehen und dann im SIT scheitern, weil der echte Anbieter Beträge in Cent erwartet, der Shop sie aber in Euro sendet.
Wer führt Systemintegrationstests durch?
SIT-Testing wird meist von unabhängigen Testern geleitet, entweder vom eigenen QA-Team eines Unternehmens oder von einem externen QA-Dienstleister, weil die Arbeit Systeme umfasst, die keinem einzelnen Entwickler gehören. Jeder Partner oder jedes interne Team stellt einen Ansprechpartner, der Testzugänge gewährt und Fehler auf seiner Seite untersucht. Entwickler beheben die Fehler in ihrem Code, und Fachanwender kommen später für den Abnahmetest hinzu.
Lässt sich SIT automatisieren?
SIT-Testing lässt sich teilweise automatisieren. Stabile, wiederholbare Prüfungen, etwa eine Beispielzahlung an die Sandbox eines Anbieters zu senden und die Antwort zu verifizieren, können nach jedem Release automatisch laufen. Manuelle Tester bleiben unverzichtbar für neue Partnerverbindungen, ungewöhnliche Fehlerszenarien und Testumgebungen, die sich anders verhalten als der Live-Dienst. Eine übliche Aufteilung ist, die bewährten Kernabläufe zu automatisieren und alles Neue von Hand zu erkunden.
Erfahren Sie, wie wir stabiles Onboarding, Identitätsprüfungen und Source-of-Funds-Workflows für ein britisches Fintech-Unternehmen bereitgestellt haben, das auf tiefen Drittanbieter-Integrationen aufgebaut ist.
