ATDD verständlich erklärt - Akzeptanztests vor dem Coding

Ein Team kann wochenlang an einer Funktion arbeiten und trotzdem am Bedarf der Nutzer vorbeientwickeln. Acceptance Test Driven Development (ATDD) setzt deshalb vor dem Programmieren an: Fachbereich, Entwicklung und Qualitätssicherung klären anhand konkreter Beispiele, wann eine Funktion wirklich als fertig gilt. Ich zeige, wie dieser Ansatz funktioniert, worin er sich von TDD und BDD unterscheidet und wie sich ATDD ohne unnötige Prozesslast in ein agiles Team integrieren lässt.

Was hinter ATDD wirklich steckt

ATDD ist kein Testwerkzeug und auch keine zusätzliche Endkontrolle kurz vor dem Release. Es ist eine gemeinsame Arbeitsweise für Anforderungen, bei der das erwartete Verhalten einer Funktion durch konkrete Beispiele beschrieben wird, bevor das Team den Code schreibt.

Ein Akzeptanztest beantwortet dabei eine praktische Frage: Woran erkennen wir, dass diese Funktion aus Sicht des Nutzers richtig funktioniert? Bei einem Online-Shop könnte das etwa bedeuten, dass ein Kunde einen verfügbaren Artikel in den Warenkorb legen und anschließend eine gültige Lieferadresse eingeben kann. Die technische Umsetzung bleibt offen.

Genau diese Trennung ist entscheidend. Ein Fachbereich muss nicht wissen, welche Datenbank oder welches Framework verwendet wird. Er muss nachvollziehen können, was das System bei bestimmten Eingaben tun soll und welches Ergebnis erwartet wird.

Die Zusammenarbeit wird häufig als „Three Amigos“ bezeichnet. Gemeint sind drei Blickwinkel, die gemeinsam Risiken sichtbar machen:

• Der Fachbereich erklärt, welches Problem gelöst werden soll.
• Die Entwicklung prüft, wie die Lösung technisch sinnvoll umgesetzt werden kann.
• Testing oder Qualitätssicherung fragt, was schiefgehen könnte und welche Grenzfälle fehlen.

Die Agile Alliance beschreibt Akzeptanztests als formale Beispiele oder Nutzungsszenarien für das Verhalten eines Produkts. Für mich ist dabei weniger die Formulierung wichtig als der gemeinsame Denkprozess: Ein guter Test ist ein verständlicher Vertrag zwischen Produktverantwortlichen und Team.

So läuft der Prozess in der Praxis ab

Ein sinnvoller ATDD-Ablauf beginnt nicht mit einer Gherkin-Datei und auch nicht mit einem Test-Framework. Ich würde zuerst eine überschaubare User Story auswählen und die Beteiligten für etwa 45 bis 60 Minuten an einen Tisch holen. Das reicht meist, um den Kern der Funktion zu schärfen.

1. Geschäftsziel klären: Welches Nutzerproblem soll gelöst werden und warum ist es relevant?
2. Beispiele sammeln: Das Team beschreibt typische Abläufe mit konkreten Eingaben und Ergebnissen.
3. Grenzfälle ergänzen: Fehlende Daten, ungültige Eingaben, Berechtigungen und Sonderregeln kommen auf den Tisch.
4. Akzeptanzkriterien festlegen: Alle Beteiligten einigen sich darauf, was erfüllt sein muss.
5. Tests formulieren: Die Beispiele werden als manuelle oder automatisierte Akzeptanztests dokumentiert.
6. Implementieren und prüfen: Die Entwicklung baut die kleinste Lösung, die die vereinbarten Beispiele erfüllt.

Ein einfaches Szenario kann im Stil von Given, When, Then beschrieben werden. Diese Struktur bedeutet „Ausgangslage, Aktion, erwartetes Ergebnis“ und ist deshalb auch für nichttechnische Beteiligte leicht lesbar.

Gegeben sei ein bezahlter Warenkorb mit einem Gesamtwert von 80 Euro
Wenn der Kunde einen Gutschein über 10 Euro einlöst
Dann beträgt der neue Gesamtwert 70 Euro

Das Beispiel ist noch kein vollständiger Test. Es fehlen etwa die Frage, was bei einem abgelaufenen Gutschein passiert oder ob der Gutschein mit anderen Rabatten kombinierbar ist. Gerade solche Lücken entdeckt das Team in der gemeinsamen Diskussion, bevor sie teuer im Code oder im Betrieb auftauchen.

