Eine Person schickt ein Formular ab, sieht anschließend eine Fehlermeldung und weiß nicht, ob ihre Eingabe angekommen ist. Noch einmal absenden kann einen doppelten Vorgang erzeugen. Für die Fehleranalyse muss deshalb der ganze Ablauf betrachtet werden: Eingabe, Speicherung, Weitergabe und Rückmeldung an den Benutzer.
Das folgende fiktive Beispiel zeigt, wie Fachseite und Entwicklung einen solchen Fehler gemeinsam eingrenzen können. Es beschreibt keinen bestimmten Kundenfall und keine pauschale Fehlerursache.
Ein Klick kann mehrere Schritte auslösen
Ein Serviceportal soll einen Reparaturauftrag annehmen. Nach dem Absenden speichert es die Anfrage, übergibt sie an ein nachgelagertes System und zeigt eine Bestätigung. Zusätzlich kann eine Benachrichtigung entstehen. Schlägt nur einer dieser Schritte fehl, sind unterschiedliche Ergebnisse möglich: Die Anfrage wurde gar nicht gespeichert, sie liegt nur im Portal, oder sie ist bereits im Zielsystem angekommen, während die Bestätigung scheitert.
Die sichtbare Fehlermeldung allein unterscheidet diese Fälle nicht. Auch eine versandte Benachrichtigung beweist noch nicht, dass der Vorgang im zuständigen Zielsystem vollständig vorliegt.
Vier Fragen für die gemeinsame Prüfung
- Was hat die Person genau getan? Halten Sie Umgebung, Uhrzeit, letzten Bedienungsschritt und Wortlaut der Meldung fest. Für die technische Nachstellung verwenden Sie freigegebene Testdaten.
- Wo ist der Vorgang tatsächlich vorhanden? Eine berechtigte Person prüft Portal und Zielsystem getrennt. Verwenden Sie eine gemeinsame Vorgangskennung, damit ähnliche Einträge nicht verwechselt werden.
- Welcher Übergang scheitert? Ordnen Sie die verfügbaren Protokolle der Vorgangskennung zu. Unterscheiden Sie einen fehlgeschlagenen Übergabeversuch von einer verzögerten Verarbeitung und einer fehlgeschlagenen Bestätigungsanzeige.
- Was passiert beim erneuten Versuch? Prüfen Sie in einer isolierten Testumgebung, ob derselbe Vorgang erkannt oder doppelt angelegt wird. Wiederholen Sie einen unbekannten Produktionsvorgang nicht nur zur Fehlersuche.
Aus der Fehlermeldung einen prüfbaren Abnahmeschritt machen
Für das Serviceportal genügt „Das Formular geht wieder“ als Abnahme nicht. Vereinbaren Sie konkrete Sollresultate:
- Normalfall: Ein Testauftrag wird einmal gespeichert, genau einmal im Zielsystem verarbeitet und mit einer passenden Bestätigung angezeigt.
- Zielsystem vorübergehend nicht erreichbar: Der tatsächliche Bearbeitungsstand bleibt nachvollziehbar. Die Anzeige behauptet keine erfolgreiche Übergabe, die noch nicht stattgefunden hat.
- Bestätigung unterbrochen: Support und berechtigte Benutzer können den Status des bereits vorhandenen Vorgangs klären.
- Erneutes Absenden: Das vereinbarte Verhalten für denselben Vorgang wird eingehalten und erzeugt keine unbeabsichtigte Doppelverarbeitung.
Ob dafür eine direkte Schnittstelle, eine Warteschlange oder eine andere Lösung passt, hängt vom vorhandenen System ab. Unser Beispiel zu REST-Aufruf und Warteschlange erklärt diese Entscheidung an einem Shop-ERP-Ablauf.
Was vor einer Änderung feststehen sollte
Benennen Sie einen fachlichen Verantwortlichen, die beteiligten Systeme und eine nutzbare Testumgebung. Halten Sie fest, wer den Status prüfen und eine erneute Verarbeitung auslösen darf. So wird aus „Beim Absenden kommt ein Fehler“ ein abgegrenzter Auftrag mit prüfbarem Ergebnis, ohne vorschnell einen weiteren Dialog oder eine neue Integration zu bauen.