Zum Inhalt
wannacode

Lebendige Dokumentation

Kurz gesagt: Ein Word-Dokument veraltet unbemerkt. Szenarien laufen bei jeder Änderung und fallen durch, sobald das System nicht mehr tut, was sie sagen: Das ist lebendige Dokumentation. Sie werden vor der Arbeit geschrieben, von den Three Amigos: Fachbereich, Entwickler und QA. BDD ist dieses Gespräch. Szenarien, die QA allein nach dem Code schreibt, sind nur Tests mit mehr Arbeit.

Problem

Das Dokument, das unbemerkt lügt

Ein neuer Mensch im Team öffnet die Spezifikation der Lieferung. Ein Word-Dokument von vor zwei Jahren. Darin steht: „kostenlose Lieferung über 40 €“.

Der Shop liefert ab 50 € kostenlos. Jemand hat die Regel geändert, aber nicht das Dokument. Niemand hat es bemerkt, weil das Dokument nichts tut: Es liegt nur da.

Jetzt weiß der neue Mensch nicht, was stimmt: das Dokument oder das System?

Die Idee

Dokumentation, die läuft

Die Szenarien in diesem Modul sind Dokument und Test zugleich. Ändert sich die Regel im System, aber nicht im Szenario, fällt das Szenario beim nächsten Lauf durch. Ändert sie sich im Szenario, aber nicht im System, fällt es auch durch. Die beiden können nicht unbemerkt auseinanderdriften.

Das heißt lebendige Dokumentation (living documentation). Sie lebt unter einer Bedingung: Die Szenarien laufen bei jeder Änderung, meistens automatisch. Szenarien, die niemand ausführt, veralten genauso wie das Word-Dokument.

Damit die Datei Dokumentation ist, muss sie sich auch so lesen:

  • Funktionalität sagt, was die Datei beschreibt, und die Story selbst kann darunter stehen;
  • Regel ist jede Geschäftsregel, in den Worten des Inhabers;
  • unter jeder Regel stehen die Beispiele: Szenarien und Grundrisse mit konkreten Zahlen.
# language: de
Funktionalität: Kostenlose Lieferung
  Als Kunde
  möchte ich bei einer größeren Bestellung kostenlose Lieferung,
  damit ich keine 4,90 € für die Lieferung zahle.


  Regel: Ein leerer Warenkorb kann nicht bestellt werden


    Szenario: Ein Warenkorb ohne Produkte
      Angenommen ein leerer Warenkorb
      Wenn ich bestelle
      Dann wird die Bestellung abgelehnt

Der Text unter „Funktionalität“ ist kein Schritt. Er ist eine Beschreibung: Gherkin überspringt ihn beim Ausführen, und Menschen lesen ihn.

Die Idee

Wer sie schreibt und wann

Szenarien schreibt nicht ein Mensch allein. Sie entstehen aus einem Gespräch zwischen drei Menschen, die du schon vom Example Mapping kennst. Sie heißen die Three Amigos:

  • der Fachbereich (der Inhaber oder die Analystin) nennt die Regeln und was zählt;
  • der Entwickler fragt, wie es gebaut wird und was daran schwierig ist;
  • QA fragt „was, wenn …?“: die Grenzen, den leeren Warenkorb, die Ablehnung.

Und wann? Vor der Arbeit. Ein Szenario, das vor dem Code geschrieben wird, sagt, was gewollt ist. Ein Szenario, das nach dem Code geschrieben wird, beschreibt, was gebaut wurde, Fehler eingeschlossen.

Die Dokumentation von Cucumber nennt die drei Schritte Entdeckung (discovery: ein Gespräch über konkrete Beispiele), Formulierung (formulation: Die Beispiele werden so aufgeschrieben, dass sie laufen können, und der Fachbereich bestätigt sie) und Automatisierung (automation: Der Entwickler bindet die Schritte an das System). Der dritte Schritt hat später ein eigenes Modul.

Probier es aus

Von der Story zum Dokument

Bring den Weg von der Story zur lebendigen Dokumentation in die Reihenfolge.

  1. Der Inhaber bringt die Story
  2. Der Entwickler bindet die Schritte und baut die Funktion
  3. Die Three Amigos legen Regeln, Beispiele und Fragen aus
  4. Der Fachbereich liest die Szenarien und sagt „ja, so ist es“
  5. Bei jeder späteren Änderung laufen die Szenarien wieder
  6. Die Beispiele werden als Gherkin-Szenarien aufgeschrieben
  7. Die Szenarien bestehen und die Story ist fertig

