Behaviour Driven Development

Ziel

Behaviour Driven Development ist eine Praxis der Spezifikation durch Beispiele. Man schreibt die echten Fälle auf, die die Lösung zu behandeln hat, jeden als dreiteiliges Szenario: der Zustand der Dinge davor, das auslösende Ereignis, das beobachtbare Ergebnis danach. Das Szenario ist Text, lesbar für jemanden aus dem Fachbereich, der nie ein Entwicklungswerkzeug geöffnet hat, und strukturiert genug, damit ein Test-Runner es unverändert ausführt.

Das Problem, um das es geht, ist ein Informationsverlust durch Übersetzung. Ein vom Fachbereich geäussertes Bedürfnis wird vom Analysten zur Anforderung umformuliert, dann vom Entwickler zum Entwurf, dann vom Tester zum Testfall. Jede Umformulierung ist eine Gelegenheit, etwas falsch zu verstehen, und die Abweichung zeigt sich bei der Abnahme, wenn die Korrektur am teuersten ist. BDD schafft die Zwischenstufen ab, indem es alle vier Sichtweisen in einem einzigen Text unterbringt, der vom Fachbereich diktiert und vom Werkzeug ausgeführt wird. Dan North nennt diese gemeinsame Sprache den ersten Gewinn der Praxis, noch vor jeder Automatisierung.

Das Arbeitsergebnis ist ein Satz von Szenarien, der an einem Backlog-Item hängt und ergänzt wird, sobald das Team die Fälle findet, die der erste Durchgang ausgelassen hat. Die Agile Extension fasst die Absicht in drei Wirkungen zusammen: mehr Wert, weniger Verschwendung und eine direktere Kommunikation zwischen den Stakeholdern und dem Delivery-Team, erreicht dadurch, dass die Analyse auf das vom Kunden erwartete Verhalten ausgerichtet wird. Die Begriffe behaviour driven development, acceptance test driven development und specification by example werden gängig füreinander verwendet, ohne dass der Leitfaden die Grenze dazwischen zieht.

Einsatz

Wann einsetzen

• Iterative Lieferung: das erwartete Verhalten Element für Element festlegen, unmittelbar vor der Umsetzung.
• Fachbereich und Team ohne gemeinsames Vokabular: wo sich die Abweichung zwischen dem Erwarteten und dem Gelieferten wiederholt, schliesst das konkrete Beispiel die Deutung, die die allgemeine Aussage offenlässt.
• Zu automatisierende Abnahmetests: einmal geschrieben, liest sich das Szenario als Spezifikation und läuft als Test.
• Nachvollziehbarkeit gegenüber einem Revisor oder einer Aufsichtsbehörde: die ausgeführte Suite belegt, welches Verhalten geprüft wird und wann es geprüft wurde.
• Abzusteckender Lösungsentwurf: die Grammatik über einen bereits skizzierten Entwurf laufen zu lassen, hält die Diskussion an einem bestimmten Verhalten.

Wann nicht einsetzen

• Kombinatorische Geschäftsregeln: die Zahl der Szenarien explodiert und wird unüberschaubar; hier gehört eine Entscheidungstabelle hin.
• Bezifferte nichtfunktionale Anforderungen: ein Verhalten trägt weder Antwortzeit noch Mengengerüst; dafür werden gemessene Akzeptanzkriterien geschrieben.

Beschreibung

Die Praxis entstand im Anschluss an test driven development. Dan North baute 2003 ein Test-Framework, JBehave, das "Test" durch "Verhalten" ersetzte, weil die Teams, die er begleitete, immer an denselben Fragen hängen blieben: Was ist zu testen, wie weit und zu welchem Zeitpunkt. Zusammen mit Chris Matts formulierte er 2004 die Vorlage "Angenommen, wenn, dann" für die Anforderungsanalyse. Der Artikel von 2006, der die Praxis festhält, handelt daher zuerst von der Sprache: Der beanspruchte Gewinn ist ein Vokabular, das Analysten, Tester, Entwickler und der Fachbereich teilen.

