Kernaussage: Ein fachliches Akzeptanzkriterium beschreibt, was fachlich gelten muss. Ein technischer Testfall beschreibt zusätzlich, wie und in welcher Reihenfolge dieser Sachverhalt zuverlässig geprüft wird. Genau diese Trennung ist für eine saubere Business Analyse entscheidend.

In vielen Projekten werden Akzeptanzkriterien und technische Testfälle fast gleich behandelt. Beide können in Given-When-Then-Form geschrieben sein, beide können später automatisiert werden und beide beschreiben prüfbare Sachverhalte. Trotzdem erfüllen sie nicht dieselbe Aufgabe.

Gerade bei der Arbeit mit Jira, Cucumber und Playwright wird diese Unterscheidung wichtig: Die Business Analyse formuliert die fachliche Erwartung. Die technische Testautomatisierung übersetzt diese Erwartung in einen deterministischen, ausführbaren Ablauf.

1. Fachliche Akzeptanzkriterien beantworten die Frage: Was muss gelten?

Ein fachliches Akzeptanzkriterium beschreibt den aus Sicht des Business erwarteten Zustand oder das erwartete Verhalten eines Systems. Es soll eindeutig, verständlich und prüfbar sein, ohne sich unnötig an eine konkrete technische Implementierung zu binden.

Ein typisches Beispiel aus einem TM4-Kontext ist: 

Then wird die Wegleitung in der Sprache "<Sprache>" geöffnet
And die geöffnete Wegleitungs-URL entspricht "<Wegleitungslink>"

Fachlich werden hier zwei Erwartungen formuliert:

  • Die richtige Sprachversion der Wegleitung wird geöffnet.
  • Die geöffnete URL entspricht dem vorgesehenen Wegleitungslink.

Aus Sicht der fachlichen Anforderung bilden diese beiden Aussagen gemeinsam den erwarteten Zustand. Sie beschreiben nicht, wie ein Browser intern navigiert, wann ein DOM-Element verfügbar ist, wie lange eine Weiterleitung dauert oder welcher technische Prüfmechanismus verwendet wird.

2. Warum die Reihenfolge bei unabhängigen fachlichen Ergebnissen nicht entscheidend ist

Wenn zwei fachliche Aussagen voneinander unabhängig denselben Zielzustand beschreiben, ist ihre Reihenfolge für die Bedeutung des Akzeptanzkriteriums grundsätzlich nicht entscheidend.

Fachlich bedeutet: 

Then wird die Wegleitung in der Sprache "<Sprache>" geöffnet
And die geöffnete Wegleitungs-URL entspricht "<Wegleitungslink>"

dasselbe wie: 

Then entspricht die geöffnete Wegleitungs-URL "<Wegleitungslink>"
And die Wegleitung wird in der Sprache "<Sprache>" geöffnet

In beiden Varianten lautet die fachliche Aussage: Die richtige Wegleitung muss am richtigen Ort und in der richtigen Sprache geöffnet werden.

Wichtig ist die Einschränkung: Das gilt dann, wenn die einzelnen Aussagen tatsächlich unabhängige Merkmale desselben fachlichen Ergebnisses beschreiben. Wenn eine Aussage fachlich Voraussetzung für eine andere ist, kann auch auf fachlicher Ebene eine Reihenfolge relevant sein.

3. Gherkin selbst führt Schritte trotzdem in Reihenfolge aus

Eine wichtige Unterscheidung darf dabei nicht verloren gehen: Nur weil die Reihenfolge für die fachliche Bedeutung zweier unabhängiger Aussagen unwichtig sein kann, bedeutet das nicht, dass Cucumber die Reihenfolge ignoriert.

Ein ausführbares Gherkin-Szenario wird technisch Schritt für Schritt in der geschriebenen Reihenfolge ausgeführt. Auch And ist dabei kein paralleler Prüfpunkt, sondern setzt die vorherige Schrittfolge fort.

Deshalb muss zwischen zwei Ebenen unterschieden werden:

  • Semantische Ebene: Was sagt das fachliche Akzeptanzkriterium aus?
  • Ausführungsebene: In welcher Reihenfolge führt die Testautomatisierung die Prüfungen aus?

4. Der technische Testfall beantwortet die Frage: Wie prüfe ich das zuverlässig?

Ein technischer Testfall muss aus einer fachlichen Erwartung einen stabilen, reproduzierbaren Ablauf machen. Dafür reicht es nicht, nur die Endergebnisse aufzuzählen.