Ich empfehle, zunächst nur die wichtigsten Beispiele zu wählen. Drei bis fünf gut durchdachte Szenarien sind für eine kleine User Story oft wertvoller als 20 oberflächliche Fälle, die später niemand mehr pflegt.

[search_image]ATDD Three Amigos acceptance criteria Given When Then software development workflow diagram

Ein Beispiel aus der Softwareentwicklung

Stellen wir uns eine deutsche SaaS-Anwendung vor, in der Mitarbeitende Reisekosten einreichen. Die User Story lautet: „Als Mitarbeiter möchte ich eine Reisekostenabrechnung einreichen, damit ich meine Auslagen erstattet bekomme.“ Ohne weitere Klärung bleibt diese Aussage zu ungenau.

Im gemeinsamen Gespräch entstehen konkrete Beispiele. Eine gültige Abrechnung enthält beispielsweise ein Reisedatum, einen Betrag, einen Beleg und eine Kostenstelle. Fehlt der Beleg, soll das System die Einreichung ablehnen und einen verständlichen Hinweis anzeigen.

Diese Beispiele leisten mehr als eine klassische Aufgabenbeschreibung. Sie machen Geschäftsregeln sichtbar, liefern der Entwicklung ein klares Ziel und geben später eine nachvollziehbare Grundlage für die Abnahme. Besonders hilfreich ist, dass der Begriff „Beleg“ im gesamten Team dieselbe Bedeutung bekommt.

Die Tests sollten nicht mit technischen Details überladen werden. „Die API liefert HTTP 422“ kann für Entwickler sinnvoll sein, ist aber kein gutes fachliches Akzeptanzkriterium. Besser ist: „Die Abrechnung bleibt offen und erklärt, welche Angabe fehlt.“ Technische Prüfungen gehören zusätzlich in Integrations- oder Unit-Tests.

ATDD, TDD, BDD und UAT sind nicht dasselbe

Die Begriffe werden oft vermischt, weil sie sich ergänzen. Sie setzen aber an unterschiedlichen Stellen an. Die folgende Einordnung hilft mir in Workshops, unnötige Grundsatzdiskussionen zu vermeiden.

TDD startet näher am Code. Entwickler schreiben zuerst einen fehlschlagenden Unit-Test, implementieren die kleinste Lösung und verbessern anschließend die Struktur. ATDD startet dagegen beim Geschäftswert und prüft, ob überhaupt die richtige Funktion gebaut wird.

BDD überschneidet sich stark mit ATDD. Cucumber beschreibt BDD als gemeinsames Herausarbeiten von Beispielen, deren Dokumentation und anschließende Automatisierung. In der Praxis verwenden Teams deshalb oft Gherkin und Given-When-Then für ATDD. Entscheidend ist nicht das Etikett, sondern ob echte fachliche Zusammenarbeit stattfindet.

UAT ist wiederum nicht automatisch ATDD. Ein User Acceptance Test kann erst am Ende eines Projekts stattfinden und von einem Kunden ausgeführt werden. Bei ATDD entstehen die akzeptierten Beispiele früh und iterativ, sodass sie die Entwicklung von Anfang an beeinflussen.

Welche Tests und Werkzeuge sinnvoll sind

Akzeptanztests können zunächst auf einem Whiteboard, in einem Ticket oder in einer Tabelle stehen. Das ist kein minderwertiger Start, sondern oft der beste Weg, um die fachliche Verständigung nicht durch Toolfragen zu überdecken.

Erst wenn die Beispiele stabil sind, lohnt sich die Automatisierung. Geeignete Werkzeuge hängen vom System und vom Team ab. Häufig eingesetzt werden etwa Cucumber für Gherkin-Szenarien, Playwright oder Cypress für browsernahe Tests sowie REST- oder GraphQL-Testwerkzeuge für serviceorientierte Systeme.

Ich bevorzuge dabei möglichst kurze Wege durch das System. Ein Test, der ausschließlich über eine fragile Benutzeroberfläche läuft, kann langsam und wartungsintensiv werden. Wenn das fachliche Verhalten über eine stabile Service-Schnittstelle geprüft werden kann, ist das oft robuster. Die Oberfläche braucht trotzdem eigene Tests für Layout, Navigation und zentrale Bedienabläufe.

Eine praxistaugliche Testlandschaft verteilt die Verantwortung auf mehrere Ebenen:

• Unit-Tests prüfen einzelne Funktionen und liefern schnelles Feedback.
• Integrations- und Vertragstests prüfen das Zusammenspiel von Modulen und Schnittstellen.
• Akzeptanztests prüfen fachliche Abläufe aus Sicht des Nutzers.
• Exploratives Testing sucht bewusst nach unerwartetem Verhalten, das kein vorher formuliertes Beispiel abdeckt.