Die drei Elemente

Die Beispiele sind erlebte Situationen, die von den Stakeholdern eingebracht werden. Der Product Owner liefert sie und klärt dabei sein eigenes Denken: Ein Sonderfall, den er für offensichtlich hielt, erweist sich als strittig, sobald das Ergebnis aufzuschreiben ist. Der Business Analyst moderiert diese Entdeckung und steht für die Vollständigkeit des Beispielsatzes ein, die sonst niemand überwacht. Nicht jedes Beispiel fällt in den Umfang des laufenden Inkrements.

Die Grammatik, Gherkin genannt, ist die Form, in die das Beispiel passen muss. Die Vorlage, die die Agile Extension übernimmt, ist bewusst karg, vier Schlüsselwörter, was sie ohne Einarbeitung lesbar und für eine Maschine auswertbar macht. Gherkin kennt einige weitere, darunter das Musterszenario mit seiner Wertetabelle (Scenario Outline und Examples), das die Varianten zusammenfasst, die sich nur in ihren Daten unterscheiden. Diese Kargheit ist zugleich eine Einschränkung für die Analyse: Ein Beispiel, das sich nicht in die Form fügt, ist das Zeichen eines noch unklaren Bedürfnisses oder eines Szenarios, das zwei enthält.

Die Ausführung schliesst den Kreis: Mehrere Produkte lesen Szenarien in diesem Format und binden sie an Testcode. Die Spezifikation wird damit zu einem Test, der fehlschlägt, sobald sich das Verhalten ändert; das ist der einzige Mechanismus, der von sich aus meldet, dass eine Dokumentation nicht mehr stimmt. Ohne diesen Schritt bleibt die Technik für das Gespräch nützlich und die Suite der Szenarien altert wie jedes andere Dokument.

Die Grammatik, Schlüsselwort für Schlüsselwort

Ein Szenario trägt einen Titel, der den behandelten Fall benennt, danach Zeilen, die von den vier Schlüsselwörtern der Vorlage eingeleitet werden. Die Regel mit der grössten Wirkung ist die des einzigen Auslösers: ein einziges WENN pro Szenario. Zwei Ereignisse in einem Szenario bedeuten zwei Szenarien, und wer sie verschmilzt, weiss nicht mehr, welches von beiden fehlgeschlagen ist. Ausgangsbedingungen und erwartete Ergebnisse lassen sich dagegen frei mit UND verketten.

Die Three-Amigos-Sitzung und die Was-wäre-wenn-Fragen

Die übliche Sitzung bringt drei Rollen zusammen, daher der Name Three Amigos: den Product Owner, der den Fall einbringt und entscheidet, was die Lösung zu tun hat; den Tester, der nach den Fällen sucht, die niemand bedacht hat; den Entwickler, der den Auslöser und die Daten hinterfragt, die das Szenario als vorhanden voraussetzt. Jeder sieht dasselbe Beispiel aus einem Blickwinkel, den die beiden anderen nicht haben, und die Uneinigkeit tritt in dem Moment auf, in dem sie sich mit einem Satz klären lässt.

Die Arbeit des Business Analysten in dieser Sitzung hat im Leitfaden einen Namen: die Was-wäre-wenn-Fragen und die Was-ist-mit-Fragen zu stellen, die die fehlenden Szenarien zutage bringen. Jede Frage betrifft eine Abwandlung einer ANGENOMMEN-Zeile. Was wäre, wenn der Saldo nicht reichte? Was wäre, wenn der Zahlungsempfänger noch nicht erfasst wäre? Was wäre, wenn die Transaktion auf einen kantonalen Feiertag fiele? Jede Antwort ist entweder ein weiteres Szenario oder eine Geschäftsregel, die niemand aufgeschrieben hatte. Hier trägt die Technik am meisten ein. Diese Fragen sind auch die ersten, die entfallen, wenn die Sitzung verkürzt wird.

Die Technik durchführen

