Test-Driven Development (TDD) und Behavior-Driven Development (BDD) sind Test-First-Praktiken und zentrale Elemente des Built-In-Quality-Prinzips im SAFe.
TDD ist eine Entwicklungstechnik, bei der Entwickler:innen zuerst einen fehlschlagenden Test schreiben, bevor sie die entsprechende Funktionalität implementieren. So wird sichergestellt, dass Code immer anhand klarer, überprüfbarer Kriterien entsteht.
BDD erweitert TDD, indem das Verhalten eines Systems in einer für Business und Technik gleichermaßen verständlichen Sprache beschrieben wird. So entsteht eine gemeinsame Basis für Entwickler:innen, Tester:innen und Business-Stakeholder.
Beide Praktiken sorgen dafür, dass Anforderungen früh validiert werden, Software wartbar bleibt und Inkremente konsistent den Kundenerwartungen entsprechen.
TDD im Detail
- Zyklus („Red–Green–Refactor“):
- Einen fehlschlagenden Test für die nächste Funktionalität schreiben.
- Minimalen Code implementieren, bis der Test erfolgreich ist.
- Code refaktorieren, um Lesbarkeit und Struktur zu verbessern, ohne das Verhalten zu ändern.
- Fokus: Interne Codequalität (sauberes Design, Modularität, Testbarkeit).
- SAFe-Bezug: TDD unterstützt Continuous Integration, da jeder Commit bereits durch Unit-Tests abgesichert ist.
BDD im Detail
- Zyklus („Given–When–Then“):
- Gegeben ein bestimmter Kontext (Vorbedingungen).
- Wenn eine Aktion ausgeführt wird.
- Dann tritt das erwartete Ergebnis ein.
- Fokus: Externes Verhalten des Systems in einer gemeinsamen Sprache, die Business und Technik verbindet.
- SAFe-Bezug: BDD liefert ausführbare Akzeptanzkriterien für Features und Stories und hilft Teams wie Product Ownern, ein einheitliches Verständnis von „Done“ zu entwickeln.
Best Practices
Für TDD:
- Tests klein, schnell und isoliert halten.
- Lesbarkeit und Wartbarkeit der Tests priorisieren.
- Refactoring konsequent durchführen, um technische Schulden zu vermeiden.
- TDD in CI-Pipelines einbinden, um Regressionen zu verhindern.
Für BDD:
- Product Owner, Business-Analyst:innen und Tester:innen in die Formulierung von Szenarien einbeziehen.
- Tools wie Cucumber oder SpecFlow nutzen, um Szenarien direkt ausführbar zu machen.
- Szenarien auf Geschäftswert fokussieren, nicht auf technische Details.
- Szenarien als lebende Dokumentation pflegen.
Beispiele
TDD in der Praxis (Automotive): Eine Entwickler:in für ein Steuergerät schreibt einen fehlschlagenden Test für einen Spezialfall im Bremsalgorithmus. Erst dann wird der Algorithmus implementiert – mit der Sicherheit, dass das Verhalten auch in kritischen Situationen konsistent ist.
BDD in der Praxis (E-Commerce): Ein Team beschreibt Akzeptanzkriterien für eine Warenkorb-Funktion:
- Gegeben ein leerer Warenkorb,
- Wenn ein Kunde ein Produkt hinzufügt,
- Dann zeigt der Warenkorb das Produkt und den aktualisierten Preis an.
Dieses Szenario ist automatisiert ausführbar und stellt sicher, dass Business-Anforderungen und technische Umsetzung deckungsgleich sind.
Im SAFe-System-Demo: Teams, die BDD nutzen, zeigen Features, deren Akzeptanztests auf Business-Szenarien beruhen – Missverständnisse mit Stakeholdern werden minimiert.
Typische Herausforderungen
- TDD: Der Refactoring-Schritt wird ausgelassen, wodurch fragile Test-Suites entstehen. Unter Zeitdruck neigen Teams dazu, TDD zu überspringen.
- BDD: Unklare oder zu technische Szenarien führen zu Redundanz oder mangelnder Aussagekraft. Wenn Product Owner nicht eingebunden sind, geht der Business-Bezug verloren.
- Im Skalierungsumfeld: Unterschiedliche Testpraktiken zwischen Teams erschweren die Integration auf ART-Ebene.
CALADE Perspektive
CALADE integriert TDD- und BDD-Coaching in Transformationsprogramme und stellt sicher, dass diese Methoden nicht als isolierte Techniken, sondern als Kulturpraktiken für Built-In Quality verstanden werden. Durch die Kombination von Developer Enablement (TDD) und Business-Kollaboration (BDD) unterstützen wir ARTs und Portfolios dabei, test-first zum Rückgrat ihrer Continuous Delivery Pipeline zu machen.
Verwandte Begriffe
- Built-In Quality
- Continuous Integration
- Akzeptanzkriterien
- Definition of Done
- Testautomatisierung
- Enabler Stories
← zurück zur Übersicht