Wenn Sie mit TDD vertraut sind, dann ist ATDD eine Art TDD mit einem höheren Testniveau und mit mehr beteiligten Interessengruppen, mit anderen Worten, es ist eher ein Akzeptanztest als ein Unit-Test. Wenn Sie mehr über TDD wissen wollen, lesen Sie bitte den folgenden Beitrag:
Acceptance test-driven development (ATDD) ist eine Entwicklungsmethodik, die auf der Kommunikation zwischen den Geschäftskunden, den Entwicklern und den Testern basiert. ATDD umfasst viele der gleichen Praktiken wie Spezifikation durch Beispiel, verhaltensgetriebene Entwicklung (BDD), beispielgetriebene Entwicklung (EDD) und unterstützungsgetriebene Entwicklung, auch storytestgetriebene Entwicklung (SDD) genannt. All diese Prozesse helfen Entwicklern und Testern, die Bedürfnisse des Kunden vor der Implementierung zu verstehen und ermöglichen es den Kunden, sich in ihrer eigenen Domänensprache zu unterhalten.
Weit verbreitet in agilen Teams ist ATDD eine Praxis, bei der Geschäftsanalysten, Entwickler, Tester und die Benutzer zusammenarbeiten, um die Akzeptanzkriterien für jede Story (oder Funktion) in einem frühen Stadium des Entwicklungsprozesses (vor Beginn der Codierung) zu definieren. Dieser Ansatz ermöglicht es allen Beteiligten, das gleiche Maß an erwarteten Ergebnissen zu haben und zu erhalten, bevor ein Entwickler mit der Codierung beginnt.
Ich weiß, dass wir alle das Klischee „Entwickler kümmern sich nicht um die Spezifikation und Tester wollen nicht automatisieren“ gehört haben, aber mit ATDD wird eine Menge Zeit und Geld gespart, indem sichergestellt wird, dass die Entwickler mehr in die frühen Phasen der Spezifikation einbezogen werden und die Tester die Akzeptanztests automatisieren.
Wie wird ATDD im „wirklichen Leben“ umgesetzt?
Benutzen Sie SCRUM? Wenn ja, dann machen Sie bereits den größten Teil der Arbeit mit ATDD. Wenn nicht, dann muss das folgende Beispiel Ihre Neugierde stillen:
Beispiel
Angenommen, der Product Owner oder der Kunde hat die folgende Funktion in unserer mobilen Anwendung gefordert: „Als Benutzer möchte ich den Anmeldebildschirm umgehen, damit ich die Anwendung anonym nutzen kann.“ Nachdem wir diese Anforderung mit dem gesamten Team (Business Analyst, Entwickler, Tester…) besprochen und weitere Details zur Story oder zum Feature hinzugefügt haben, werden wir einige „Akzeptanz-“ oder „funktionale“ Tests haben, die dem hier ähneln (Bitte beachten Sie, dass dies nur ein Beispiel ist, viele Akzeptanztests fehlen für dieses Feature):
- Akzeptanzkriterium 1: Die Anwendung akzeptiert optional Login/Passwort zur Anmeldung
- Akzeptanzkriterium 2: Die Umgehungstaste ermöglicht es dem Benutzer, innerhalb der Anwendung ohne Login zu browsen.
- Akzeptanzkriterien 3: Wenn die Schaltfläche „Bypass“ ausgewählt ist, speichert oder zeigt die Anwendung keine benutzerspezifischen Informationen an.
- Akzeptanzkriterien 4: Wenn Login/Passwort verwendet werden, muss die Benutzeroberfläche der Anwendung an die Benutzereinstellungen angepasst werden.
Vorteile
1- Kunden-Verkäufer-Angleichung: Durch die obigen Akzeptanzkriterien als Eingabeinformationen sind wir (jedes Teammitglied) nun sicher, dass die Anwendung ihre Login/Passwort-Funktionalität beibehält und nur eine Schaltfläche hinzufügt, die es dem Benutzer ermöglicht, den Login-Bildschirm zu umgehen.
2- Qualität und Kosteneffizienz: Die oben genannten Tests können leicht automatisiert werden, noch bevor die Entwickler mit der Programmierung beginnen.
3- Time to Market: Sobald die Tests implementiert sind, können die Entwickler ihre geforderten Aufgaben validieren, bevor sie bekannt geben, dass sie fertig sind.
ATDD erfordert keine speziellen Tools. Es ist wichtig zu wissen, dass nicht alle Akzeptanztests automatisiert werden müssen. Die Automatisierung Ihrer Tests hängt von verschiedenen Aspekten ab, wie z.B.: technische Herausforderungen, Fristen und Kosten.
Werden Werkzeuge empfohlen?
ATDD erfordert keine speziellen Werkzeuge. Es ist wichtig zu wissen, dass nicht alle Akzeptanztests automatisiert werden müssen. Die Automatisierung Ihrer Tests hängt von verschiedenen Aspekten ab, wie z.B.: technische Herausforderungen, Fristen und Kosten.
In diesem Abschnitt gebe ich Ihnen nur einen Überblick über die am häufigsten verwendeten Automatisierungstools für ATDD:
FitNess: Das voll integrierte, eigenständige Wiki und Akzeptanztest-Framework
Robot-Framework: Generisches Testautomatisierungs-Framework für Akzeptanztests und akzeptanztestgetriebene Entwicklung (ATDD)
Calabash: Automatisierte Akzeptanztests für mobile Apps – Beachten Sie, dass dieses Framework möglicherweise nicht die neueste OS-Version unterstützt (über Android O )