Story oder Regel ist klein genug für konkrete Beispiele.
Specification by Example
Die Anleitung zur Methode: Voraussetzungen und Materialien klären, den gesamten Ablauf verstehen und Ergebnisse, Stolperfallen sowie Abbruchkriterien nachschlagen.
Vorbedingung
Was vorher fertig sein muss
Domain/Product, Development und Test bringen ihre Perspektiven ein.
Vorbereitung
Was vor Start vorliegen muss
Story oder Regel, reale Fälle, vierfarbige Example-Map-Karten, Domänenvokabular, Feature-Datei und Testzugang.
Product/Domain Expert · Developer · Tester · optional Facilitator
Kleine Änderung auswählen, bekannte Regeln und Vorfälle sammeln und entscheidungsfähige Domainperson einladen.
25–45 Minuten Discovery je kleine Story; Formulation und Automation folgen
Story, Regeln, Beispiele und Fragen getrennt darstellen; Gherkin erst nach gemeinsamer Discovery formulieren.
Kernfrage
Die eine Frage, die diese Methode beantwortet
Welche konkreten Beispiele zeigen, dass die Geschäftsregel fachlich richtig, vollständig und testbar verstanden ist?
Ablauf
Phasen mit Ziel, Durchführung, Ergebnis und Stolperfalle
Specification by Example verbindet Discovery, Formulation und Automation. Fachseite, Entwicklung und Test klären Regeln an realistischen Beispielen, formulieren sie in domänennaher Sprache und halten ausführbare Spezifikation und Systemverhalten gemeinsam aktuell.
Regel-Beispiel-Spezifikation
Fiktives Arbeitsbeispiel
Jede Zeile verbindet eine Geschäftsregel mit einem konkreten Beispiel und offenem Klärungsbedarf.
| Beispiel | Geschäftsregel | Given: Kontext | When: Ereignis | Then: Ergebnis | Offene Frage oder Grenze |
|---|---|---|---|---|---|
| Storno exakt 24 Stunden vorherGrenzbeispiel | Kostenlose Stornierung bis einschließlich 24 Stunden vor Beginn. | Termin beginnt am 20.06. um 10:00; bezahlt sind 120 €. | Kundin storniert am 19.06. um 10:00. | 120 € werden vollständig erstattet; Bestätigung nennt 0 € Gebühr. | Welche Zeitzone bestimmt Beginn und Stornozeitpunkt? |
1. Geschäftsregel
- Storno exakt 24 Stunden vorher
- Kostenlose Stornierung bis einschließlich 24 Stunden vor Beginn.
2. Given: Kontext
- Storno exakt 24 Stunden vorher
- Termin beginnt am 20.06. um 10:00; bezahlt sind 120 €.
3. When: Ereignis
- Storno exakt 24 Stunden vorher
- Kundin storniert am 19.06. um 10:00.
4. Then: Ergebnis
- Storno exakt 24 Stunden vorher
- 120 € werden vollständig erstattet; Bestätigung nennt 0 € Gebühr.
5. Offene Frage oder Grenze
- Storno exakt 24 Stunden vorher
- Welche Zeitzone bestimmt Beginn und Stornozeitpunkt?
Ein Beispiel illustriert eine Regel. Fragen werden vor der Formulation entschieden oder sichtbar zurückgestellt.
- 1
Entdecken
Regeln mit Beispielen erkunden

Ziel
Gemeinsames Verständnis der fachlichen Regel, Grenzen und offenen Fragen herstellen.
Voraussetzungen für diesen Schritt
- Kleine Story oder fachliche Änderung
- Domain Expert, Developer und Tester
- Bekannte Regeln und Vorfälle
Durchführung
- Geschäftsregeln statt UI-Schritte benennen.
- Pro Regel typische, Grenz- und Gegenbeispiele sammeln.
- Unbeantwortete Fragen separat markieren und Scope schneiden.
Ergebnis
Example Map
Regeln · Beispiele · Fragen · Scope
Qualitätscheck
Illustriert jedes Beispiel genau eine Regel?
Stolperfalle
Das Gespräch springt direkt in Gherkin oder UI-Klickfolgen und verdeckt fachliche Unsicherheit. In Alltagssprache zu Regel, Beispiel und erwarteter Wirkung zurückkehren.
Zeitlicher Rahmen: 20–30 Minuten
- 2
Formulieren
Beispiele als lesbare Spezifikation schreiben

