Akzeptanztestgetriebene Entwicklung (ATDD): Ein vollständiger Leitfaden
Mehrdeutige Akzeptanzkriterien gehören zu den teuersten Defekten in der Auslieferung, da Ihr Team dafür zweimal zahlt: Einmal für die verschwendete Implementierung und erneut für die Nacharbeit. Akzeptanzkriterien können für alle klar lesbar sein und trotzdem für jeden Beteiligten etwas leicht Unterschiedliches bedeuten. Nacharbeiten, verpasste Sprint-Commitments und UAT-Ablehnungen beginnen alle dort. Akzeptanztestgetriebene Entwicklung (ATDD) ist die richtige Methodik, um das Problem zu beheben.
Akzeptanztestgetriebene Entwicklung ist eine kollaborative Praxis, bei der sich Product Owner, Entwickler und Tester auf Akzeptanzbeispiele einigen, bevor die Implementierung beginnt.
ATDD arbeitet auf Feature-Ebene und ergänzt TDD, das das Unit-Level-Design abdeckt. BDD überschneidet sich stark mit ATDD, da beide auf kollaborativer Anforderungsanalyse und Given-When-Then-Szenarien basieren.
Der Hauptaufwand liegt in der Anforderungsanalyse. Teams, die eine Gherkin-Datei öffnen, bevor sie das Feature diskutieren, überspringen den Teil, der kostspielige Nacharbeiten verhindert.
Akzeptanzszenarien sollten Geschäftsverhalten beschreiben, während API-Endpunkte und Tabellennamen in die Schrittdefinitionen gehören.
Das Tooling teilt sich in Requirements-Plattformen, ausführbare Spezifikations-Frameworks und Testmanagementsysteme. Reqnroll ersetzte SpecFlow für .NET, nachdem Tricentis den Support Ende 2024 einstellte.
Dieser Leitfaden erklärt, was ATDD ist und wo es sich von TDD und BDD unterscheidet, und zeigt dann den Zyklus anhand eines durchgearbeiteten Passwort-Reset-Beispiels. Er erläutert auch Tools, die Agile-Praktiken und die Gewohnheiten, die es am Laufen halten.
Was ist akzeptanztestgetriebene Entwicklung (ATDD)?
Akzeptanztestgetriebene Entwicklung ist ein kollaborativer Ansatz, bei dem sich Product Owner, Entwickler und Tester auf Akzeptanzbeispiele einigen, bevor ein Feature gebaut wird. Da diese Beispiele das Verhalten beschreiben, das der fertige Code zeigen muss, leiten sie die Implementierung vom ersten Commit an.
Sie werden akzeptanztestgetriebene Entwicklung ATDD in der QA-Dokumentation auf beide Arten geschrieben sehen, und beide Schreibweisen bedeuten dieselbe Praxis. „Getrieben“ ist das operative Wort in dieser Definition. Tests, die nach dem Versand eines Features geschrieben werden, hatten keinen Einfluss auf dessen Design, daher zählt diese Arbeit als einfaches Akzeptanztesting. ATDD stellt die Beispiele an erste Stelle, und Ihre Entwickler bauen darauf hin.
Praktiker fassen den Zyklus oft als vier Schritte zusammen, bekannt als Discuss, Distill, Develop und Demo. Ihr Team diskutiert die Anforderung, destilliert sie in spezifische Beispiele, entwickelt dann gegen diese fehlschlagenden Beispiele, bevor es das Ergebnis demonstriert.
Warum ATDD eine Requirements-Praxis ist
ATDD ist eine Requirements-Praxis, weil ihr Hauptoutput ein Satz vereinbarter Regeln ist, und die Tests kommen aus diesen Regeln. Betrachten Sie wieder die Versandanforderung: Bis jemand fragt, wie groß eine Bestellung sein muss und ob Rabatte die Summe ändern, bleibt die Regel unvollständig. Traditionelle Auslieferung stellt diese Fragen während der Implementierung oder nach dem Release, wenn die Beantwortung bedeutet, Code zu ändern. ATDD zieht dieselben Fragen in die Refinement-Phase.
ATDD vs TDD vs BDD
Alle drei Ansätze nutzen Tests oder Beispiele, um die Entwicklung zu leiten, obwohl jeder eine andere Frage über das System beantwortet. Suchergebnisse vermischen routinemäßig ATDD akzeptanztestgetriebene Entwicklung mit den anderen beiden, daher hilft ein direkter Vergleich.
Aspekt
ATDD
TDD
BDD
Hauptfokus
Geschäftliche Akzeptanzkriterien und Kundenanforderungen
Technisches Design und Implementierungskorrektheit
Verhalten und gemeinsame Domänensprache über Rollen hinweg
Wer nimmt teil
Product Owner, Entwickler, Tester
Entwickler
Product Owner, Entwickler, Tester, Analysten
Abstraktionsebene
Von außen beobachtbares Geschäftsverhalten
Interne Code-Units wie Klassen und Funktionen
Domänenverhalten, ausgedrückt in Geschäftssprache
Typisches Testformat
Given-When-Then-Szenarien oder Akzeptanzkriterien
Unit-Tests mit Assertions
Given-When-Then-Szenarien fokussiert auf Verhalten
Hauptergebnis
Vereinbarung darüber, was „fertig“ bedeutet
Sauberer, wartbarer, gut designter Code
Dokumentation, die mit Systemänderungen aktuell bleibt
TDD und ATDD unterscheiden sich hauptsächlich im Umfang. In test driven development schreibt ein Entwickler einen fehlschlagenden Unit-Test, fügt den minimalen Code hinzu, der ihn bestehen lässt, und refaktoriert dann. ATDD arbeitet eine Ebene höher, auf Feature-Ebene. Ein einzelner Akzeptanztest wie „Kunde erhält kostenlosen Versand ab €50″ kann mehrere TDD-Zyklen für Preisgestaltung und Warenkorb-Berechtigung abdecken.
BDD und ATDD überschneiden sich in der modernen Praxis stark. Beide entstanden aus vagen Anforderungen und schlechter Kommunikation zwischen Business und Delivery, und beide nutzen kollaborative Anforderungsanalyse mit Given-When-Then-Beispielen. Das Vokabular unterscheidet sich: ATDD spricht von Akzeptanzkriterien, BDD von Verhalten und ausführbaren Spezifikationen. Teams, die eines praktizieren, leihen sich routinemäßig Techniken vom anderen.
Ihre Product Owner, Entwickler und Tester sollten alle in der Lage sein, die Coverage hinter jeder Anforderung zu verfolgen. aqua cloud, eine KI-gesteuerte Test- und Requirements-Management-Plattform, orchestriert Daten, Akzeptanzkriterien und Testfälle an einem Ort, sodass jedes Beispiel miteinander verbunden bleibt. aqua Intelligence, basierend auf Ihrer eigenen Projektdokumentation, entwirft Testfälle aus diesen Anforderungen in Sekunden und schreibt sie in Ihrer Domänensprache. Jeder Plan beinhaltet auch unbegrenzte kostenlose Gast-Lizenzen, sodass Business-Analysten und Stakeholder Akzeptanzkriterien und Coverage-Reports lesen können, ohne einen bezahlten Platz zu belegen. Teams, die zu aqua wechseln, sparen bis zu 60% der Zeit, die sie für QA-Management aufwenden, was die Refinement-Stunden bezahlt, die ATDD erfordert. Bidirektionale Jira-Synchronisation hält Refinement-Ergebnisse und Testergebnisse in beiden Richtungen abgeglichen, während Azure DevOps- und Confluence-Integrationen Akzeptanzkriterien bis zur Implementierung tragen.
Entwerfen Sie ausführbare Testfälle aus Ihren vereinbarten Akzeptanzkriterien in Sekunden mit aquas KI
Die Praxis der akzeptanztestgetriebenen Entwicklung basiert auf einer kleinen Menge von Ideen, die unabhängig vom gewählten Tooling Ihres Teams gelten: Business, Entwicklung und Testing einigen sich auf den Umfang, bevor Code beginnt, und konkrete Beispiele ersetzen Formulierungen, die mehr als eine Lesart zulassen.
Zusammenarbeit kommt vor der Implementierung
ATDD bringt die Business-, Entwicklungs- und Testing-Perspektiven in ein Gespräch, bevor die Arbeit beginnt. Teams nennen das Muster üblicherweise die Three Amigos, obwohl die Gruppe auch einen Designer oder einen Architekten einschließen kann. Überlegen Sie, ob „€50 Bestellungen“ „mindestens €50″ oder „mehr als €50″ bedeutet. Die beiden Lesarten erzeugen unterschiedliche Warenkorb-Logik, also muss sich jemand zwischen ihnen entscheiden. Refinement ist, wo diese Entscheidung hingehört.
Beispiele machen Regeln spezifisch
Sich darauf zu einigen, dass „Bestellungen über €50 für kostenlosen Versand qualifizieren“ ist einfach. Die schwierigere Frage ist, ob eine €55-Bestellung mit einem €10-Rabatt qualifiziert. Das Durcharbeiten solcher Fälle erzwingt Präzision, und Ihre Product- und Delivery-Teams konvergieren auf ein Vokabular. Specification by Example baut auf derselben Idee auf, da reale Szenarien Geschäftsregeln ausdrücken, die Prosa offen für Interpretation lässt.
Akzeptanz wird vor Code vereinbart
Ihr Team klärt, wie „fertig“ aussieht, während die Anforderung noch editierbar ist. Diese Vereinbarung wird zum Ziel für Entwickler und zur Checkliste für Tester. Automatisierte akzeptanztestgetriebene Entwicklung fügt darüber hinaus ausführbare Prüfungen hinzu. Einige Teams automatisieren jedes Szenario, während andere einen manuellen Satz behalten, und beide praktizieren ATDD.
Der ATDD-Prozess: Schritt für Schritt
KI-generiertes Bild.
Der ATDD-Zyklus läuft von einem groben User-Need bis zur dauerhaften Regressions-Coverage. Unsere sieben Schritte sind eine praktische Lesart dieses Ablaufs, da die Praxis selbst keine feste Anzahl von Phasen vorschreibt.
1. Mit einem User-Need beginnen
Jeder Zyklus beginnt mit einer Aussage darüber, was Ihre Nutzer benötigen, egal ob das als User Story oder als einzeiliges Backlog-Item ankommt. Zum Beispiel: „Registrierte Kunden erhalten kostenlosen Standardversand, wenn ihre berechtigte Bestellung €50 übersteigt.“ Zu diesem Zeitpunkt fehlt der Anforderung das Detail, das für eine sichere Implementierung nötig ist. Ihr Team einigt sich hier auf das Problem, und die Lösung kommt später.
2. Kollaborativ diskutieren
Die Three Amigos untersuchen die Story aus Business-, Implementierungs- und Testing-Perspektiven. Product nennt die Absicht, ein Entwickler nennt, was der Code aus der Formulierung nicht entscheiden kann, und ein Tester nennt die Grenzen und Fehlerpfade. Product sagt „kostenloser Versand über €50″, der Entwickler fragt, welche Zwischensumme zu berechnen ist, und der Tester fragt, was bei genau €50 passiert. Product beantwortet beide Fragen in der Session, und Ihr Team schreibt die Antworten auf, bevor jemand geht.
3. Abstrakte Regeln in konkrete Beispiele destillieren
Mit den Annahmen auf dem Tisch wandelt Ihr Team Formulierungen in Fälle um, die jeder verifizieren kann. Nehmen Sie „Bestellungen über €50 qualifizieren für kostenlosen Versand“ und testen Sie die Formulierung gegen echte Warenkörbe. Die Regel könnte dann werden: „Kostenloser Standardversand gilt, wenn die berechtigte Warenzwischensumme nach Rabatten mindestens €50 beträgt.“ Die vereinbarten Beispiele lauten dann wie folgt:
Warenkorbinhalt
Erwartetes Ergebnis
€50 an berechtigten Artikeln
Kostenloser Versand
€49,99 an berechtigten Artikeln
Bezahlter Versand
€75 vor einem €30-Rabatt
Bezahlter Versand
€60 mit €15 an ausgeschlossenen Artikeln
Bezahlter Versand
Die dritte Zeile ist, wo Ihr Team entdeckt, ob „übersteigt €50″ „mehr als“ oder „mindestens“ bedeutete.
Akzeptanzkriterien und Akzeptanztests arbeiten auf zwei Detailebenen, und Teams verwechseln sie häufig:
Akzeptanzkriterien
Akzeptanztests und Beispiele
Zweck
Definieren die Bedingungen für Akzeptanz
Beweisen diese Bedingungen mit spezifischen Fällen
Form
Geschäftsregel
Spezifischer Input oder Kontext, plus das erwartete Ergebnis
Beispiel
Bestellungen von €50 oder mehr erhalten kostenlosen Versand
Sobald die Beispiele vereinbart sind, drücken Sie sie in einem Format aus, das die Implementierung leiten kann. Given-When-Then funktioniert hier gut, weil es Kontext, Aktion und Ergebnis trennt:
Szenario: Kostenloser Versand an der Schwelle
Given ein registrierter Kunde
And ihre berechtigte Warenkorb-Zwischensumme beträgt €50
When sie zur Kasse gehen
Then sollte der Standardversand kostenlos sein
Szenario: Versand unter der Schwelle
Given ein registrierter Kunde
And ihre berechtigte Warenkorb-Zwischensumme beträgt €49,99
When sie zur Kasse gehen
Then sollte der Standardversand nicht kostenlos sein
5. Die Funktionalität implementieren
Die Entwicklung beginnt damit, dass die Akzeptanztests bereits fehlschlagen, da das Feature noch nicht existiert. Ihre Entwickler wählen den Implementierungsansatz, der passt, wie TDD auf Unit-Ebene oder Pair Programming. Die Akzeptanzspezifikationen definieren durchgehend das Ziel.
6. Die Tests zum Bestehen bringen
Während die Implementierung fortschreitet, beginnen die vereinbarten Szenarien eins nach dem anderen zu bestehen. Wenn alle bestehen, erfüllt das Feature Akzeptanzkriterien, die Ihr Team festgelegt hat, bevor Code existierte. Argumente darüber, ob die Arbeit fertig ist, enden hier, weil die Definition im Voraus fixiert war.
7. Die Tests als Regressions-Coverage behalten
Behalten Sie schließlich die bestandenen Akzeptanztests als Regressions-Coverage, unter der Bedingung, dass sie sich mit den Anforderungen entwickeln, die sie spezifizieren. Ein veraltetes Szenario kann immer noch korrekt fehlschlagen, während es eine Regel dokumentiert, die Ihr Product Owner vor zwei Sprints geändert hat. Automatisierte Szenarien melden Implementierungs-Drift, sobald sie laufen. Manuelle Szenarien melden nichts, bis jemand sie bewusst erneut ausführt.
Rollen und Verantwortlichkeiten in ATDD
ATDD hängt davon ab, dass drei Perspektiven im richtigen Moment beitragen, und jede besitzt eine andere Frage. Die Praxis bricht zusammen, wenn Ihr Team sie als „QA schreibt Gherkin-Szenarien“ behandelt.
Perspektive
Üblicherweise gehalten von
Fragen, die sie aufwerfen
Was sie besitzen
Business
Product Owner, Business Analyst, Domänenexperte
Gilt dieser Rabatt? Was passiert bei Premium-Mitgliedern?
Das „Was“ und das „Warum“
Entwicklung
Entwickler, Architekten
Berechnen wir vor oder nach Steuer? Was, wenn das Payment-Gateway nicht verfügbar ist?
Das „Wie“, plus technische Beschränkungen des „Was“
Testing
Tester, QA-Engineers
Was passiert bei genau €50? Was ist mit einem abgelaufenen Token, der zweimal verwendet wird?
Das „Was wäre wenn“ und die Vollständigkeit der Beispiele
Beispiel für akzeptanztestgetriebene Entwicklung: Passwort-Reset
Ein durchgearbeitetes Beispiel für akzeptanztestgetriebene Entwicklung zeigt, was der Zyklus produziert. Product bringt eine vertraute Story: „Als Kunde möchte ich mein Passwort zurücksetzen, damit ich wieder Zugang zu meinem Konto erhalte.“
Die Story liest sich als vollständig, bis Ihr Team sie prüft:
Offenbart das System, ob eine E-Mail-Adresse existiert?
Wie lange bleibt der Reset-Link gültig?
Kann jemand denselben Link zweimal verwenden?
Was passiert, wenn ein Kunde einen zweiten Reset anfordert, bevor er den ersten verwendet?
Werden bestehende Sessions nach der Passwortänderung widerrufen?
Welche Passwort-Richtlinie gilt für das neue Passwort?
Keine davon sind Edge Cases. Jede beschreibt Kernverhalten, das die ursprüngliche Story unspezifiziert ließ, also würde ein Entwickler es sonst allein entscheiden.
Durch Diskussion landet das Team auf einer Geschäftsregel: Ein Reset-Token kann genau einmal verwendet werden und läuft nach 30 Minuten ab. Drei Szenarien machen diese Regel testbar:
Szenario: Gültiger Token innerhalb des Zeitlimits
Given ein Reset-Link wurde vor 10 Minuten erstellt
When der Kunde ein gültiges neues Passwort einreicht
Then ändert sich das Passwort
And der Reset-Token wird ungültig
Szenario: Abgelaufener Token
Given ein Reset-Link wurde vor 31 Minuten erstellt
When der Kunde versucht, ihn zu verwenden
Then bleibt das Passwort unverändert
And der Kunde wird informiert, dass der Link abgelaufen ist
Szenario: Wiederverwendeter Token
Given ein Reset-Token wurde bereits verwendet
When der Kunde versucht, ihn erneut zu verwenden
Then wird die Anfrage abgelehnt
And der Kunde wird informiert, dass der Link nicht mehr gültig ist
Ihre Entwickler wissen jetzt, einen Token zu generieren, der nach 30 Minuten stirbt, und dann dessen Alter und Verwendungsstatus zu prüfen, bevor ein Reset erlaubt wird. Tester wissen, was zu verifizieren ist, und Product weiß, was Kunden erleben werden. Sobald die Szenarien bestehen, bleiben sie in der Suite, sodass ein späteres Refactoring nicht leise die Token-Ablaufzeit entfernen kann.
Die Akzeptanzkriterien dienen dazu, die Details auf eindeutige Weise zu definieren. Entscheidend ist, dass sie großartig sind, um dem Team zu ermöglichen, um Funktionalität herum zu kommunizieren und sich zu organisieren und sicherzustellen, dass sie die gleiche Interpretation einer User Story teilen.
ATDD zahlt sich durch Timing aus, da Ihr Team Formulierungen während des Refinements korrigiert, während die Anforderung noch ein Satz ist.
Frühere Mehrdeutigkeitserkennung: Vage Anforderungen kommen im Refinement heraus, sodass eine 15-minütige Diskussion drei Tage fehlgeleiteter Implementierung ersetzt.
Vereinbarung über Rollen hinweg: Business, Entwicklung und QA klären beabsichtigtes Verhalten, bevor Code existiert.
Testbare Anforderungen: Akzeptanzkriterien, die aus Beispielen mit beobachtbaren Ergebnissen gebaut sind, sind einfach zu verifizieren.
Weniger anforderungsgetriebene Nacharbeit: Missverstandene Anforderungen gehören zu den teuersten Quellen von Defekten, und ATDD legt sie offen, während sie noch Formulierungen sind.
Eingebaute Regressions-Coverage: Automatisierte Akzeptanzbeispiele prüfen weiterhin erwartetes Verhalten nach späteren Änderungen.
Reduzierter Scope Creep: Spezifische Szenarien sagen Ihren Entwicklern genau, welches Verhalten zu implementieren ist.
Schnellere Feedback-Loops: Probleme erscheinen in der Diskussion, sodass sich die Schleife von Wochen in UAT auf Stunden im Refinement verengt.
Herausforderungen und Einschränkungen von ATDD
ATDD verlangt von Ihrem Team Zeit und Gewohnheiten, die es möglicherweise noch nicht hat, und diese Kosten entstehen, bevor irgendeiner der Vorteile eintritt.
Vorabzeit im Refinement: Kollaborative Spezifikation fügt Zeit zu Anforderungsdiskussionen hinzu, und Teams, die gewohnt sind, sofort mit Code zu beginnen, finden das Tempo langsam. Da die Rendite später kommt, brauchen Sie organisatorische Vereinbarung, dass frühe Klarheit die Investition wert ist.
Kultureller Wandel: Die Praxis scheitert, wenn Product Anforderungen über die Mauer wirft oder wenn Entwickler erst nach der Implementierung mit Testern sprechen. Kollaborative Gewohnheiten brauchen länger zum Aufbau als technische Fähigkeiten.
Risiko der Über-Spezifikation: Einige Teams versuchen, jede mögliche Input-Kombination zu dokumentieren, bevor die Entwicklung beginnt, was Analyseparalyse ist. Zielen Sie auf Klarheit über Kernverhalten ab und hören Sie weit vor einer 100-Seiten-Spezifikation auf.
Tooling kann von der Konversation ablenken: Teams, die über Cucumber-Syntax und CI-Konfiguration debattieren, bevor sie die Anforderung diskutieren, automatisieren Verhalten, auf das sich niemand geeinigt hat.
Nicht jedes Kriterium verdient Automatisierung: Bestimmte Szenarien sind teuer zu automatisieren, ändern sich selten oder sind schneller manuell zu verifizieren. Der Aufwand, sie zu automatisieren, bringt wenig zurück.
Die Three Amigos planen: Die richtigen Leute in einen Raum zu bekommen ist schwer für verteilte Teams über Zeitzonen hinweg, und verschobene Sessions untergraben den Nutzen schnell.
Es ersetzt nicht anderes Testing: ATDD beantwortet, ob ein Feature vereinbarte Akzeptanzkriterien erfüllt. Performance-, Security-, Usability- und exploratives Testing bleiben alle die Verantwortung Ihres Teams.
Tools und Frameworks für akzeptanztestgetriebene Entwicklung
Tools für akzeptanztestgetriebene Entwicklung fallen in drei Kategorien, und jede dient einem anderen Teil des Zyklus.
Kollaborations- und Requirements-Tools
Diese handhaben die Upstream-Arbeit, von User Stories und Akzeptanzkriterien bis zu Genehmigungen und Änderungshistorie. Jedes vereinbarte Beispiel braucht ein Zuhause und einen Link zurück zu seiner Eltern-Anforderung. Jira, Azure DevOps und ein dediziertes test management tool wie aqua decken diesen Bereich ab. aqua hält die Kette von Anforderung zu Akzeptanzkriterium zu Testfall zu Ausführungsergebnis, mit Genehmigungen und Audit-Historie inklusive.
Ausführbare Spezifikations-Frameworks
Diese wandeln vereinbarte Beispiele in ausführbare Prüfungen um. Lesbarkeit ist ihre gemeinsame Stärke, weil Nicht-Entwickler die Szenarien lesen und hinterfragen können.
Framework
Ökosystem
Beste Eignung
Cucumber
Java, JavaScript, Ruby
Teams, die auf Gherkin-Szenarien standardisieren
Reqnroll
.NET
Gherkin-basierte ausführbare Spezifikationen für moderne .NET-Projekte
Robot Framework
Python, plattformübergreifend
Keyword-gesteuerte Tests für Teams mit gemischten Fähigkeiten
FitNesse
Java, .NET
Etablierte Suites in langjährigen Produkten
Reqnroll ist der aktiv gewartete Nachfolger des eingestellten SpecFlow-Projekts, das Ende 2024 Vendor-Support verlor. Jedes .NET-Team, das heute beginnt, sollte daher SpecFlow-Tutorials überspringen. Jedes Framework hier automatisiert Szenarien, auf die sich Ihr Team vorher geeinigt hat, und Requirements-Management bleibt bei den Tools in der vorherigen Kategorie.
Testmanagementsysteme
Sobald Ihr Team Akzeptanzszenarien im großen Maßstab ausführt, werden Ownership und Traceability zum täglichen Problem. Welche Anforderung betrifft dieser Fehler, und wer besitzt das Szenario? Ein test case management tool beantwortet beides, indem es Anforderungen, Akzeptanzkriterien, Testfälle, Ausführungsergebnisse und Defekte zentralisiert. Coverage-Reporting sagt Ihrem Team dann, welche Anforderungen noch keine angehängten Szenarien haben.
Wählen Sie den Stack, der zum Workflow passt, den Ihr Team bereits ausführt.
Diagramm der akzeptanztestgetriebenen Entwicklung
Das Diagramm der akzeptanztestgetriebenen Entwicklung unten bewegt sich durch vier Phasen, mit Feedback-Schleifen, die jede Phase mit der vorherigen verbinden.
Implementierungsphase: Fehlschlagende Akzeptanztests 0 Entwicklung mit TDD 0 Bestandene Akzeptanztests
Wartungsphase: Regressions-Suite 0 Kontinuierliche Verifizierung 0 Dokumentation, die aktuell bleibt
Die Phasen laufen iterativ und nie streng linear. Wenn Beispiele eine unklare Regel offenbaren, kehrt Ihr Team zur Discovery zurück. Ein unerwarteter Fehler schickt es zurück zur Spezifikation, und geänderte Akzeptanzkriterien starten den Zyklus von oben neu.
Beim Schreiben von Stories, lasst die „Three Amigos“ zusammenkommen — Architekten für die ganzheitliche Sicht, Entwickler für das „Wie“ und Tester, um alles schön zusammenzubinden. Eure Aufgabe ist es, der Gruppe Kontext für das zu geben, was getan werden muss, die Diskussion zu moderieren und letztendlich aufzuschreiben, was sie in der Story brauchen.
Beim Schreiben von Stories, lasst die „Three Amigos" zusammenkommen — Architekten für die ganzheitliche Sicht, Entwickler für das „Wie" und Tester, um alles schön zusammenzubinden. Eure Aufgabe ist es, der Gruppe Kontext für das zu geben, was getan werden muss, die Diskussion zu moderieren und letztendlich aufzuschreiben, was sie in der Story brauchen.
Akzeptanztestgetriebene Entwicklung in Agile-Teams braucht keine neuen Events, weil Refinement, Planning und Review die Diskussion bereits abdecken. Was sich ändert, ist der Inhalt dieser Meetings. Der Scrum Guide behandelt die Definition of Done als Commitment und sagt nichts über eine Definition of Ready. Zeilen hier mischen daher Scrum-Events mit Praktiken, die einige Teams hinzufügen.
Scrum-Aktivität oder Praxis
Wo ATDD hineinpasst
Backlog refinement
Ihr Team definiert Beispiele für jede Story und identifiziert die Regeln dahinter
Definition of Ready, wo Teams eine verwenden
Eine Story qualifiziert sich, sobald vereinbarte, testbare Beispiele existieren, sodass vage Arbeit aus dem Sprint bleibt
Sprint planning
Schätzungen verbessern sich, weil Entwickler das genaue Verhalten kennen, und Tester können Daten und Umgebungen vorbereiten
Daily Scrum
Fehlschlagende Akzeptanzszenarien können Blocker offenlegen, die den Fortschritt zum Sprint Goal beeinflussen
Sprint review
Stakeholder sehen bestandene Szenarien demonstriert und wissen genau, welches Verhalten funktioniert
Retrospective
Ihr Team misst, wie oft Beispiele spät definiert oder mid-Sprint revidiert wurden
Definition of Done
Fertigstellung bedeutet, jedes vereinbarte Akzeptanzszenario besteht, was subjektives Urteil entfernt
ATDD funktioniert am besten, wenn es Meetings ändert, die Ihr Team bereits durchführt. Ein separater Spezifikations-Workshop zusätzlich zum Refinement produziert das gegenteilige Ergebnis, weil das zusätzliche Meeting zum ersten wird, das in einem vollen Sprint gestrichen wird. Für eine breitere Sicht darauf, wie Beispiele Testdesign speisen, deckt unser Leitfaden zu Agile test case design techniques die Techniken ab, die gut mit ATDD zusammenpassen.
Wie aqua ATDD vom Refinement bis zur Ausführung unterstützt
KI-generiertes Bild.
aqua cloud unterstützt ATDD, indem es Anforderungen und ihre Akzeptanzbeispiele in einem System hält und dann jedes Beispiel mit den Tests und Ergebnissen verknüpft, die es verifizieren. Weil Refinement-Ergebnisse, Testfälle und Ausführungshistorie an einem Ort bleiben, kann Ihr Team Coverage-Fragen beantworten, ohne drei Tools zu öffnen.
Mehrere Teile des Produkts bilden sich auf den ATDD-Zyklus ab:
Requirements und Akzeptanzkriterien an einem Ort. aquas requirements management-Modul speichert User Stories zusammen mit ihren Akzeptanzkriterien. Testfälle verknüpfen sich automatisch mit ihnen, sodass alles, was nicht abgedeckt ist, in der Requirements-Ansicht erscheint.
Gherkin-Generierung aus Anforderungen. aqua Intelligence entwirft Testfälle im BDD-Format direkt aus einer Anforderung. Ihr Team überprüft dann während des Refinements eine erste Version jedes Szenarios.
Bidirektionale Jira-Synchronisation. In Jira verfeinerte Stories kommen in aqua mit ihren angehängten Akzeptanzkriterien an. Ergebnisse fließen danach zurück zum Ticket, sodass Product sieht, welche Szenarien bestehen.
Automatisierung und Nachweise. Jenkins, Ranorex und die REST API-Integration speisen automatisierte Ergebnisse zurück in aqua. Die Capture-Erweiterung zeichnet währenddessen manuelle Durchläufe mit Video und Screenshots auf.
Wenn ein Akzeptanztest fehlschlägt, sieht Ihr Team die Eltern-Anforderung, den Owner, die Ausführungshistorie und jeden verknüpften Defekt auf einem Bildschirm. Dieser Bildschirm ist auch der Datensatz, den Auditoren anfordern.
Best Practices für die Implementierung von ATDD
Sobald der Zyklus regelmäßig läuft, halten einige operationale Gewohnheiten ihn nachhaltig.
Strukturieren Sie die Diskussion mit Example Mapping. Die Technik organisiert Refinement um die Story, die sie regierenden Regeln, ein Beispiel für jede Regel und die offenen Fragen. In dieser Reihenfolge zu arbeiten hält die Session in Bewegung, weil ungelöste Fragen für später aufgezeichnet werden und die Diskussion nicht blockieren. Timeboxen Sie jede Story und speisen Sie dann den Output direkt in Ihre Akzeptanztests.
Beschreiben Sie beobachtbares Verhalten in Ihren Szenarien. Ein Szenario, das „Wenn ich POST /api/v2/cart sende und Tabelle cart_items abfrage“ liest, dokumentiert Ihre Architektur. Ein Szenario, das „Wenn der Kunde das Produkt in seinen Warenkorb legt, dann erscheint das Produkt im Warenkorb“ liest, dokumentiert die Geschäftsregel. Halten Sie Endpunkte und Tabellennamen in Schrittdefinitionen, wo sie hingehören.
Wählen Sie das günstigste Test-Interface, das das Verhalten beweist. Business-Akzeptanz erfordert selten einen Browser, sodass Service-Level- oder API-Level-Prüfungen normalerweise die bessere Standardeinstellung sind. Sie laufen schneller, brechen seltener und verifizieren trotzdem, was Product gefordert hat. Einige Szenarien brauchen wirklich UI-Verifizierung, und die sind ihre Kosten wert.
Halten Sie Szenarien unabhängig. Jedes Szenario sollte seinen eigenen Kontext aufbauen, ein Verhalten ausüben und ein Ergebnis verifizieren. Abhängigkeit von früheren Szenarien macht Fehler schwer zu debuggen, und ein Szenario, das zehn Verhaltensweisen abdeckt, verbirgt, welche Regel gebrochen ist. Ihre Suite wächst auf diese Weise größer, und sie wird auch viel einfacher zu vertrauen.
Automatisieren Sie basierend auf Wert. Priorisieren Sie Szenarien, die jeden Sprint laufen oder Kern-Business-Flows abdecken. Lassen Sie Low-Value-Beispiele manuell, bis Ihr Team Bandbreite hat, sie richtig zu automatisieren. Suites, die für totale Coverage gebaut wurden, neigen dazu, dauerhaft rot zu bleiben.
Pfle gen Sie Spezifikationen, wenn Anforderungen sich ändern. Ein Akzeptanzszenario, das nicht mehr mit der vereinbarten Regel übereinstimmt, wird irreführende Dokumentation, selbst während es besteht. Also wenn Product eine Regel ändert, aktualisieren Sie das Szenario im selben Sprint und prüfen Sie, dass es immer noch mit seiner Anforderung verknüpft ist. Teams, die diese Wartung überspringen, häufen Dokumentation an, die eine ältere Version des Produkts beschreibt.
ATDD hängt von kollaborativer Anforderungsanalyse, vereinbarten Beispielen und Traceability von Business-Intent durch Verifizierung ab. aqua cloud, eine KI-gestützte Test- und Requirements-Management-Lösung, deckt alle drei in einer Plattform ab. Definieren Sie Anforderungen und Akzeptanzkriterien mit Ihrem Team und lassen Sie dann aqua Intelligence vollständige Testszenarien aus der eigenen Dokumentation Ihres Projekts entwerfen. Jedes Akzeptanzbeispiel verknüpft zurück zu seiner Eltern-Anforderung, sodass Ihr Team bidirektionale Traceability in jedem Maßstab behält. aqua ist ISO 27001-zertifiziert und DORA-konform, sodass die Akzeptanznachweise, die Ihr Team sammelt, in einem externen Audit standhalten, ohne eine separate Reporting-Übung. Mehr als 200 Unternehmen und 35.000 Nutzer in 26 Ländern führen ihre QA bereits auf diese Weise durch. Führen Sie Szenarien manuell oder durch 10+ native Automatisierungs-Integrationen aus, einschließlich Jenkins, Ranorex, JMeter, SoapUI, REST API, PowerShell, UnixShell und MSSQL- oder Oracle-Datenbanken. Die Capture-Integration zeichnet dann jede Ausführung mit Video und Screenshots für Ihre Audit-Historie auf.
Fazit
ATDD verschiebt Akzeptanz von einer finalen Prüfung in ein frühes Gespräch. Wenn sich Ihre Product Owner, Entwickler und Tester auf spezifische Beispiele vor der Implementierung einigen, kommt Mehrdeutigkeit heraus, während die Anforderung noch editierbar ist. Diese Beispiele funktionieren dann gleichzeitig als Spezifikation, Verifizierung und Dokumentation. Die Praxis verlangt allerdings kulturellen Wandel, Refinement-Zeit und Tooling, das eine Anforderung bis zur Ausführung verfolgt. Wenn diese vorhanden sind, verbringt Ihr Team weit weniger von jedem Sprint damit, Features neu zu bauen, die beim ersten Mal missverstanden wurden.
TDD ist eine Entwickler-Praxis, die auf Unit-Tests basiert, die das interne Design formen. ATDD arbeitet auf Feature-Ebene, wo Business-Beispiele beobachtbares Verhalten definieren. Ihre Entwickler führen oft mehrere TDD-Zyklen unter einem einzelnen Akzeptanztest aus.
Ist ATDD dasselbe wie BDD?
Sie überschneiden sich stark in der modernen Praxis. Beide beruhen auf kollaborativer Anforderungsanalyse und Given-When-Then-Beispielen. BDD betont Verhalten und gemeinsame Domänensprache über den Delivery-Zyklus. ATDD konzentriert sich auf Akzeptanzkriterien und den Punkt, an dem ein Feature als fertig zählt.
Wer schreibt Akzeptanztests in ATDD?
Ihr gesamtes Team trägt bei. Product Owner definieren das Business-Ergebnis, Entwickler heben technische Beschränkungen hervor, und Tester drängen auf Edge Cases. Ein Tester oder Business Analyst schreibt normalerweise die finale Formulierung, obwohl die Beispiele selbst aus der gemeinsamen Diskussion kommen.
Was sind die Hauptvorteile von ATDD?
Frühere Erkennung vager Anforderungen, Vereinbarung über Rollen hinweg, testbare Akzeptanzkriterien und weniger anforderungsgetriebene Nacharbeit. Automatisierte Beispiele bleiben auch in Ihrer Suite als Regressions-Coverage, die beabsichtigtes Verhalten für jeden dokumentiert, der später Ihrem Team beitritt.
Welche Tools unterstützen akzeptanztestgetriebene Entwicklung?
Cucumber, Reqnroll und Robot Framework wandeln vereinbarte Beispiele in ausführbare Spezifikationen um. Anforderungen, Coverage und Traceability gehören in Test-Management-Plattformen wie aqua cloud. Jira oder Azure DevOps handhaben den Story-Level-Workflow um sie herum.
Erfordert ATDD die Automatisierung jedes Szenarios?
Nein. Automatisieren Sie die Szenarien, die jeden Sprint laufen oder Kern-Business-Flows abdecken, und halten Sie seltene oder teure Prüfungen manuell. Teams, die alles automatisieren, häufen normalerweise eine Wartungslast an, die schwer genug ist, um sie von der Praxis abzubringen.
Wann sollte Ihr Team Akzeptanztests definieren?
Kurz bevor die Entwicklung beginnt, während des Backlog Refinements. Definieren Sie sie früher und die Details werden veraltet, bevor das Coding beginnt. Lassen Sie es später und Ihr Team schreibt Tests für Code, der bereits existiert.
Die Verbesserung des aqua-Produkts ist Martins Hauptaufgabe und größte Mission. Sein Fachwissen umfasst ITIL-Prozessberatung, Änderungsmanagement, Qualitätssicherung, Qualitätsmanagement und Anforderungsmanagement. Martin arbeitet seit mehr als 18 Jahren in der Qualitätssicherung für regulierte Branchen und ist eine unersetzliche Führungskraft bei der andagon Group.
Nurlan, ein QA-Koordinator, ist stolz darauf, nahtlose QA-Operationen zu orchestrieren. Seine Expertise in der Koordination von QA-zentrierten Projekten und der Integration von QA-Lösungen hat konsequent höchste Kundenzufriedenheit erzielt. Neben seiner Vollzeittätigkeit als QA-Koordinator beinhaltet Nurlans Rolle das Erstellen von überzeugenden Inhalten, die Nutzer über die…
Pavel ist Quality-Assurance-Berater und Autor mit tiefem Fachwissen in der Lösung komplexer Testherausforderungen. Sein Hintergrund in der Softwareentwicklung hat Organisationen dabei geholfen, ihre QA-Praktiken von reaktiv zu proaktiv zu entwickeln. Neben der Beratung entwickelt Pavel Best-Practice-Leitfäden und Fallstudien für aqua cloud, die praxisnahe QA-Lösungen demonstrieren…
Beginnen Sie Ihre Arbeit nicht mit gewöhnlichen E-Mails: Fügen Sie eine gesunde Dosis an aufschlussreichen Softwaretest-Tipps von unseren QS-Experten hinzu.
Home » Agile in der QS » Akzeptanztestgetriebene Entwicklung (ATDD): Ein vollständiger Leitfaden
Lieben Sie das Testen genauso wie wir?
Werden Sie Teil unserer Community von begeisterten Experten! Erhalten Sie neue Beiträge aus dem aqua-Blog direkt in Ihre Inbox. QS-Trends, Übersichten über Diskussionen in der Community, aufschlussreiche Tipps — Sie werden es lieben!
Wir sind dem Schutz Ihrer Privatsphäre verpflichtet. Aqua verwendet die von Ihnen zur Verfügung gestellten Informationen, um Sie über unsere relevanten Inhalte, Produkte und Dienstleistungen zu informieren. Diese Mitteilungen können Sie jederzeit wieder abbestellen. Weitere Informationen finden Sie in unserer Datenschutzrichtlinie.
X
🤖 Neue spannende Updates sind jetzt für den aqua KI Assistenten verfügbar! 🎉
