methodatlas
MethodenanleitungAgile

Specification by Example

Die Anleitung zur Methode: Voraussetzungen und Materialien klären, den gesamten Ablauf verstehen und Ergebnisse, Stolperfallen sowie Abbruchkriterien nachschlagen.

KomplexitätMittel
Zeit60-90 min pro Feature
Teilnehmende3-6
FormatWorkshop
ReifegradCanonical
Specification by Example planen
01

Vorbedingung

Was vorher fertig sein muss

Vorher abschließenKleine fachliche Änderung

Story oder Regel ist klein genug für konkrete Beispiele.

Zu großer Scope erzeugt unverbundene Szenarien und verdeckt Regeln.
Vorher abschließenThree Amigos

Domain/Product, Development und Test bringen ihre Perspektiven ein.

Ohne Rollenvielfalt bleiben wichtige Beispiele und Fragen unsichtbar.
02

Vorbereitung

Was vor Start vorliegen muss

Materialien

Story oder Regel, reale Fälle, vierfarbige Example-Map-Karten, Domänenvokabular, Feature-Datei und Testzugang.

Personen / Rollen

Product/Domain Expert · Developer · Tester · optional Facilitator

Vorabinfos

Kleine Änderung auswählen, bekannte Regeln und Vorfälle sammeln und entscheidungsfähige Domainperson einladen.

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.

03

Kernfrage

Die eine Frage, die diese Methode beantwortet

Welche konkreten Beispiele zeigen, dass die Geschäftsregel fachlich richtig, vollständig und testbar verstanden ist?

04

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.

Regel-Beispiel-Spezifikation
BeispielGeschäftsregelGiven: KontextWhen: EreignisThen: ErgebnisOffene Frage oder Grenze
Storno exakt 24 Stunden vorherGrenzbeispielKostenlose 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. 1. Geschäftsregel

    Storno exakt 24 Stunden vorher
    Kostenlose Stornierung bis einschließlich 24 Stunden vor Beginn.
  2. 2. Given: Kontext

    Storno exakt 24 Stunden vorher
    Termin beginnt am 20.06. um 10:00; bezahlt sind 120 €.
  3. 3. When: Ereignis

    Storno exakt 24 Stunden vorher
    Kundin storniert am 19.06. um 10:00.
  4. 4. Then: Ergebnis

    Storno exakt 24 Stunden vorher
    120 € werden vollständig erstattet; Bestätigung nennt 0 € Gebühr.
  5. 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.

Cucumber: Behaviour-Driven Development

  1. 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. 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. 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. 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

05

Artefakt

Was am Ende rauskommt

Skizze: so sieht das Artefakt aus

Specification by Example · Beispiele als SpezifikationStory, Regeln und konkrete Beispiele gemeinsam schärfen und als ausführbare Acceptance Tests in Tabellenform übergeben
Specification by ExampleDas Visual zeigt Story, Regeln, konkrete Given-When-Then-Beispiele, Grenzfälle, Acceptance Tests und offene Fragen.Anforderungen über konkrete Beispiele eindeutig machenBusiness, Test und Engineering formulieren Beispiele so präzise, dass daraus lebende Spezifikation und Acceptance Tests werden.Story / Featurewelches Verhalten soll eindeutigwerden?Regelnfachliche Aussagen als prüfbare SätzeBeispieltabelleGivenWhenThenE1Konto aktivBestellung > LimitFreigabe nötigE2Limit erreichtRabatt steigtWarnung zeigenE3Daten fehlenSendenFehler erklärenAcceptance TestsBeispiele werden ausführbar undbleiben lebende DokumentationOffene Fragenunklare Regeln zurück ins RefinementBeispiele konkret statt ProsaGrenzfälle aktiv suchenfachlich lesbar,technisch prüfbar
Form

Versionierte Rule/Example-Spezifikation mit Fragenlog, Automatisierungsbindung und Teststatus.

Versionierung / Ownership

Datum, Autor, Quellenstand und Entscheidungsstatus je Revision erhalten; frühere Ergebnisse nicht überschreiben.

Tool-Alternativen
  • 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

BeispielRegelAusgangslageEreignisBeobachtbares ErgebnisFrage · 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

06

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?

07

Stolperfallen

Symptome erkennen, gegensteuern

Kurzüberblick, vollständiger Text steht in der jeweiligen Phase im Ablauf

  1. Regeln mit Beispielen erkundenDas Gespräch springt direkt in Gherkin oder UI-Klickfolgen und verdeckt fachliche Unsicherheit.In der Phase ansehen
  2. Beispiele als lesbare Spezifikation schreibenSzenarien enthalten Klickfolgen und Selektoren, sodass eine UI-Änderung die fachliche Spezifikation bricht.In der Phase ansehen
  3. Beispiele mit dem System verbindenAlle Beispiele werden über eine langsame End-to-End-UI automatisiert und werden fragil.In der Phase ansehen
  4. Lebende Spezifikation erhaltenSzenarien bleiben grün, erklären aber eine überholte Geschäftsregel oder doppeln nur Implementierungsdetails.In der Phase ansehen
08

Abbruchkriterien

Wann du anhalten, Voraussetzungen klären oder einen anderen Ansatz wählen solltest

Jeder Eintrag ist methodengerecht formuliert und mit Evidenz oder offen markierter Unsicherheit verbunden.
Nächste Entscheidung, Owner und Prüftermin sind soweit erforderlich sichtbar.

Methode nach Gojko Adzic. Kuratiert mit 1 Quellen.

Quellen: Cucumber: Behaviour-Driven Development

Ablauf, Timeboxen und Stolperfallen sind redaktionell kuratierte Praxisempfehlungen auf Basis der genannten Quellen.

Methodenanleitung durchgearbeitet?

Zum Steckbrief für Zweck, ähnliche Methoden und Quellen oder direkt zur nächsten Methode im Katalog.