Ziel
Ausgewählte Beispiele mit Kontext, Ereignis und erwartetem Ergebnis eindeutig formulieren.
Voraussetzungen für diesen Schritt
- Example Map
- Gemeinsames Domänenvokabular
- Entschiedene Fragen
Durchführung
- Beispielnamen aus fachlicher Wirkung ableiten.
- Given beschreibt relevanten Kontext, When das Ereignis, Then das beobachtbare Ergebnis.
- Irrelevante UI- und Implementierungsdetails entfernen.
Ergebnis
Ausführbare Spezifikation
Rule · Example · Given · When · Then
Qualitätscheck
Kann eine fachkundige Person das Verhalten ohne Implementierungswissen prüfen?
Stolperfalle
Szenarien enthalten Klickfolgen und Selektoren, sodass eine UI-Änderung die fachliche Spezifikation bricht. Schritte auf Domänenhandlung und beobachtbares Ergebnis anheben.
Zeitlicher Rahmen: 15–30 Minuten
- 3
Automatisieren
Beispiele mit dem System verbinden

Ziel
Ausführbare Beispiele als schnelle, verlässliche Rückmeldung in die Delivery integrieren.
Voraussetzungen für diesen Schritt
- Abgestimmte Spezifikation
- Testzugänge und Daten
- Produktcode
Durchführung
- Passende Automatisierungsebene wählen.
- Testdaten und Schrittdefinitionen wartbar gestalten.
- Beispiel zunächst fehlschlagen lassen und Verhalten implementieren.
Ergebnis
Automatisierte Beispiele
Spezifikation · Testbindung · Ergebnis
Qualitätscheck
Fehlschlägt das Beispiel aus einem fachlich verständlichen Grund?
Stolperfalle
Alle Beispiele werden über eine langsame End-to-End-UI automatisiert und werden fragil. Auf der niedrigsten fachlich aussagekräftigen Ebene automatisieren und nur notwendige Systemgrenzen durchlaufen.
Zeitlicher Rahmen: Je Beispiel unterschiedlich
- 4
Pflegen
Lebende Spezifikation erhalten

