Acceptance Test-Driven Development (ATDD) ist eine agile Entwicklungspraktik, bei der Akzeptanztests vor der eigentlichen Implementierung definiert werden. Diese Tests beschreiben Anforderungen anhand konkreter Beispiele und werden gemeinsam von Business, Entwicklung und Test erarbeitet. Im Gegensatz zu Test-Driven Development (TDD) liegt der Fokus nicht auf Unit-Tests, sondern auf dem fachlichen Verhalten aus Anwendersicht.
Ursprung und Zweck
ATDD entstand in den 2000er-Jahren aus den Praktiken von Extreme Programming (XP), TDD und den Konzepten von Specification by Example (Gojko Adzic). Ziel war es, ein gemeinsames Verständnis von Anforderungen zwischen allen Beteiligten herzustellen und so Fehlinterpretationen zu vermeiden.
Im SAFe-Framework ist ATDD Teil der Built-in Quality-Praktiken und eng mit BDD (Behavior-Driven Development) gekoppelt: Während BDD die Szenarien in verständlicher Sprache beschreibt, stellt ATDD die formalen Abnahmekriterien sicher.
Kernelemente
- Akzeptanzkriterien zuerst: Bereits vor der Entwicklung wird definiert, wann eine User Story oder ein Feature als „fertig“ gilt.
- Beispiele als Tests: Konkrete, überprüfbare Szenarien beschreiben gewünschtes Verhalten.
- Kollaboration: Product Owner, Entwickler:innen und Tester:innen arbeiten eng zusammen.
- Automatisierung: Viele Akzeptanztests werden automatisiert und in CI/CD-Pipelines integriert, obwohl auch manuelle Tests sinnvoll sein können (z. B. in stark regulierten Umfeldern).
- Definition of Done: Akzeptanztests operationalisieren die DoD auf Story- und Feature-Ebene.
Anwendung und Best Practices
- Refinement-Workshops: Anforderungen werden vor Beginn der Entwicklung präzisiert. Akzeptanztests machen Erwartungen transparent.
- Gherkin-Syntax (Given – When – Then): Szenarien sind für Business und IT gleichermaßen verständlich.
- Automatisierte Regressionstests: Neue Funktionalität wird kontinuierlich gegen bestehende Akzeptanztests geprüft.
- Traceability: ATDD schafft direkte Rückverfolgbarkeit zwischen Anforderung, Test und Ergebnis.
- Risikobasierte Priorisierung: Kritische Szenarien werden zuerst umgesetzt und automatisiert.
- Best Practice: Tests klar, messbar und wartbar formulieren, ohne unnötige technische Details.
Praxisbeispiele
Versicherung: „Given ein Kunde hat eine gültige Police – When ein Schadensfall gemeldet wird – Then wird die Bearbeitung gestartet und dem Kunden eine Bestätigung gesendet.“
Gesundheitswesen: Akzeptanztests stellen sicher, dass ein elektronisches Rezept regulatorisch korrekt gespeichert wird.
Automotive: Ein Fahrerassistenzsystem muss beim Erkennen eines Hindernisses innerhalb von 200 ms reagieren – ein Akzeptanztest validiert dieses Verhalten.
SAFe-Umfeld: Auf Portfolioebene werden Features in Stories zerlegt, deren Abnahmekriterien direkt in ATDD-Szenarien überführt werden.
Kritik und Grenzen
- Initialaufwand: Die frühzeitige Definition von Tests erfordert Zeit und Disziplin.
- Wartungskomplexität: Automatisierte Tests müssen regelmäßig aktualisiert werden, sonst verlieren sie an Wert.
- Oberflächlichkeit: Zu grob definierte Tests können Lücken in der Qualitätssicherung hinterlassen.
- Dynamische Umfelder: In Projekten mit stark wechselnden Anforderungen können vorab definierte Tests zu viel Vorabstruktur schaffen und Anpassungen verlangsamen.
- Explorative Vorhaben: In Forschung oder Prototyping-Umgebungen ist ATDD schwer einsetzbar.
- Abgrenzung zu BDD: ATDD wird häufig mit BDD verwechselt; BDD legt den Schwerpunkt auf gemeinsame Sprache, ATDD auf formale Abnahmebedingungen.
Einbettung und Kombination
- SAFe Built-in Quality: ATDD ist eine Kernpraxis zur Sicherung von Qualität von Anfang an.
- Verknüpfung mit TDD und BDD:
- TDD = Entwicklerperspektive (Unit Tests).
- ATDD = Anwendersicht (Akzeptanztests).
- BDD = Brücke über eine gemeinsame Sprache.
- CI/CD-Integration: Akzeptanztests laufen automatisiert und sichern kontinuierlich Regressionen ab.
Kombination mit Living Transformation® und Living Strategy: Auch organisatorische Transformationen können von klar definierten „Akzeptanzkriterien“ profitieren – als explizite Bedingungen, wann eine Veränderung als erfolgreich gilt.
CALADE-Perspektive
Wir bei CALADE nutzen ATDD, um Anforderungen messbar und überprüfbar zu machen – nicht nur in Softwareprojekten, sondern auch in organisatorischen Veränderungsprozessen. Unsere Expert:innen unterstützen Teams dabei, ATDD pragmatisch einzusetzen und es mit BDD, TDD und SAFe Built-in Quality zu kombinieren.
Verweise auf verwandte Glossarartikel
- Test-Driven Development (TDD)
- Behavior-Driven Development (BDD)
- Built-in Quality (SAFe)
- Continuous Delivery Pipeline
- Specification by Example
← zurück zur Übersicht