In dieser Folge stellt Pascal Moll Behaviour Driven Development (BDD) vor, einen Weg im Team gemeinsam das gewünschte Verhalten einer Software zu definieren und diese Definition zur Grundlage der Abnahme zu machen, auch für eine automatisierte Abnahme.
Podcast #1: Behaviour Driven Development - Testautomatisierung, Testing
Diese Themen erwarten Dich:
[00:48] Kurzer Überblick über den Podcast
[01:14] Vorstellung Pascal Moll
[01:48] Was bedeutet Behaviour Driven Development(BDD) ?
[02:22] Ist Cucumber ein Synonym für BDD ?
[02:50] Unterschiede TDD BDD
[04:02] Ungenaue Spezifikationen und BDD
[04:54] Wie anfangen mit BDD?
[05:57] Unterschiede zu User Stories
[06:52] Szenarien und Fachbereiche
[07:45] BDD ins Team bringen
[08:59] BDD als ausführbare Spezifikation
[10:06] Granularität von Szenarien
[11:14] Einsatz von Gegeben, Wenn, Dann (Given, When, Then)
[12:18] Granularität von Steps
[13:28] Der optimale Weg zur Nutzung von BDD
[14:17] Auslagerung von gemeinsam genutzten Schritten
[14:40] Testautomatisierung und BDD
[16:10] Vorteile von BDD
[16:58] Von neuen Features zur Testautomatisierung
[17:45] Unterschied zu Keyword Driven
[18:36] Ablauf Seminar BDD Cucumber
Einleitung in die Welt des Behaviour Driven Development
In dieser Podcast-Episode hatten wir das Vergnügen, mit Pascal Moll tief in das Thema Behaviour Driven Development (BDD) einzutauchen. Als jemand, der seit über 20 Jahren in der IT-Branche tätig ist, brachte Pascal eine Fülle von Wissen und Erfahrungen mit sich. BDD steht im Zentrum unseres Gesprächs - ein Thema, das in der heutigen schnelllebigen Entwicklungslandschaft immer relevanter wird. Pascal teilte seine Einsichten darüber, wie BDD Teams helfen kann, eine gemeinsame Sprache zu finden und Missverständnisse zwischen technischen und nicht-technischen Stakeholdern aus dem Weg zu räumen. Sein Ansatz beleuchtet die Bedeutung eines klaren Kommunikationskanals innerhalb des Teams und wie BDD dazu beitragen kann, genau diesen zu etablieren.
Die Grundlagen von BDD verstehen
Pascal erklärte uns die Grundlagen von BDD und hob hervor, dass es sich dabei um viel mehr als nur eine Testmethodik handelt. Es geht darum, Entwicklung und Anforderungen durch eine gemeinsame Sprache - oft realisiert durch die Gherkin-Syntax - miteinander zu verknüpfen. Diese Syntax ermöglicht es, Szenarien in einer Art und Weise zu beschreiben, die sowohl für Fachexperten als auch für Entwickler verständlich ist. Das 'Gegeben-Wenn-Dann'-Konzept spielt dabei eine zentrale Rolle. Es hilft Teams nicht nur bei der Spezifikation von Anforderungen, sondern fördert auch ein tieferes Verständnis des Endziels jedes Features oder jeder Funktion.
BDD vs. TDD: Ein detaillierter Vergleich
Ein interessanter Teil unseres Gesprächs drehte sich um den Vergleich zwischen BDD und Test-Driven Development (TDD). Markus wies darauf hin, dass TDD einen eher technisch orientierten Ansatz verfolgt, bei dem Tests vor dem eigentlichen Code geschrieben werden. BDD hingegen legt einen stärkeren Fokus auf Kommunikation und Zusammenarbeit im Team. Diese Methode ermöglicht es, bereits im Vorfeld Klarheit über die Anforderungen und Erwartungen zu schaffen. Durch den Einsatz von Szenarien können Teams effektiver zusammenarbeiten und sicherstellen, dass alle auf dem gleichen Stand sind. Diese Praxis fördert nicht nur die Qualität der Endprodukte, sondern spart letztendlich auch Zeit und Ressourcen.
Wie man ein Team für BDD begeistert
Pascal teilte wertvolle Einblicke darüber, wie man ein Team für BDD gewinnen kann. Der Trick liegt darin, den Mehrwert klar zu kommunizieren - insbesondere wie BDD dazu beiträgt, Missverständnisse auszuräumen und eine effizientere Arbeitsweise zu fördern. Workshops können hierbei ein wirkungsvolles Mittel sein, um sowohl technische als auch nicht-technische Teammitglieder an einen Tisch zu bringen. Durch praktische Übungen erleben Teilnehmer hautnah die Vorteile einer solchen Herangehensweise. Solche Maßnahmen tragen maßgeblich dazu bei, die Akzeptanz im Team zu erhöhen.
Schritte zur Implementierung von BDD
Der Weg zur Implementierung von BDD in einem Team kann zunächst herausfordernd erscheinen. Pascal betonte jedoch, dass dieser Prozess Schritt für Schritt angegangen werden sollte. Beginnen sollte man mit der Definition klarer Szenarien und der Einführung der Gherkin-Syntax. Von dort aus kann das Team dann beginnen, diese Szenarien in automatisierte Tests umzuwandeln. Wichtig ist hierbei vor allem eines: Die kontinuierliche Zusammenarbeit zwischen Fachbereich und Entwicklern muss gewährleistet sein. Nur so kann sichergestellt werden, dass alle Aspekte eines Features vollständig verstanden und korrekt umgesetzt werden.
Abschlussgedanken: Warum BDD einen Unterschied macht
Zum Abschluss unserer Diskussion reflektierten wir über den wesentlichen Nutzen von BDD für Softwareentwicklungsteams. Pascal unterstrich noch einmal die Bedeutung der gemeinsamen Sprache sowie die verbesserte Kommunikation innerhalb des Teams als Hauptvorteile dieser Methodik. Darüber hinaus hilft BDD dabei, Entwicklungsprozesse transparenter zu gestalten und trägt somit zur Steigerung der allgemeinen Produktqualität bei. Unsere Konversation mit Pascal war äußerst aufschlussreich; sie zeigte deutlich auf, wie essentiell gute Kommunikation in agilen Entwicklungsprozessen ist.
Tauchen Sie tiefer in die Welt des Behaviour Driven Development ein und entdecken Sie seine transformative Kraft für Ihr Team – hören Sie jetzt in unsere Podcast-Episode rein.
Veröffentlicht am 11.Februar 2022
Aktualisiert am 28.Mai 2024
Senior Testmanager, Testarchitekt
Markus Thaler war 22 Jahre in der Commerzbank tätig, wo er sich mehr als 10Jahre um Teststandards, Testwerkzeuge und Testautomatisierung in einer zentralen Funktiongekümmert hat, bevor er nach einer Zwischenstation im Testinfrastrukturmanagement achtJahre als Testmanager in der Risikofunktion der Commerzbank gewirkt hat. Vor derCommerzbank konnte er Testerfahrungen bei Lufthansa, Siemens, Nestle und der DZ-Bankgewinnen. Aktuell ist er als Senior Testmanager und Testarchitekt bei Qytera tätig.