Ziel
Regel, Beispiele, Automatisierung und Systemverhalten bei Änderungen synchron halten.
Voraussetzungen für diesen Schritt
- Ausführbare Spezifikation
- Testergebnisse
- Neue fachliche Entscheidungen
Durchführung
- Bei Regeländerung zuerst Beispiele aktualisieren.
- Redundante Beispiele entfernen, ohne wichtige Grenzen zu verlieren.
- Veraltete Spezifikationen gemeinsam mit dem Code ändern oder löschen.
Ergebnis
Lebende Dokumentation
Aktuelle Regeln · Beispiele · Teststatus
Qualitätscheck
Beschreibt jedes grüne Beispiel noch relevantes Verhalten?
Stolperfalle
Szenarien bleiben grün, erklären aber eine überholte Geschäftsregel oder doppeln nur Implementierungsdetails. Regelverantwortung benennen und Spezifikation im selben Review wie Code behandeln.
Zeitlicher Rahmen: Laufende Pflege
Artefakt
Was am Ende rauskommt
Skizze: so sieht das Artefakt aus
Versionierte Rule/Example-Spezifikation mit Fragenlog, Automatisierungsbindung und Teststatus.
Datum, Autor, Quellenstand und Entscheidungsstatus je Revision erhalten; frühere Ergebnisse nicht überschreiben.
- Example Map
- Gherkin- oder andere ausführbare Spezifikation
- Automatisierung und CI-Testbericht
specification-by-example-working-template.md
Plane Specification by Example mit realem Scope, passenden Rollen und einem klaren Entscheidungsziel.
Specification by Example: Arbeitsvorlage
Fragestellung
Noch zu klären
Gewünschtes Ergebnis
Noch zu klären
Rahmen
Praxis einrichten und prüfen Zeit: 25–45 Minuten Discovery je kleine Story; Formulation und Automation folgen
Diese Vorlage während der Arbeit auf Papier oder in einem eigenen Dokument ausfüllen.
Vorbereitung für diesen Umfang
Methodische Grundausstattung
- Materialien: Story oder Regel, reale Fälle, vierfarbige Example-Map-Karten, Domänenvokabular, Feature-Datei und Testzugang.
- Rollen: Product/Domain Expert · Developer · Tester · optional Facilitator
- Vorab-Infos: Kleine Änderung auswählen, bekannte Regeln und Vorfälle sammeln und entscheidungsfähige Domainperson einladen.
- Gesamter Zeitbedarf: 25–45 Minuten Discovery je kleine Story; Formulation und Automation folgen
- Setup: Story, Regeln, Beispiele und Fragen getrennt darstellen; Gherkin erst nach gemeinsamer Discovery formulieren.
Für die Arbeitsschritte bereitstellen
Entdecken: Regeln mit Beispielen erkunden
- Kleine Story oder fachliche Änderung
- Domain Expert, Developer und Tester
- Bekannte Regeln und Vorfälle
Formulieren: Beispiele als lesbare Spezifikation schreiben
- Example Map
- Gemeinsames Domänenvokabular
- Entschiedene Fragen
Automatisieren: Beispiele mit dem System verbinden
- Abgestimmte Spezifikation
- Testzugänge und Daten
- Produktcode
Pflegen: Lebende Spezifikation erhalten
- Ausführbare Spezifikation
- Testergebnisse
- Neue fachliche Entscheidungen
Regel-Beispiel-Spezifikation
| Beispiel | Regel | Ausgangslage | Ereignis | Beobachtbares Ergebnis | Frage · Grenze |
|---|---|---|---|---|---|
| Storno exakt 24 Stunden vorher |
- Storno exakt 24 Stunden vorher: Grenzbeispiel
Geschäftsverhalten beschreiben; UI- und Implementierungsdetails weglassen.
Cucumber: Behaviour-Driven Development
Entdecken: Regeln mit Beispielen erkunden
Erwartetes Artefakt: Example Map
Regeln · Beispiele · Fragen · Scope
Eintrag:
...
- Illustriert jedes Beispiel genau eine Regel?
Formulieren: Beispiele als lesbare Spezifikation schreiben
Erwartetes Artefakt: Ausführbare Spezifikation
Rule · Example · Given · When · Then
Eintrag:
...
- Kann eine fachkundige Person das Verhalten ohne Implementierungswissen prüfen?
Automatisieren: Beispiele mit dem System verbinden
Erwartetes Artefakt: Automatisierte Beispiele
Spezifikation · Testbindung · Ergebnis
Eintrag:
...
- Fehlschlägt das Beispiel aus einem fachlich verständlichen Grund?
Pflegen: Lebende Spezifikation erhalten
Erwartetes Artefakt: Lebende Dokumentation
Aktuelle Regeln · Beispiele · Teststatus
Eintrag:
...
- Beschreibt jedes grüne Beispiel noch relevantes Verhalten?
Offene Fragen und nächste Schritte
...
Methodenanleitung: https://methodatlas.meierhoff-systems.de/de/methods/specification-by-example/run-sheet
Beispielausgabe
Konkret gefülltes Szenario, fiktives Beispiel
Fiktives Beispiel zur Orientierung. Die genannten Mengen und Zeiten beschreiben diesen Fall und sind keine allgemeine Vorgabe.
specification-by-example-beispiel.md
Konkret gefülltes Szenario, fiktives Beispiel
Fiktives Beispiel: Regel 'Kostenlose Stornierung bis 24 Stunden vor Beginn'. Beispiel: Beginn 20.06. 10:00, Storno 19.06. 09:59, bezahlter Betrag 120 €, erwartete Erstattung 120 €. Grenzbeispiel: Storno 19.06. 10:00 ist ebenfalls kostenlos, weil exakt 24 Stunden. Frage: Welche Zeitzone gilt?
Stolperfallen
Symptome erkennen, gegensteuern
Kurzüberblick, vollständiger Text steht in der jeweiligen Phase im Ablauf
- Regeln mit Beispielen erkundenDas Gespräch springt direkt in Gherkin oder UI-Klickfolgen und verdeckt fachliche Unsicherheit.In der Phase ansehen
- Beispiele als lesbare Spezifikation schreibenSzenarien enthalten Klickfolgen und Selektoren, sodass eine UI-Änderung die fachliche Spezifikation bricht.In der Phase ansehen
- Beispiele mit dem System verbindenAlle Beispiele werden über eine langsame End-to-End-UI automatisiert und werden fragil.In der Phase ansehen
- Lebende Spezifikation erhaltenSzenarien bleiben grün, erklären aber eine überholte Geschäftsregel oder doppeln nur Implementierungsdetails.In der Phase ansehen
Regeln mit Beispielen erkunden
Das Gespräch springt direkt in Gherkin oder UI-Klickfolgen und verdeckt fachliche Unsicherheit.
In Alltagssprache zu Regel, Beispiel und erwarteter Wirkung zurückkehren.
Beispiele als lesbare Spezifikation schreiben
Szenarien enthalten Klickfolgen und Selektoren, sodass eine UI-Änderung die fachliche Spezifikation bricht.
Schritte auf Domänenhandlung und beobachtbares Ergebnis anheben.
Beispiele mit dem System verbinden
Alle Beispiele werden über eine langsame End-to-End-UI automatisiert und werden fragil.
Auf der niedrigsten fachlich aussagekräftigen Ebene automatisieren und nur notwendige Systemgrenzen durchlaufen.
Lebende Spezifikation erhalten
Szenarien bleiben grün, erklären aber eine überholte Geschäftsregel oder doppeln nur Implementierungsdetails.
Regelverantwortung benennen und Spezifikation im selben Review wie Code behandeln.
Abbruchkriterien
Wann du anhalten, Voraussetzungen klären oder einen anderen Ansatz wählen solltest
Methodenanleitung durchgearbeitet?
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen oder direkt zur nächsten Methode im Katalog.