1. Das Backlog-Item wählen und die drei Rollen zusammenbringen
   Eine Sitzung behandelt ein einziges Backlog-Item. Ohne den Product Owner erzeugt die Sitzung Annahmen; ohne den Tester erzeugt sie nur den Normalfall.
2. Den Fachbereich die Beispiele erzählen lassen
   Man verlangt erlebte Fälle mit ihren echten Werten. Ein letzte Woche bearbeitetes Dossier ist mehr wert als eine Verallgemeinerung.
3. Die Was-wäre-wenn-Fragen stellen
   Jede Abwandlung einer Ausgangsbedingung ist ein Kandidat für ein Szenario. Auch die Antworten, die ausserhalb des Umfangs des Inkrements liegen, werden festgehalten, ohne in Form gebracht zu werden.
4. In Form bringen
   Ein Titel, der den Fall benennt, ein einziges WENN, die Bedingungen und die Ergebnisse mit UND verkettet. Die Werte stehen ausgeschrieben im Text.
5. Die Abdeckung prüfen
   Der Satz enthält mindestens den Normalfall, die Ablehnungsfälle und die Grenzfälle, an denen eine Regel kippt. Ein Szenario, dessen Ergebnis sich nicht aus den genannten Bedingungen ableiten lässt, ist unvollständig.
6. Die Szenarien an das Backlog-Item hängen
   Sie werden zu dessen Akzeptanzkriterien und zur Grundlage für die Demo am Ende der Iteration.
7. Automatisieren und wiederholen
   Jedes Szenario wird an Testcode gebunden und bei jeder Integration erneut ausgeführt. Ein Szenario, das nie ausgeführt wird, ist nur noch ein Kommentar.
8. Aufräumen
   Bei jeder Regeländerung werden die betroffenen Szenarien umgeschrieben oder gelöscht. Eine Suite, die man wachsen lässt, wird unlesbar, bevor sie falsch wird.

Der Platz des Szenarios unter den Akzeptanzkriterien

Ein Szenario nach dem Muster Angenommen, Wenn, Dann ist ein Format von Akzeptanzkriterien unter anderen. Akzeptanz- und Bewertungskriterien behandeln die allgemeine Frage: Unter welchen Bedingungen wird eine Lösung angenommen und auf welchen Skalen werden mehrere Kandidaten verglichen. BDD ist die gemeinsame Praxis, die eines dieser Formate hervorbringt, dasjenige, das der Fachbereich lesen und ein Werkzeug ausführen kann. Ein Projekt schreibt seine Kriterien zu Verfügbarkeit, Kosten oder Konformität in anderen Formen und setzt das Szenario dort ein, wo ein Verhalten zu beurteilen ist.

Was die Technik scheitern lässt

Das Szenario im Vokabular der Bildschirmmaske

"Wenn ich auf der Registerkarte Zahlungen auf die Schaltfläche Bestätigen klicke" beschreibt eine Oberfläche dort, wo das Szenario ein Verhalten beschreiben muss. Das Szenario bricht bei der ersten Überarbeitung der Oberfläche, obwohl die Geschäftsregel unverändert geblieben ist, und der Fachbereich liest es nicht mehr nach, weil er sein Geschäft darin nicht wiedererkennt. Geschrieben wird die Handlung, "wenn ich die Überweisung bestätige", und der technischen Schicht wird überlassen, wo die Schaltfläche liegt.

Das fehlende Szenario

Das ist die Grenze, die der Leitfaden zuerst nennt: Ohne jemanden, der die Was-wäre-wenn-Fragen stellt, fallen Fälle unter den Tisch. Die Suite läuft vollständig durch, obwohl sie unvollständig ist, was gefährlicher ist als gar keine Tests, weil sie beruhigt.

Die ausufernde Suite

Wenn die Geschäftsregeln kombinatorisch sind, vermehren sich die Szenarien schneller, als man ihnen folgen kann, bis zu einer Suite, deren Inhalt niemand mehr kennt und die niemand mehr anzurühren wagt. Wertevarianten gehören in ein Musterszenario und seine Tabelle. Regelkombinationen werden in einer Entscheidungstabelle behandelt, und BDD behält die wenigen Szenarien, die das Gesamtverhalten zeigen.