Die Idee

BDD gegen „Gherkin-Tests“

All das hat einen Namen: BDD (behaviour-driven development, verhaltensgetriebene Entwicklung). Das Wichtige an BDD ist nicht Gherkin. Es ist diese Reihenfolge: Gespräch, Beispiele, dann Code.

Viele Teams übernehmen nur die Syntax. QA schreibt die Szenarien allein, nach dem Code, mit „klicke auf den Button“. Der Fachbereich liest sie nie. Das sind Gherkin-Tests: gewöhnliche automatisierte Tests mit einer weiteren Schicht darüber, die gepflegt werden muss. Die Kosten von BDD sind bezahlt, und der Nutzen fehlt.

Anzeichen dafür:

  • niemand aus dem Fachbereich hat die Szenarien gelesen;
  • die Szenarien werden nach dem Code geschrieben;
  • die Schritte handeln von Buttons und Feldern, nicht von Regeln;
  • Szenarien werden korrigiert, wenn sie durchfallen, ohne zu fragen, ob das System es falsch gemacht hat.

Gibt es kein Gespräch, ist die ehrliche Wahl ein einfacher Komponententest. Er ist schneller und billiger. Gherkin lohnt sich, wenn der Fachbereich die Szenarien wirklich liest.

Probier es aus

BDD oder nicht?

1. QA schreibt die Szenarien allein, nachdem der Entwickler fertig ist. Niemand aus dem Fachbereich liest sie.
2. Der Inhaber, der Entwickler und QA besprechen die Beispiele vor der Arbeit. Die Szenarien entstehen in der Sitzung, und der Inhaber bestätigt sie.
3. Das Team schreibt Szenarien vor dem Code, aber alle lauten „klicke auf den Button“ und „öffne die Seite“.
4. Die Szenarien werden nur von Hand ausgeführt, einmal im Jahr.

Übung

Das Dokument zur Lieferung

Die ganze Funktionalität. Die Story und die Regeln sind geschrieben.

Setze unter jede Regel die Beispiele, die sie zeigen: um die Grenze herum, weit von ihr und den leeren Warenkorb. Das Dokument muss alle sechs Fehler abfangen.

GherkinKostenlose Lieferung
Genauer, für Neugierige

ISTQB CTFL v4.0.1. Abschnitt 2.1.3 („Testing as a Driver for Software Development“) stellt TDD, ATDD und BDD nebeneinander: Alle drei legen die Tests vor dem Code fest und wenden das Prinzip des frühen Testens an. Für BDD heißt es, die Testfälle werden in einer einfachen natürlichen Sprache geschrieben, die die Interessengruppen verstehen, meist Given/When/Then, und dann in automatisierte Tests umgewandelt. Abschnitt 4.5.3 beschreibt ATDD (acceptance test-driven development): einen Spezifikationsworkshop, in dem die Story und ihre Kriterien gemeinsam besprochen werden (Kunde, Entwickler, Tester), dann die Testfälle, zuerst die positiven, dann die negativen, dann die nichtfunktionalen. Liegen sie in einem Format vor, das ein Framework zur Testautomatisierung versteht, werden die Abnahmetests zu ausführbaren Anforderungen.

ISTQB CT-AcT v1.0 (Abnahmetest) hat ein Kapitel über kollaborativen Abnahmetest und behandelt Akzeptanzkriterien und Abnahmetests als gemeinsame Arbeit von Business-Analyse und Testen.

Dan North beschreibt BDD im Artikel „Introducing BDD“, zuerst im März 2006 im Magazin Better Software erschienen. Darin entwickelt er mit Chris Matts eine Vorlage für Akzeptanzkriterien als Szenarien: Given (der Kontext), When (das Ereignis), Then (die Ergebnisse).

Die Three Amigos. Der Name ist in der agilen Gemeinschaft weit verbreitet. Er wird oft mit George Dinwiddie verbunden, aber wir haben keine Primärquelle gefunden, die das bestätigt.

Die Dokumentation von Cucumber („Behaviour-Driven Development“) beschreibt die drei Praktiken: Discovery, Formulation und Automation.

Test

Teste dich

1. Was macht Szenarien zu „lebendiger“ Dokumentation?
2. Wer sind die Three Amigos?
3. Wann werden Szenarien im BDD geschrieben?
4. Was ist ATDD nach ISTQB CTFL v4.0.1?

Erstellt von Ivo Gergov im Rahmen der Kampagne von Evo Tech für zugängliche Programmierausbildung ·