Akzeptanztests für einen Geschäftsprozess entwerfen, bevor Sie ihn automatisieren

Die Automatisierung eines unzureichend definierten Geschäftsprozesses überträgt dessen Mehrdeutigkeiten oft auf die Software. Mit einem Akzeptanztest lässt sich gemeinsam mit den Prozessverantwortlichen prüfen, ob das vorgeschlagene Verhalten die betrieblichen Regeln widerspiegelt, bevor man sich in der Produktion darauf verlässt. Er ersetzt weder die Anforderungsdefinition noch technische Tests, sondern verbindet vereinbarte Regeln mit beobachtbaren Ergebnissen.

Was ein geschäftlicher Akzeptanztest validiert

Ein Akzeptanztest prüft, ob eine Lösung oder ein Prozess in einer konkreten Situation das vom Unternehmen benötigte Ergebnis liefert. Zum Beispiel, ob ein Antrag, der bestimmte Kriterien erfüllt, in den richtigen Status wechselt, den erforderlichen Datensatz erzeugt und eine Aufgabe der zuständigen Person zuweist.

Er unterscheidet sich von verwandten Aktivitäten:

• Informelle Prozessprüfung: Ein Gespräch oder ein gemeinsamer Durchlauf kann Probleme aufdecken, hält aber nicht immer überprüfbare Bedingungen und Ergebnisse fest.
• Technischer Test: Er prüft Aspekte wie eine API-Antwort, eine Funktion, eine Integration oder die Fehlerbehandlung. Er kann erfolgreich sein, obwohl die implementierte Geschäftsregel falsch ist.
• Akzeptanztest: Er validiert das Verhalten aus Sicht der vereinbarten betrieblichen Regeln anhand von Szenarien und Kriterien, die die Verantwortlichen bewerten können.

Ziel ist weder, jede Anforderung lediglich anders zu formulieren, noch die gesamte Teststrategie für den Code festzulegen. Vielmehr soll eine überschaubare Menge von Situationen vereinbart werden, die eine Frage beantwortet: Würden die Benutzerinnen und Benutzer dieses Verhalten für den Prozess als gültig akzeptieren?

Szenarien auswählen, die die tatsächliche Arbeit abbilden

Beginnen Sie damit, den Hauptablauf zu skizzieren: Was löst den Prozess aus, welche Entscheidungen werden getroffen, wer ist beteiligt und wie endet der Prozess? Identifizieren Sie anschließend Ausnahmen, die eine Entscheidung ändern oder einen Eingriff erfordern können. Es ist nicht nötig, jede mögliche Kombination aufzulisten. Abgedeckt werden sollten jedoch die Varianten, die sich auf das Ergebnis, das Risiko oder den betrieblichen Aufwand auswirken.

Eine sinnvolle erste Szenarienauswahl umfasst in der Regel:

• Regulärer Ablauf: Eine gültige Eingabe durchläuft die häufigsten Regeln bis zum Abschluss des Prozesses.
• Relevante Ausnahme: Fehlende Informationen, ein nicht erfülltes Kriterium oder ein erforderlicher Prüfschritt verändert den Ablauf.
• Entscheidungsgrenzwert: Ein Wert genau am Schwellenwert und, sofern sinnvoll, je ein weiterer unmittelbar darunter und darüber. So wird geklärt, ob eine Bedingung den Grenzwert einschließt, und unterschiedliche Auslegungen werden vermieden.
• Wiederholung oder Duplikat: Eine wiederholte Eingabe, eine erneut ausgeführte Aktion oder eine verspätete Antwort, sofern der Prozess solchen Situationen ausgesetzt sein kann.
• Menschlicher Eingriff: Ein Fall, der angehalten, eskaliert oder einer Person zugewiesen werden muss, statt automatisch gelöst zu werden.

Priorisieren Sie Szenarien nach den Folgen eines Fehlers, der betrieblichen Häufigkeit und der Schwierigkeit, einen Fehler zu erkennen. Wenn zwei Fälle dieselbe Regel prüfen und zum selben Ergebnis führen, reicht wahrscheinlich einer aus. Ändert eine Ausnahme jedoch, wer entscheidet oder welche Verpflichtung eingegangen wird, sollte sie separat betrachtet werden.

Eingaben und reproduzierbaren Ausgangszustand vorbereiten

Für jedes Szenario muss beschrieben sein, welche Informationen vor Beginn des Tests vorliegen. Berücksichtigen Sie die für die Regeln relevanten Felder, den vorherigen Status des Vorgangs und gegebenenfalls Berechtigungen oder offene Aufgaben. Die Anweisung „einen unvollständigen Antrag testen“ reicht nicht aus, wenn sie nicht angibt, welche Angabe fehlt und welche anderen Angaben vorhanden sind.

Verwenden Sie nach Möglichkeit synthetische oder anonymisierte Daten, sofern sich das Verhalten damit bewerten lässt. Kopieren Sie nicht aus Bequemlichkeit echte personenbezogene Daten: Das verringert nicht nur die Offenlegung, sondern kontrollierte Daten ermöglichen es auch, den Fall zu wiederholen, ohne von Änderungen in betrieblichen Datensätzen abhängig zu sein. Ist eine externe Integration beteiligt, dokumentieren Sie, welche Antwort erwartet wird und wie sie während der Validierung simuliert oder kontrolliert wird.

Halten Sie außerdem die Vorbedingungen fest, etwa ob der Fall mit einem neuen oder bereits geprüften Vorgang beginnt. Ohne einen gemeinsamen Ausgangszustand kann eine Abweichung auf den vorherigen Test, zurückgebliebene Daten oder die geprüfte Regel zurückzuführen sein.