Das nach dem Code geschriebene Szenario

Das Szenario beschreibt dann das Verhalten, das der Code ohnehin schon erzeugt. Es besteht immer und es gibt dem Projekt die Illusion einer Abdeckung.

Gherkin ohne das Gespräch

Ein Team, das seine Szenarien allein verfasst, erhält korrekt geformte Dateien und dazu genau den Mangel, den die Technik beseitigen soll: eine Spezifikation, die ohne den Fachbereich geschrieben wurde. Die Grammatik ist nur so viel wert wie die Sitzung, die sie füllt.

KI-Überlegungen

Bei dieser Technik leistet ein Sprachmodell vier Dienste. Es erzeugt aus einem Backlog-Item und dessen Geschäftsregeln eine Liste von Was-wäre-wenn-Fragen, an der sich die Sitzung messen lässt. Es bringt in Form: Man gibt ihm das Protokoll oder die Mitschrift der Sitzung und es zieht daraus strukturierte Szenarien, die die Sitzung korrigiert. Es findet Dubletten und Überschneidungen in einer Suite, die zum Nachlesen zu gross geworden ist. Es gleicht die drei Sprachen ab für ein Team, das auf Französisch, Deutsch und Englisch arbeitet, da die Grammatik karg genug ist, um die Übersetzung zu überstehen.

Die Grenzen ergeben sich daraus, was ein Beispiel ist. Das Beispiel gehört dem Fachbereich: Es ist ein Fall, der in dieser Organisation eingetreten ist, mit ihren Beträgen, ihren Schwellen und ihren hauseigenen Ausnahmen. Ein Modell, das zur Produktion solcher Beispiele aufgefordert wird, erfindet eine Überweisungslimite, eine Widerrufsfrist oder einen Betrag in CHF, die richtig aussehen und keiner Regel des Hauses entsprechen. Das falsche Szenario wird ebenso getreu automatisiert wie ein richtiges. Ein erzeugtes Szenario, das niemand bespricht, wiederholt den Mangel von Gherkin ohne Gespräch. Schwellen, an denen Geld oder Konformität hängen, werden gegen die geschriebene Regel geprüft. Schliesslich enthalten echte Beispiele Personendaten, Kundennamen, AHV-Nummern, IBAN, Beträge: Sie werden anonymisiert, bevor irgendetwas an ein öffentliches Modell geht.

Beispiele

Eine Schweizer Retailbank ergänzt ihr E-Banking um eine tägliche Überweisungslimite. Die Sitzung bringt zwei Szenarien hervor: dasjenige, das durchgeht, und dasjenige, das die Limite stoppt.

Das ist die übliche Gestalt eines brauchbaren Satzes von Szenarien: eng um eine kippende Bedingung geführte Varianten. Der Leser findet das Ergebnis durch Rechnen, CHF 5'000 Limite abzüglich CHF 4'000 bereits genutzt ergeben CHF 1'000, womit eine Überweisung von CHF 1'200 abgelehnt wird. Ein einziges Szenario hätte gezwungen, das Kippen als allgemeine Regel zu formulieren, also das Beispiel zugunsten der Abstraktion zu verlassen, die die Technik gerade vermeiden will.

Die Sitzung hat mehr hervorgebracht als diese beiden Texte. Der dritte aufgeworfene Fall, "was wäre, wenn die Überweisung in Fremdwährung erfolgte", brachte eine Regel zum Vorschein, die niemand aufgeschrieben hatte: Die Tageslimite bemisst sich am Gegenwert in Franken, zum Tageskurs. Die Regel ist in die Produktdokumentation eingegangen und wartet auf ihr eigenes Szenario. Der Entwickler fragte, was mit der Limite um Mitternacht geschieht: Sie wird beim Tagesabschluss der Bank zurückgesetzt, was eine ANGENOMMEN-Zeile ergänzen wird, sobald dieser Fall geschrieben wird. Ein letzter Kandidat, die telefonisch beim Kundenberater erhöhte Limite, liegt ausserhalb des Umfangs des Inkrements: Er ist im Backlog erfasst und bleibt ohne Ausformulierung, mangels eines Verhaltens, das diesmal zu liefern wäre.

