Akzeptanztests mit BDD – Ist das sinnvoll?

Immer wieder werden wir gefragt, wie der Einsatz von BDD zu bewerten sei. Auf den ersten Blick sprechen viele Gründe für Behavior Driven Development:

• Es entstehen lesbare Testfälle.
• Damit geht eine hohe Nachvollziehbarkeit und Transparenz der Testfälle einher.
• Es gibt eine „Single Source Of Truth“ für die umzusetzenden Anforderungen.

Warum sollten wir BDD also nicht überall einsetzen? Oder anders gefragt: Passt BDD in jeden Projekt-Alltag?

Die grundlegende Idee von BDD

BDD ist ein Entwicklungsprozess, der sich auf vier Schritte zurückführen lässt:

1. Bevor ein neues Feature in eine Software integriert wird, werden die Anforderungen geklärt. Hierfür kommt eine formalisierte Syntax zum Einsatz, bspw. Gherkin (Given-When-Then-Format) oder Markdown.
2. Sobald die Implementierung startet, werden die (formalisierten) Anforderungen in die Testautomatisierung übernommen. Die Tests werden zu Beginn FAILED sein, weil sie ein Verhalten beschreiben, das noch nicht in der Software implementiert ist.
3. Anschließend wird die Funktionalität und parallel die Testautomatisierung implementiert. Die Testfälle werden in dieser Phase kontinuierlich ausgeführt.
4. Am Ende dieses Zyklus werden die Anforderungen erfolgreich getestet sein.

Im Kern handelt es sich also um einen Test-Driven-Ansatz, der an den Anfang des Entwicklungsprozesses formalisierte Anforderungen setzt.

In der Praxis können Lifecycle-Management-Systeme verwendet werden, in denen die Szenarien sowohl für manuelle als auch automatisierte Testfälle ausführbar sind. So können bspw. mit opentext ALM Octane oder in Jira mittels XRAY die Szenarien als Testfälle direkt in der Gherkin-Syntax erfassen.

Anforderungen als verbindendes Element

Diese (formalisierten) Anforderungen bilden eine verbindende Einheit – von Business-, Entwicklung-, QA bis hin zu Infrastruktur-Teams. Jedes Team bringt dabei seine Sichtweisen ein und erarbeitet somit eine gemeinsame Datenbasis.

BDD setzt also ein hochwertiges Requirement Engineering sowie ein funktionsübergreifendes Team voraus.

In der Praxis sind hingegen immer wieder andere Konstellationen anzutreffen:

• DEV- und QA-Teams sind organisatorisch getrennt und werden auch im Projekt nachgelagert involviert.
• Anforderungen werden von separaten Business-Analysten formuliert, oft in Freitext und in Tools, die für QA- oder Infrastruktur-Teams nicht zugreifbar sind.

Hier fällt es schwer, eine allgemeine Aussage über den sinnvollen Einsatz von BDD zu treffen.

Wer BDD leben möchte, sollte sich deshalb bewusst die folgenden Fragen stellen:

1. Gibt es ein abteilungsübergreifendes Entwicklungsteam?
2. Ist es gerechtfertigt, ausschließlich für die Testautomatisierung noch einmal formalisierte Anforderungen zusammenzutragen?

BDD und Testautomatisierung

Wenn man sich gängige Tutorials zum Thema BDD anschaut, kann man schnell den Eindruck erhalten, dass Gherkin eine einfach einzusetzende Sprache ist.

Ist sie auch – wenn man ein paar Spielregeln beachtet:

1. Jede Anforderung, jedes Szenario, ist Testautomatisierungs-Quellcode.

• Es sollten die bekannten CleanCode-Prinzipien gelten, z.B. „Don’t Repeat Yourself“ oder „Keep it simple stupid“.
• Jede Anforderung sollte dabei typischerweise 5-7 Zeilen umfassen – nicht mehr!
• In regelmäßigen Abständen sollte ein Review und Refactoring der Szenarien durchgeführt werden.#

2. Jede Anforderung, jedes Szenario, beschreibt erwartetes Verhalten.

• UI-Designs oder UX-Design gehören in separate Dokumente, nicht in die Szenarien.
• Stattdessen sollte der Workflow aller Artefakte beschrieben sein:
  • Was ist der Ausgangszustand?
  • Was passiert mit ihnen?
  • Wie sehen die Artefakte am Ende jedes Prozessschrittes aus?

3. Jede Anforderung, jedes Szenario, muss (kontinuierlich) testbar sein.

• BDD löst keine strukturellen Probleme in der Testautomatisierung.
• Testdaten oder Test-Cluster müssen bereitstehen und über CI-Server angesteuert werden können.
• Im Frontend müssen stabil erkennbare Objekte existieren, APIs eine entsprechende Konstanz aufweisen.

BDD ersetzt kein Testautomatisierungs-Framework, sondern ergänzt eine weitere Schicht.

BDD und Akzeptanztests

Im Akzeptanztest werden i.a.R. umfassende Workflows abgetestet. Die Testfälle umfassen oftmals viele Einzelschritte, die schon für sich genommen aufwändig zu automatisieren sind. Auch ohne BDD ist diese Testebene der aufwändigste Prozessschritt im Rahmen einer Produkt-Entwicklung. Heißt dies im Umkehrschluss, in dieser Ebene auf BDD zu verzichten?

Wie so oft hilft es, einen Blick auf den gesamten Testprozess zu richten. Wenn es gelingt, jeden einzelnen Prozessschritt automatisiert zu testen, wie groß ist das verbliebene Risiko im Gesamt-Prozess?

Der Fokus auf die Prozessschritte hilft dabei in mehrfacher Hinsicht:

• Für jeden Schritt können passende Testdaten bereitgestellt werden, um auch besondere Konstellationen zu testen.
• In jedem Schritt können Ausnahme-Situationen (Verbindungsabbrüche, Programmabstürze, …) deutlich einfacher simuliert werden.
• Wenn einzelne Prozessschritte verändert werden, betrifft dies nur eine Untermenge aller Tests. Es ist also nicht nötig, im Zweifelsfall alle Tests anzupassen.

Der „Akzeptanztest“ kann deshalb stark fokussiert erfolgen. Explorative Tests oder A/B-Tests mit ausgewählten Nutzergruppen sind hier oftmals kostengünstiger und decken das gleiche Risiko ab als der Versuch, eine vollständige Testautomatisierung mit BDD umzusetzen.

Eine allgemeine Antwort, ob BDD für einen Akzeptanztest sinnvoll ist, ist letztlich nur im konkreten Projekt-Kontext möglich.

Zusammenfassung

BDD verbindet alle Fachbereiche auf Basis einheitlicher, formalisierter Anforderungen.

Die Verwendung von BDD ist kein Selbstläufer und bedarf sorgfältiger Planung im Projekt. Nur weil die Syntax modern und einfach wirkt, bedarf es trotzdem kontinuierlicher Anstrengungen, diese Ebene in der Testautomatisierung sinnvoll einzusetzen.

Podcastempfehlung