Was vorher fertig sein muss
Business, Test und Engineering arbeiten in Refinement zusammen oder können für Workshop zusammengebracht werden.
Was vor Start vorliegen muss
Geteiltes Dokument oder Confluence-Seite mit Tabellen-Struktur; Story oder Feature-Beschreibung; bekannte Regelwerke aus Domain; Beispiele aus früheren ausführbaren Spezifikationen; Test-Framework-Referenz (Gherkin, Cucumber, SpecFlow).
Ein Facilitator (Tester oder BA); Product Owner oder Domainexperte; Engineer mit Implementierungs-Wissen; optional ein Tester für Edge-Case-Suche.
Story-Beschreibung mit Akzeptanzkriterien; bestehende Geschäftsregeln (z. B. aus Doku, Rechtstexten); fachliches Glossar; Liste bekannter Sonderfälle.
60-90 min pro Feature
Pro Story eine Sektion im Dokument. Tabelle mit Spalten Regel, Beispiel-Eingabe, Erwartete Ausgabe, Anmerkung. Gherkin-Vorlage als Optionalstruktur. Glossar sichtbar.
Die eine Frage, die diese Methode beantwortet
Welche konkreten Beispiele beschreiben die Geschäftslogik unmissverständlich, sodass sie als ausführbare Tests dienen können?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Story und Regeln klären | 10-15 min | Story oder Feature vorstellen. Pro Story 1-5 Regeln benennen, die die Logik beschreiben (z. B. „Rabatt ab 100 EUR Warenwert“). | Wenn Regeln nicht stabil sind, ist Story nicht reif für Specification by Example. Vorher mit PO Regeln aushandeln, dann Beispiele. |
2Phase 2: Happy-Path-Beispiele | 15-20 min | Pro Regel mindestens ein Happy-Path-Beispiel formulieren: konkrete Eingabewerte, erwartete Ausgabe. Beispiele in Tabelle oder Given-When-Then. | Werte mit Bedeutung wählen (z. B. 99,99 EUR, 100,00 EUR, 100,01 EUR statt nur 50, 100, 200). Bedeutungslose Werte verschleiern Grenzen. |
3Phase 3: Grenzfälle und Edge Cases | 15-25 min | Aktiv Grenzfälle suchen: Nullwerte, Maximalwerte, leere Listen, ungültige Eingaben, parallele Bedingungen. Pro Edge Case eigenes Beispiel. | Tester treiben diese Phase. Wer keine Edge Cases findet, hat Story zu oberflächlich verstanden. Grenzfall-Suche ist methodischer Kern. |
4Phase 4: Beispiele als Acceptance Tests übergeben | 10-15 min | Beispiele in Test-Framework-Format überführen (Gherkin, JSON, CSV). Engineering implementiert Tests vor Code. Tester reviewt Coverage. | Wenn Beispiele nicht automatisierbar sind, ist Schritt eingespart. Goldstandard: Beispiele werden zu lauffähigen Akzeptanztests. Manuelle Tests sind valider Fallback. |
Was am Ende rauskommt
Beispiel-Tabelle oder Gherkin-Feature-Datei im Repo, verlinkt mit Story im Ticket-System. Glossar im Wiki. Automatisierte Tests im Test-Verzeichnis, die Beispiele referenzieren.
Beispiele im Code-Repo, gleicher Branch wie Implementierung. Regel-Änderungen mit Pull Request, Beispiele werden mitversioniert. Glossar im Wiki versioniert.
Kompakte Arbeitsvorlage für Specification by Example mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# Specification by Example Arbeitsvorlage
## Ziel
Konkrete Beispiele dienen als ausführbare Spezifikation.
## Kontext
Wann und wofür nutzen wir diese Methode?
## Input
Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?
## Durchführung
Kurze Notizen entlang des Run Sheets.
## Ergebnisartefakte
- Beispieltabelle:
- Acceptance Tests:
## Annahmen und offene Fragen
- ...
## Entscheidung / Nächster Schritt
Owner, Datum und Erfolgssignal.Konkret gefülltes Szenario
## Specification by Example - Mandanten-Rabatt-Berechnung, 2026-05-18
**Story**: Als Steuerberater möchte ich automatisch einen Rabatt erhalten, wenn meine Mandanten-Anzahl die Staffel überschreitet.
**Regeln**
1. Bei 1-10 Mandanten: 0% Rabatt.
2. Bei 11-50 Mandanten: 10% Rabatt auf Gesamtpreis.
3. Bei 51-100 Mandanten: 20% Rabatt.
4. Bei >100 Mandanten: 30% Rabatt.
**Beispiele (Gherkin)**
```gherkin
Feature: Mandanten-Rabatt-Berechnung
Scenario Outline: Rabatt nach Mandanten-Anzahl
Given Steuerberater Sabine hat <Mandanten> aktive Mandanten
When der Monatspreis berechnet wird
Then ist der Rabatt <Rabatt>% und der Endpreis <Endpreis> EUR
Examples:
| Mandanten | Rabatt | Endpreis |
| 1 | 0 | 29.00 |
| 10 | 0 | 29.00 |
| 11 | 10 | 26.10 |
| 50 | 10 | 26.10 |
| 51 | 20 | 23.20 |
| 100 | 20 | 23.20 |
| 101 | 30 | 20.30 |
| 500 | 30 | 20.30 |
```
**Edge Cases**
- 0 Mandanten -> 0 EUR Endpreis (Sonderregel: kein Vertrag aktiv)?
- Mandanten mit Status „pausiert“ zählen nicht (Klärung mit PO).
- Bei Übergang im Monat (z. B. 10 auf 11 Mandanten am 15.): Rabatt-Recompute zum Monatsende.
**Glossar-Updates**: „Aktiver Mandant“ = Status „active“ in Tabelle mandanten, nicht pausiert oder gelöscht.Symptome erkennen, gegensteuern
Nur Happy-Path-Beispiele, Tests sind grün, aber Produktions-Edge-Cases lösen Bugs aus.
Tester treibt Edge-Case-Suche aktiv. Pro Story mindestens 30% Edge Cases. Liste typischer Edge-Patterns (Null, Max, Leer, Ungültig) als Checkliste.
Beispiele nutzen 1, 10, 100 ohne Bezug zu Geschäftsregeln, Grenzwerte werden nicht geprüft.
Werte um Grenzen wählen (99,99, 100,00, 100,01). Pro Regel-Grenze mindestens 3 Werte: vor, auf, nach Grenze.
Beispiele beschreiben UX-Verhalten ohne klare Eingabe-Ausgabe-Logik, Tests bleiben manuell.
Beispiele auf Logikebene halten, nicht UI. Wenn UI-Verhalten gemeint, separate UI-Tests definieren. Specification by Example ist Logik-Spezifikation.
Nur PO und Engineer anwesend, Tester fehlt. Edge Cases bleiben unbearbeitet, Coverage schwach.
Three-Amigos-Prinzip durchsetzen. Wenn Tester nicht verfügbar, Workshop verschieben oder asynchron Tester-Review einbauen. Nicht ohne Tester finalisieren.
Beispiele im Wiki werden gepflegt, Test-Code im Repo nicht synchron, Drift zwischen Doku und Realität.
Single Source of Truth: Beispiele im Code-Repo neben Tests. Wiki-Beispiele nur als generierter Output aus Test-Definitionen.
Done-Signale, in unter einer Minute prüfbar
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.