Die automatisierten Akzeptanztests sollten in die Continuous Integration eingebunden werden. Dabei startet die Pipeline die Prüfungen bei Änderungen am Code. Scheitert ein Test, muss das Ergebnis verständlich genug sein, damit das Team nicht erst eine halbe Stunde in Logs suchen muss.

Wo ATDD an Grenzen stößt

ATDD verhindert keine Fehler automatisch. Es verbessert vor allem die Qualität der Kommunikation und macht bestimmte Erwartungen überprüfbar. Wenn die falsche Geschäftsregel vereinbart wurde, kann auch ein grüner Test eine falsche Entscheidung bestätigen.

Ein häufiger Fehler ist die Testautomatisierung ohne Gespräch. Dann schreibt ein Entwickler oder ein QA-Team Szenarien allein, während der Fachbereich nur noch das Ergebnis abnickt. Die Dateien sehen zwar professionell aus, lösen aber das eigentliche Problem nicht.

Ebenso problematisch sind zu technische Szenarien. Begriffe wie Datenbanktabellen, interne Klassen oder konkrete CSS-Selektoren gehören normalerweise nicht in fachliche Akzeptanztests. Sie machen die Dokumentation schwer verständlich und führen dazu, dass sich Tests bei jeder internen Änderung unnötig verändern.

Auch die Testmenge muss kontrolliert werden. Wenn jedes Detail als End-to-End-Test abgebildet wird, wird die Pipeline langsam und instabil. Ich würde deshalb die wichtigsten Geschäftsrisiken auf dieser Ebene testen und Detailvarianten weiter unten in der Testpyramide abdecken.

Für kleine Wartungsaufgaben oder sehr technische Refactorings ist eine große Three-Amigos-Runde oft übertrieben. Dort reichen klare Unit- und Integrationstests. ATDD spielt seine Stärke vor allem bei fachlich riskanten, missverständlichen oder kundenrelevanten Funktionen aus.

So startet ein Team ohne unnötigen Overhead

Der beste Einstieg ist eine einzelne User Story mit sichtbarem Geschäftsrisiko. Ich würde zunächst keine neue Plattform kaufen und auch nicht alle alten Tests umschreiben. Stattdessen sollte das Team eine Funktion auswählen, an der sich der Nutzen schnell zeigen lässt.

1. Product Owner, Entwickler und Tester formulieren gemeinsam das Ziel.
2. Das Team sammelt ein erfolgreiches Beispiel und mindestens einen Fehler- oder Grenzfall.
3. Die Szenarien werden in einer für alle verständlichen Sprache dokumentiert.
4. Die Entwicklung implementiert nur das Verhalten, das für die Beispiele erforderlich ist.
5. Nach dem ersten Durchlauf prüft das Team, ob die Szenarien verständlich, stabil und nützlich sind.

Für den Anfang genügt es, eine bis zwei User Stories pro Sprint auf diese Weise zu bearbeiten. Nach zwei oder drei Iterationen wird sichtbar, ob die Gespräche bessere Anforderungen liefern und ob sich die Automatisierung im Alltag trägt.

Ein gutes Erfolgssignal ist nicht die Anzahl der Gherkin-Dateien. Aussagekräftiger sind weniger Rückfragen während der Entwicklung, frühere Entdeckung widersprüchlicher Anforderungen und eine Abnahme, die nicht jedes Mal zur Überraschung wird.

Was aus grünen Akzeptanztests folgen sollte

Ein grüner Akzeptanztest bedeutet nicht, dass ein Produkt fertig oder fehlerfrei ist. Er sagt präziser, dass ein vereinbartes Verhalten unter den beschriebenen Bedingungen funktioniert. Diese Begrenzung macht die Aussage belastbar.

Ich sehe ATDD deshalb als Entscheidungs- und Verständigungswerkzeug, nicht als Wettbewerb um möglichst viel Testcode. Teams profitieren besonders dann, wenn sie die Beispiele gemeinsam schreiben, fachliche Sprache ernst nehmen und Automatisierung nur dort einsetzen, wo sie dauerhaft Feedback liefert.

Wer mit einer klar abgegrenzten User Story beginnt, drei Perspektiven zusammenbringt und die wichtigsten Beispiele vor dem Coding klärt, bekommt schnell ein realistisches Bild vom Nutzen. Genau darin liegt die Stärke dieses Ansatzes: Die Frage „Haben wir es richtig gebaut?“ wird früh mit der wichtigeren Frage verbunden, „Bauen wir überhaupt das Richtige?“