Die Testautomatisierung muss beispielsweise wissen:

  • Welches Element wird zuerst ausgewählt?
  • Welches Ereignis löst das Öffnen der Wegleitung aus?
  • Öffnet sich die Wegleitung im selben Fenster oder in einem neuen Tab?
  • Wann ist die Navigation abgeschlossen?
  • Wann ist die neue Seite tatsächlich geladen?
  • Wann kann die URL zuverlässig gelesen werden?
  • Wann steht der sprachabhängige Inhalt zur Verfügung?
  • Welche Wartebedingung ist notwendig, bevor eine Assertion ausgeführt wird?

Diese Punkte gehören nicht zwingend in das fachliche AK. Sie gehören in die technische Umsetzung des Tests, beispielsweise in Step Definitions, Page Objects, Hilfsfunktionen oder Playwright-Assertions.

5. Beim technischen Test ist Reihenfolge eine Voraussetzung für Stabilität

Im technischen Test kann eine falsche Reihenfolge dazu führen, dass ein fachlich korrektes System trotzdem einen fehlgeschlagenen automatisierten Test erzeugt.

Beispiel:

  1. Der Benutzer wählt den Wegleitungslink.
  2. Der Browser beginnt die Navigation.
  3. Der Test wartet auf das neue Dokument oder den neuen Tab.
  4. Die URL wird geprüft.
  5. Die Sprache oder der erwartete Inhalt wird geprüft.

Würde der Test die URL bereits prüfen, bevor die Navigation abgeschlossen ist, könnte noch die alte URL vorhanden sein. Würde die Sprache geprüft, bevor die Zielseite ihren Inhalt geladen hat, könnte das erwartete Element noch fehlen.

Das Problem wäre dann nicht die fachliche Anforderung, sondern die technische Reihenfolge der Testausführung.

6. Fachliche Reihenfolge und technische Reihenfolge sind zwei verschiedene Dinge

Diese Unterscheidung ist besonders wichtig, weil dieselbe Gherkin-Schreibweise leicht den Eindruck vermittelt, Fachlichkeit und technische Ausführung seien identisch.

Sie sind es nicht.

Ein fachliches AK kann beispielsweise lauten: 

Then wird die Wegleitung in der Sprache "<Sprache>" geöffnet
And die geöffnete Wegleitungs-URL entspricht "<Wegleitungslink>"

Die technische Umsetzung kann intern aber wesentlich feiner sein: 

1. Klick auf Wegleitungslink auslösen
2. Navigation bzw. neuen Tab erkennen
3. Auf Ladezustand warten
4. Ziel-URL auslesen
5. URL gegen Erwartungswert prüfen
6. sprachabhängiges Seitenelement lokalisieren
7. Sprache bzw. Inhalt prüfen

Das fachliche AK bleibt kompakt. Die technische Umsetzung trägt die Verantwortung für die korrekte zeitliche und logische Reihenfolge.

7. Warum technische Details nicht unnötig in fachliche AKs gehören

Werden technische Abläufe zu stark in fachliche Akzeptanzkriterien eingebaut, entstehen mehrere Nachteile.

  • Die fachliche Aussage wird schwerer verständlich.
  • Das AK wird stärker an eine konkrete technische Umsetzung gekoppelt.
  • Änderungen in der Testautomatisierung erzwingen unnötige Änderungen an fachlichen AKs.
  • Business Stakeholder müssen technische Details verstehen, die für die Fachlichkeit nicht relevant sind.
  • Die Trennung zwischen Requirement und Testimplementierung wird verwischt.

Ein fachliches Akzeptanzkriterium sollte deshalb so detailliert wie nötig, aber so technisch neutral wie möglich sein.

8. Jira als fachliche Wahrheit, GitLab als ausführbare Wahrheit

In den bisherigen TM4-Diskussionen hat sich dafür ein sinnvolles Zwei-Schichten-Modell ergeben:

  • Jira: fachliche Akzeptanzkriterien als prüfbare Done-Bedingung.
  • GitLab / Cucumber / Playwright: ausführbare technische Umsetzung dieser Kriterien.

Dadurch bleibt im Jira nachvollziehbar, welche fachliche Erwartung erfüllt sein muss. Die technische Testautomatisierung kann gleichzeitig so detailliert und robust implementiert werden, wie es für eine zuverlässige Ausführung notwendig ist.

9. Ein fachliches AK sollte keine Selektoren und Wartezeiten kennen

Ein Business Analyst sollte im Akzeptanzkriterium normalerweise nicht festlegen, dass beispielsweise zuerst ein bestimmter CSS-Selektor gefunden, anschliessend auf networkidle gewartet und danach ein Locator geprüft werden muss.

