Behavior Driven Development (BDD)
Behavior Driven Development (BDD) ist ein Entwicklungsansatz, der die Zusammenarbeit zwischen Entwicklern, Testern und Fachleuten fördert.
Klassifikation
- KomplexitätMittel
- AuswirkungTechnisch
- EntscheidungstypDesign
- OrganisationsreifeFortgeschritten
Technischer Kontext
Prinzipien & Ziele
Use Cases & Szenarien
Kompromisse
- Falsche Interpretation von Anforderungen.
- Unzureichende Tests.
- Mangelnde Akzeptanz im Team.
- Dokumentation aller Szenarien.
- Regelmäßige Überprüfung von Tests.
- Nutzung von klar definierten Vorgaben.
I/O & Ressourcen
- Benutzergeschichten
- Akzeptanzkriterien
- Spezifikationsdokumente
- Funktionierende Software
- Vollständige Testsuite
- Dokumentierte Anforderungen
Beschreibung
BDD fördert die Definition von Softwareverhalten in natürlichen Sprache, was zur besseren Kommunikation und zum Verständnis beiträgt. Die Verwendung von Tests, die sowohl für Fachleute als auch für technische Mitarbeiter verständlich sind, verbessert die Qualität und reduziert Missverständnisse.
✔Vorteile
- Verbesserte Softwarequalität.
- Weniger Missverständnisse.
- Förderung der Zusammenarbeit.
✖Limitationen
- Abhängigkeit von Fachkenntnissen.
- Mögliche Überkomplexität.
- Nicht geeignet für alle Projekte.
Trade-offs
Metriken
- Defektquote
Anzahl der Defekte pro getestete Funktion.
- Testabdeckung
Prozentualer Anteil der getesteten Anforderungen.
- Bereitstellungsfrequenz
Häufigkeit der Bereitstellung von Softwareänderungen.
Beispiele & Implementierungen
Online-Shop
Ein Online-Shop, der BDD zur Definition seiner Checkout-Pipeline verwendet.
Soziale Netzwerk App
Eine App, die BDD nutzt, um Anforderungen klar zu formulieren und Benutzerfeedback zu integrieren.
Finanzsoftware
Eine Softwarelösung, die BDD anwendet, um Sicherheitsanforderungen zu erfüllen.
Implementierungsschritte
Einführungsworkshop organisieren.
Team in BDD schulen.
Szenarien gemeinsam entwickeln.
⚠️ Technische Schulden & Engpässe
Tech Debt
- Unzureichende Testautomatisierung.
- Unbehandelte technische Schulden.
- Fehlende Dokumentation.
Bekannte Engpässe
Beispiele für Missbrauch
- Übermäßige Komplexität in Tests.
- Defekte ignorieren.
- Fokus auf zu viele Szenarien.
Typische Fallen
- Schlechte Kommunikation im Team.
- Übersehen von Akzeptanzkriterien.
- Verwirrung durch technische Terminologie.
Erforderliche Fähigkeiten
Drivers (Architectural Drivers)
Constraints
- • Mangelnde Ressourcen.
- • Technische Schulden.
- • Zeitdruck.