Executable Specifications (ausführbare Spezifikationen)

« Back to Glossary Index

Kurzdefinition

Executable Specifications sind fachliche Anforderungen, die so präzise und formalisiert beschrieben sind, dass sie automatisiert ausgeführt werden können – typischerweise als Tests. Damit dienen sie gleichzeitig als Spezifikation (Dokumentation) und als verifizierbare Akzeptanzkriterien.

Was bedeutet das genau?

Statt Anforderungen nur in Textform (z. B. „Das System soll …“) zu dokumentieren, werden sie in einer Form beschrieben, die ein Tool ausführen kann – häufig als:

• Akzeptanztests (Acceptance Tests)
• BDD-Szenarien (Behavior-Driven Development), z. B. in Gherkin („Given–When–Then“)
• ATDD-Tests (Acceptance Test–Driven Development)
• Specification by Example: Anforderungen werden über konkrete Beispiele beschrieben, die maschinell prüfbar sind.

Das Ziel ist, dass die Spezifikation immer aktuell bleibt, weil sie im CI/CD-Prozess regelmäßig läuft und bei Abweichungen sofort fehlschlägt.

Typische Merkmale

✅ Fachlich verständlich (für Product Owner, Fachbereich, QA, Dev)
✅ Eindeutig (weniger Interpretationsspielraum)
✅ Automatisiert prüfbar (z. B. als Test)
✅ Lebende Dokumentation (ändert sich mit dem System)
✅ Gemeinsam erstellt (oft in „Three Amigos“: Business–Dev–QA)

Warum sind Executable Specifications nützlich?

• Gemeinsames Verständnis: Anforderungen werden anhand ausführbarer Beispiele geklärt.
• Weniger Missverständnisse: Präzise Akzeptanzkriterien reduzieren „Implementiert, aber falsch“.
• Schnelles Feedback: Änderungen brechen Tests sofort, wenn sie die Spezifikation verletzen.
• Nachvollziehbarkeit: Man kann jederzeit zeigen, welches Verhalten vereinbart ist.

Beispiel (Gherkin)

Funktionalität: Passwort zurücksetzen

Szenario: Erfolgreiches Zurücksetzen mit gültigem Token
  Angenommen der Nutzer hat ein gültiges Reset-Token
  Wenn der Nutzer ein neues Passwort setzt
  Dann wird das Passwort gespeichert
  Und der Nutzer kann sich mit dem neuen Passwort anmelden

Abgrenzung / verwandte Begriffe

• Akzeptanzkriterien: Können Teil ausführbarer Spezifikationen sein, müssen aber nicht automatisch ausführbar sein.
• Unit Tests: Prüfen Implementierungsdetails; Executable Specifications prüfen fachliches Verhalten.
• Regressionstests: Executable Specifications wirken oft als Regressionstests, sind aber primär Spezifikation.
• Living Documentation: Ergebnis/Benefit, wenn die Spezifikationen regelmäßig ausgeführt werden.

Häufige Stolpersteine

⚠️ Zu technisch formuliert: Wenn nur Entwickler es verstehen, geht der Business-Nutzen verloren.
⚠️ Zu viele UI-End-to-End-Tests: Fragil und langsam; lieber auf Service-/API-Ebene spezifizieren, wo möglich.
⚠️ Unklare Verantwortlichkeit: Ohne Pflege werden sie veraltet oder ignoriert.
⚠️ „Test-Suite ohne Spezifikation“: Wenn Szenarien nicht das gewünschte Verhalten beschreiben, sondern nur Implementierung nachzeichnen.

Praxis-Tipp (Best Practices)

• Beschreibe Verhalten und Regeln, nicht Klickpfade.
• Nutze konkrete Beispiele (z. B. Grenzwerte, Fehlerszenarien).
• Halte Szenarien klein, unabhängig und eindeutig.
• Etabliere sie im Prozess (Refinement/Three-Amigos) und im CI.

« Back to Glossary Index