Solche Angaben können für Playwright entscheidend sein, sind aber keine fachlichen Anforderungen.

Die fachliche Aussage lautet:

Die vorgesehene Wegleitung wird in der gewünschten Sprache unter dem vorgesehenen Link geöffnet.

Wie dies technisch geprüft wird, ist Aufgabe der Testimplementierung.

10. Wann die Reihenfolge auch im fachlichen AK wichtig wird

Es wäre jedoch falsch, daraus abzuleiten, dass Reihenfolge in fachlichen AKs grundsätzlich unwichtig ist. Sobald der Geschäftsprozess selbst eine Abfolge verlangt, muss diese fachlich beschrieben werden.

Beispiele:

  • Eine Berechnung darf erst nach einer bestimmten Eingabe ausgelöst werden.
  • Ein Datensatz muss gespeichert sein, bevor eine Folgemaske geöffnet werden darf.
  • Eine Fehlermeldung erscheint erst nach einer konkreten Benutzeraktion.
  • Eine Auswahl beeinflusst nachfolgend verfügbare Felder.

Dann ist die Reihenfolge selbst Bestandteil der Fachlogik und gehört folglich auch in das AK.

11. Die entscheidende Frage für den Business Analyst

Beim Schreiben eines Akzeptanzkriteriums hilft eine einfache Kontrollfrage:

Ist diese Reihenfolge fachlich erforderlich, oder brauche ich sie nur, damit ein automatisierter Test technisch stabil ausgeführt werden kann?

Ist sie fachlich erforderlich, gehört sie in das AK. Ist sie nur für die technische Testausführung notwendig, gehört sie in den Testfall beziehungsweise in die Automatisierung.

12. Dasselbe gilt für Then und And

Then und And sollten in fachlichen AKs primär erwartete Ergebnisse verständlich strukturieren. Die Reihenfolge mehrerer unabhängiger Ergebnisprüfungen sollte nicht künstlich zu einer fachlichen Abhängigkeit erklärt werden.

Technisch muss die Automatisierung dagegen sehr wohl entscheiden, welche Assertion zuerst sinnvoll und möglich ist.

Das ist kein Widerspruch, sondern genau die notwendige Trennung zwischen fachlicher Beschreibung und technischer Ausführung.

13. Vorteile dieser Trennung

Eine klare Trennung zwischen fachlichem AK und technischem Testfall bringt mehrere Vorteile:

  • Akzeptanzkriterien bleiben für Fachbereich, BA, Entwicklung und Testing verständlich.
  • Technische Tests können unabhängig optimiert werden.
  • Änderungen an Playwright-Mechanismen verändern nicht automatisch die fachliche Spezifikation.
  • Fachliche Regeln bleiben langfristig stabiler als technische Testdetails.
  • Fehler lassen sich besser einordnen: Requirement-Problem oder Testimplementierungsproblem?
  • Wiederverwendbare Step Definitions und Satzschablonen werden einfacher möglich.

Mein Fazit

Fachliche und technische Akzeptanzkriterien beziehungsweise Testfälle verfolgen dasselbe Ziel: Sie sollen sicherstellen, dass die gewünschte Funktion korrekt umgesetzt wurde. Trotzdem arbeiten sie auf unterschiedlichen Ebenen.

Das fachliche Akzeptanzkriterium beschreibt den erwarteten Zustand. Bei mehreren unabhängigen Ergebnissen ist deren Aufzählungsreihenfolge für die fachliche Aussage häufig nicht entscheidend.

Der technische Testfall dagegen muss einen konkreten Ablauf beherrschen. Navigation, Ladezustände, Abhängigkeiten, Seitenelemente und Assertions müssen in einer sinnvollen Reihenfolge ausgeführt werden.

Gerade beim Beispiel der Wegleitung wird der Unterschied deutlich: Fachlich zählt, dass die richtige Wegleitung in der richtigen Sprache unter dem richtigen Link geöffnet wird. Technisch zählt zusätzlich, wann welcher Zustand erreicht ist und wann welche Prüfung zuverlässig erfolgen kann.

Für eine professionelle Business Analyse ist diese Trennung zentral: Das AK beschreibt, was gelten muss. Der technische Test beschreibt, wie dieses Ergebnis zuverlässig bewiesen wird.

Kommentare

Kommentare werden geladen ...

Kommentar verfassen

Der Kommentar wird nicht automatisch veröffentlicht. Er wird zuerst geprüft und bei Freigabe in der zentralen Kommentar-Datei ergänzt.

← Zurück zur Blogübersicht