Visualisierungen

Die Technik erzeugt strukturierten Text, Zeilen und Schlüsselwörter, also sind beide Artefakte Tabellen: das Raster der vier Schlüsselwörter mit ihrer Entsprechung im Unit-Test und der Satz von Szenarien aus dem vorangehenden Abschnitt, der das Arbeitsergebnis ist. Zwei Gedanken verlangen dagegen eine Zeichnung. Der erste ist die dreifache Verwendung desselben Textes, ein Beispiel, das zu einem Szenario wird, von dem drei Pfeile ausgehen, zur vom Fachbereich gelesenen Dokumentation, zum am Backlog-Item hängenden Akzeptanzkriterium und zum bei jeder Integration wiederholten Test. Der zweite ist die Sitzung mit drei Rollen, mit der je eigenen Frage jeder Rolle und den Was-wäre-wenn-Fragen, die die fehlenden Szenarien hervorbringen.

Aufwand

Werkzeuge

Der Ausgangspunkt ist ein Whiteboard oder ein während der Sitzung geteiltes Textdokument. Ein Szenario ist kurzer Text und die Vorlage kommt mit vier Wörtern aus: Die nützliche Auflage ist, es für alle sichtbar zu machen.

Werkzeuge zur Backlog-Verwaltung (Jira, Azure DevOps, GitLab und ihre Entsprechungen) führen die Szenarien als Akzeptanzkriterien des Elements, an dem sie hängen. Das ist der günstigste Ort, solange die Automatisierung noch nicht im Spiel ist, denn das Szenario folgt dem Element in die Priorisierung und in die Demo am Ende der Iteration.

Werkzeuge für die Spezifikation durch Beispiele (Cucumber, SpecFlow, Behat, JBehave und ihre Entsprechungen) lesen Szenariendateien und binden sie an Testcode. Sie liefern auch die Kennzahlen, die das blosse Schreiben nicht hergibt: welche Szenarien abgedeckt sind, welche fehlschlagen, welche Anforderungen ohne Szenario bleiben. Ihre Syntaxkonventionen unterscheiden sich, und man wählt jenes, das die Sprache der Plattform des Teams spricht.

Zwei Ergänzungen zählen so viel wie das Testwerkzeug. Die Versionsverwaltung hält die Szenariendateien beim Code, den sie spezifizieren, sodass eine Verhaltensänderung und ihre Spezifikation im selben Commit liegen. Die Continuous-Integration-Pipeline spielt die Suite bei jeder Codelieferung erneut ab und lässt ein falsch gewordenes Szenario auffallen, bevor ein Leser sich darauf verlässt.

Quellen

• IIBA, Agile Extension to the BABOK Guide, §7.2 Behaviour Driven Development: die Einordnung für den Business Analysten, die drei Elemente (Beispiele, Gherkin-Grammatik, Ausführung), die Regel des einzigen WENN, die Three-Amigos-Sitzung, die Verwendung des Szenarios als Akzeptanzkriterium einer Story und die genannten Grenzen, fehlendes Szenario mangels Was-wäre-wenn-Fragen, kombinatorische Explosion und Unterhalt der Suite.
• Dan North, Introducing BDD, Better Software, März 2006: die Quelle der Technik. Der Wechsel vom Vokabular des Testens zu jenem des Verhaltens, die mit Chris Matts für die Anforderungsanalyse formulierte Vorlage "Angenommen, wenn, dann" und die von Analysten, Testern, Entwicklern und dem Fachbereich geteilte Sprache.
• Agile Alliance, What is BDD (Behavior Driven Development)?: die Zuschreibung der Technik an Dan North und Chris Matts und die Einordnung von BDD unter die Praktiken test driven development und acceptance test driven development.