Specification by Example
- Typische Dauer:
- 1h
Eine kollaborative Praxis, bei der Business-Stakeholder, Entwickler und Tester Anforderungen durch konkrete Beispiele definieren, die zu automatisierten Akzeptanztests werden.
Zweck
Specification by Example (SBE) überbrückt die Lücke zwischen Geschäftsabsicht und funktionierender Software. Durch Definition von Anforderungen als konkrete, testbare Beispiele vor Entwicklungsbeginn baut das Team gemeinsames Verständnis auf und produziert lebende Dokumentation.
Auf einen Blick
| Merkmal | Detail |
|---|---|
| Gruppengröße | 3 – 8 |
| Dauer | 60 Minuten |
| Schwierigkeit | Mittel–Hoch |
| Moderationsstil | Kollaborativer Workshop |
| Setting | Vor Ort oder Videocall mit geteiltem Dokument |
Ablauf
- Feature identifizieren (5 Min.) — Feature oder User Story zur Spezifikation auswählen.
- Geschäftsregeln ableiten (15 Min.) — Welche Regeln steuern dieses Feature?
- Mit Beispielen illustrieren (25 Min.) — Pro Regel konkrete Beispiele erstellen: Gegeben [Kontext], Wenn [Aktion], Dann [Ergebnis].
- Beispiele verfeinern (10 Min.) — Redundante Beispiele entfernen.
- Automatisierung vereinbaren (5 Min.) — Entscheiden, welche Beispiele automatisierte Akzeptanztests werden.
Material
- Feature- oder User-Story-Beschreibung
- Gegeben-Wenn-Dann-Template
- Geteiltes Dokument oder Spezifikationstool
Stolperfallen & häufige Fehler
- Beispiele zu abstrakt — Konkrete Daten verwenden.
- Zu viele Beispiele — Pro Regel 2–4 Beispiele, nicht 20.
- Keine Automatisierung — Beispiele in Dokumenten veralten schnell.
- Nur Tester nehmen teil — Der Wert kommt aus dem Three-Amigos-Gespräch.
Inklusion & Barrierefreiheit
- Beispiele in verständlicher Geschäftssprache schreiben.
- Feature-Beschreibung vorab teilen.
- Nicht-technischen Teilnehmern eigene Wortwahl für Beispiele ermöglichen.
Varianten
- Example Mapping — Farbige Karten zur Strukturierung des Gesprächs.
- BDD-Workshops — Sessions zum Schreiben von Gherkin-Szenarien.
- Lebende Dokumentation — Dokumentation aus automatisierten Beispielen generieren.
Wann NICHT einsetzen
- Für explorative Arbeit oder Spikes.
- Wenn keine automatisierte Testinfrastruktur vorhanden ist.
Quelle & Weiterlesen
- Adzic, G. (2011). *Specification by Example*. Manning.
- North, D. (2006). „Introducing BDD.“ dannorth.net
Aus den Bausteinen eine Agenda machen
Leg den Tag an, zieh die Blöcke in die Reihenfolge, die dir vorschwebt, und lass die Zeiten sich selbst ausrechnen. Oder beschreib deiner KI, was du vorhast, und lass sie den ersten Entwurf schreiben.
14 Tage kostenlos testen