Meine Session planen

# Session Brief: Specification by Example

## Ziel
Artefakt: Beispieltabelle

## Arbeitsfrage
Welche konkreten Beispiele beschreiben die Geschäftslogik unmissverständlich, sodass sie als ausführbare Tests dienen können?

## Kontext
Story-Beschreibung mit Akzeptanzkriterien; bestehende Geschäftsregeln (z. B. aus Doku, Rechtstexten); fachliches Glossar; Liste bekannter Sonderfälle.

## Setup
- Format: Methoden-Session
- Dauer: 60-90 min pro Feature
- Modus: Workshop
- Teilnehmende: Ein Facilitator (Tester oder BA); Product Owner oder Domainexperte; Engineer mit Implementierungs-Wissen; optional ein Tester für Edge-Case-Suche.
- Owner: Ein Facilitator (Tester oder BA)
- Beteiligungsmodus: Teamrunde, gemeinsames Arbeiten und Alignment
- Ergebnislogik: Artefakt fertigstellen

## Beteiligungslogik
Nutze die Session für gemeinsames Verständnis. Beiträge werden sichtbar gesammelt, Annahmen werden abgeglichen und offene Unterschiede bleiben im Artefakt nachvollziehbar.

## Ergebnislogik
Die Session arbeitet direkt auf Beispieltabelle hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

## Input
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).

## Vorbereitung
Pro Story eine Sektion im Dokument. Tabelle mit Spalten Regel, Beispiel-Eingabe, Erwartete Ausgabe, Anmerkung. Gherkin-Vorlage als Optionalstruktur. Glossar sichtbar.

## Agenda
1. Phase 1: Story und Regeln klären (10-15 min)
   Owner: Facilitator
   Aktion: Story oder Feature vorstellen. Pro Story 1-5 Regeln benennen, die die Logik beschreiben (z. B. „Rabatt ab 100 EUR Warenwert“). Hinweis: Wenn Regeln nicht stabil sind, ist Story nicht reif für Specification by Example. Vorher mit PO Regeln aushandeln, dann Beispiele. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Beispieltabelle

2. Phase 2: Happy-Path-Beispiele (15-20 min)
   Owner: Facilitator
   Aktion: Pro Regel mindestens ein Happy-Path-Beispiel formulieren: konkrete Eingabewerte, erwartete Ausgabe. Beispiele in Tabelle oder Given-When-Then. Hinweis: 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. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Acceptance Tests

3. Phase 3: Grenzfälle und Edge Cases (15-25 min)
   Owner: Facilitator
   Aktion: Aktiv Grenzfälle suchen: Nullwerte, Maximalwerte, leere Listen, ungültige Eingaben, parallele Bedingungen. Pro Edge Case eigenes Beispiel. Hinweis: Tester treiben diese Phase. Wer keine Edge Cases findet, hat Story zu oberflächlich verstanden. Grenzfall-Suche ist methodischer Kern. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Beispieltabelle

4. Phase 4: Beispiele als Acceptance Tests übergeben (10-15 min)
   Owner: Owner
   Aktion: Beispiele in Test-Framework-Format überführen (Gherkin, JSON, CSV). Engineering implementiert Tests vor Code. Tester reviewt Coverage. Hinweis: Wenn Beispiele nicht automatisierbar sind, ist Schritt eingespart. Goldstandard: Beispiele werden zu lauffähigen Akzeptanztests. Manuelle Tests sind valider Fallback. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Acceptance Tests

5. Artefakt veröffentlichen (10 min)
   Owner: Owner
   Aktion: Artefakt auf Vollständigkeit prüfen, Ablageort festlegen, Version oder Status setzen und Review-Empfänger benennen.
   Output: Beispieltabelle

## Abschluss
- Ergebnisartefakt aktualisieren: Beispieltabelle
- Ablageort, Version und Review-Empfänger festlegen.
- Owner, nächster Schritt und Reviewtermin festlegen.

# Beispieltabelle: Specification by Example

## Arbeitsfrage
Welche konkreten Beispiele beschreiben die Geschäftslogik unmissverständlich, sodass sie als ausführbare Tests dienen können?

## Kontext
Story-Beschreibung mit Akzeptanzkriterien; bestehende Geschäftsregeln (z. B. aus Doku, Rechtstexten); fachliches Glossar; Liste bekannter Sonderfälle.

## Beteiligte
- Owner: Ein Facilitator (Tester oder BA)
- Teilnehmende: Ein Facilitator (Tester oder BA); Product Owner oder Domainexperte; Engineer mit Implementierungs-Wissen; optional ein Tester für Edge-Case-Suche.

## Input
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).

## Vorlage
# 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.

## Fertigstellungscheck
- Beispieltabelle ist vollständig genug für Review:
- Ablageort:
- Version / Status:
- Review durch:
- Nächster Schritt:

## Nächster Schritt
- Ergebnis prüfen
- offene Fragen markieren
- Review oder Entscheidung terminieren