Warum sollten wir BDD also nicht \u00fcberall einsetzen? Oder anders gefragt: Passt BDD in jeden Projekt-Alltag?<\/p>\n
Die grundlegende Idee von BDD<\/h2>\n
BDD ist ein Entwicklungs<\/strong>prozess, der sich auf vier Schritte zur\u00fcckf\u00fchren l\u00e4sst:<\/p>\n Im Kern handelt es sich also um einen Test-Driven-Ansatz, der an den Anfang des Entwicklungsprozesses formalisierte Anforderungen setzt.<\/p>\n In der Praxis k\u00f6nnen Lifecycle-Management-Systeme verwendet werden, in denen die Szenarien sowohl f\u00fcr manuelle als auch automatisierte Testf\u00e4lle ausf\u00fchrbar sind. So k\u00f6nnen bspw. mit opentext ALM Octane<\/a> oder in Jira mittels XRAY<\/a> die Szenarien als Testf\u00e4lle direkt in der Gherkin-Syntax erfasst werden.<\/p>\n Diese (formalisierten) Anforderungen bilden eine verbindende Einheit \u2013 von Business-, Entwicklung-, QA bis hin zu Infrastruktur-Teams. Jedes Team bringt dabei seine Sichtweisen ein und erarbeitet somit eine gemeinsame Datenbasis.<\/p>\n BDD setzt also ein hochwertiges Requirement Engineering sowie ein funktions\u00fcbergreifendes Team voraus.<\/strong><\/p>\n In der Praxis sind hingegen immer wieder andere Konstellationen anzutreffen:<\/p>\n Hier f\u00e4llt es schwer, eine allgemeine Aussage \u00fcber den sinnvollen Einsatz von BDD zu treffen.<\/p>\n Wer BDD leben m\u00f6chte, sollte sich deshalb bewusst die folgenden Fragen stellen:<\/p>\n Wenn man sich g\u00e4ngige Tutorials zum Thema BDD anschaut, kann man schnell den Eindruck erhalten, dass Gherkin eine einfach einzusetzende Sprache ist.<\/p>\n Ist sie auch \u2013 wenn man ein paar Spielregeln beachtet:<\/p>\n 1. Jede Anforderung, jedes Szenario, ist Testautomatisierungs-Quellcode.<\/strong><\/p>\n 2. Jede Anforderung, jedes Szenario, beschreibt erwartetes Verhalten.<\/strong><\/p>\n 3. Jede Anforderung, jedes Szenario, muss (kontinuierlich) testbar sein.<\/strong><\/p>\n BDD ersetzt kein Testautomatisierungs-Framework, sondern erg\u00e4nzt eine weitere Schicht.<\/strong><\/p>\n Im Akzeptanztest werden i.a.R. umfassende Workflows abgetestet. Die Testf\u00e4lle umfassen oftmals viele Einzelschritte, die schon f\u00fcr sich genommen aufw\u00e4ndig zu automatisieren sind. Auch ohne BDD ist diese Testebene der aufw\u00e4ndigste Prozessschritt im Rahmen einer Produkt-Entwicklung. Hei\u00dft dies im Umkehrschluss, in dieser Ebene auf BDD zu verzichten?<\/p>\n Wie so oft hilft es, einen Blick auf den gesamten Testprozess zu richten. Wenn es gelingt, jeden einzelnen Prozessschritt automatisiert zu testen, wie gro\u00df ist das verbliebene Risiko im Gesamt-Prozess?<\/p>\n Der Fokus auf die Prozessschritte hilft dabei in mehrfacher Hinsicht:<\/p>\n Der \u201eAkzeptanztest\u201c kann deshalb stark fokussiert erfolgen. Explorative Tests oder A\/B-Tests mit ausgew\u00e4hlten Nutzergruppen sind hier oftmals kosteng\u00fcnstiger und decken das gleiche Risiko ab als der Versuch, eine vollst\u00e4ndige Testautomatisierung mit BDD umzusetzen.<\/p>\n Eine allgemeine Antwort, ob BDD f\u00fcr einen Akzeptanztest sinnvoll ist, ist letztlich nur im konkreten Projekt-Kontext m\u00f6glich.<\/strong><\/p>\n BDD verbindet alle Fachbereiche auf Basis einheitlicher, formalisierter Anforderungen.<\/p>\n Die Verwendung von BDD ist kein Selbstl\u00e4ufer und bedarf sorgf\u00e4ltiger Planung im Projekt. Nur weil die Syntax modern und einfach wirkt, bedarf es trotzdem kontinuierlicher Anstrengungen, diese Ebene in der Testautomatisierung sinnvoll einzusetzen.<\/p>\n\n
![\"Test-Driven-Ansatz](\"https:\/\/www.proficom.de\/blog\/app\/uploads\/2023\/09\/Test-Driven-Ansatz.png\")
<\/figure>\nAnforderungen als verbindendes Element<\/h2>\n
![\"Requirement](\"https:\/\/www.proficom.de\/blog\/app\/uploads\/2023\/09\/Requirement-Engineering-Team_BDD.png\")
<\/figure>\n\n
\n
BDD und Testautomatisierung<\/h2>\n
\n
\n
\n
\n
![\"Testautomatisierungsframework](\"https:\/\/www.proficom.de\/blog\/app\/uploads\/2023\/09\/Testautomatisierungsframework_BDD.png\")
<\/figure>\nBDD und Akzeptanztests<\/h2>\n
\n
Zusammenfassung<\/h2>\n
![\"Software](\"https:\/\/www.proficom.de\/blog\/app\/uploads\/2023\/09\/software_testing_podcast_andreas_doering-1024x1024-1.jpg\")
<\/figure>\n<\/p><\/div>\n