Beobachtbare Ergebnisse statt Absichten festlegen

Beschreiben Sie für jedes Szenario das erwartete Ergebnis anhand überprüfbarer Signale. „Der Prozess funktioniert korrekt“ lässt sich nicht überprüfen. Geben Sie stattdessen an, was sich ändert und was unverändert bleiben muss.

• Status: Endstatus des Falls sowie Statusübergänge, die stattfinden oder ausbleiben müssen.
• Daten: Datensätze, Felder oder Kennungen, die angelegt oder aktualisiert werden, sowie relevante Werte.
• Kommunikation: Benachrichtigungen, die versendet werden, ihre Empfänger und die Bedingungen für den Versand.
• Ausstehende Aufgaben: Eine Aufgabe, die verantwortliche Person, eine Frist oder ein festgehaltener Eskalationsgrund.
• Unzulässige Aktionen: Zum Beispiel darf ein prüfpflichtiger Fall nicht geschlossen und bei einem erneuten Versuch kein Datensatz dupliziert werden.

Das beobachtbare Ergebnis sollte von einer internen Implementierungsentscheidung getrennt werden. Die Abnahme sollte nicht davon abhängen, ob das System eine Warteschlange, eine Tabelle oder einen bestimmten Dienst verwendet, es sei denn, diese Wahl ist Teil einer vereinbarten Einschränkung. So bleibt das Kriterium auch bei einer Änderung der Architektur gültig.

Abweichungen bearbeiten, ohne offene Regeln zu verschleiern

Stimmt das beobachtete Ergebnis nicht mit dem erwarteten überein, dokumentieren Sie den Fall, die Eingaben, den Ausgangszustand sowie das tatsächliche und das erwartete Verhalten. Ergänzen Sie, wer die Regel bestätigt hat und welche Entscheidung noch aussteht. Eine Abweichung ist nicht immer ein technischer Fehler: Sie kann darauf hinweisen, dass die Regel mehrdeutig oder das Akzeptanzkriterium unvollständig war oder dass das System die Vereinbarung nicht umsetzt.

Klassifizieren Sie den Befund, bevor Sie über eine Korrektur entscheiden:

• Mehrdeutige oder widersprüchliche Regel: Die Abnahme dieses Falls aussetzen, bis die verantwortliche Person das gültige Verhalten festgelegt hat.
• Verhalten weicht von einer vereinbarten Regel ab: Einen Fehler mit seinen Auswirkungen und den Bedingungen für einen erneuten Test dokumentieren.
• Erwartetes Ergebnis veraltet: Die Änderung prüfen und genehmigen lassen; das Kriterium nicht nur ändern, damit der Test erfolgreich ist.
• Daten- oder Umgebungsproblem: Die Testvorbereitung korrigieren und den Test wiederholen. Dabei festhalten, warum der vorherige Versuch keine eindeutige Aussage zuließ.

Weisen Sie den Abweichungen Verantwortliche und Status zu. Eine Liste von Beobachtungen ohne Entscheidung oder Nachverfolgung wird zu einer Quelle für Meinungsverschiedenheiten statt zu einem Abnahmenachweis.

Szenarien nach Änderungen wiederholen und über die Automatisierung entscheiden

Abgenommene Szenarien können bei Änderungen an Regeln, Formularen, Integrationen oder betrieblichen Abläufen wiederverwendet werden. Wiederholen Sie die betroffenen Fälle sowie Hauptabläufe, die von Nebenwirkungen betroffen sein könnten. Automatisierte Softwaretests können technische Prüfungen schnell ausführen; bei der Geschäftsvalidierung muss weiterhin bestätigt werden, dass die Ergebnisse für den Betrieb sinnvoll sind, insbesondere wenn sich Richtlinien oder Verantwortlichkeiten ändern.

Prüfen Sie vor der Automatisierung, ob jedes Szenario reproduzierbare Eingaben und ein überprüfbares Ergebnis hat und ob eine entscheidungsbefugte Person für Rückfragen zur Verfügung steht. Gelten je nach Team, Kanal oder Falltyp unterschiedliche Regeln, müssen diese Abgrenzungen ausdrücklich festgehalten werden. Bewahren Sie Versionen oder Verweise auf die geltenden Regeln auf, damit nachvollziehbar ist, welches Verhalten wann abgenommen wurde.

Checkliste vor der Automatisierung

• Sind Beginn und Ende des Prozesses sowie die Verantwortlichen für jede Entscheidung festgelegt?
• Sind der reguläre Ablauf, folgenreiche Ausnahmen und die Grenzwerte der Regeln abgedeckt?
• Enthält jeder Fall Angaben zu Eingaben, Ausgangszustand und sicheren, wiederverwendbaren Testdaten?
• Sind die erwarteten Ergebnisse als beobachtbare Änderungen an Status, Daten, Benachrichtigungen oder Aufgaben beschrieben?
• Ist klar, wie bei einer Abweichung vorzugehen ist und wer eine Regel genehmigen kann?
• Wird zwischen einem Implementierungsfehler, einer noch offenen Regel und einem Problem bei der Testvorbereitung unterschieden?
• Gibt es Kriterien dafür, die Validierung bei Änderungen am Prozess zu wiederholen?

Wenn mehrere Antworten „Nein“ lauten, muss der Prozess vor der Automatisierung noch definiert werden. Lauten sie „Ja“, bieten Akzeptanztests für Geschäftsprozesse eine gemeinsame Grundlage, um das Verhalten zu validieren, ohne die betriebliche Abnahme mit der technischen Testabdeckung zu verwechseln. Das Ergebnis ist eine überprüfbare Vereinbarung darüber, was geschehen muss – auch wenn ein Fall vom regulären Ablauf abweicht.