In der Entwicklung ist Given, When, Then (GWT) ein noch nicht so geläufiger Begriff. Es handelt sich dabei um eine Methode zur Definition von Testszenarien, die einfacher zu verstehen und zu handhaben sind. Durch die Möglichkeit der manuellen und automatisierten Durchführung, bietet ein Vorgehen zwei Möglichkeiten zur Testdurchführung.
Given, Then, When entstammt dem Behavior Driven Development (BDD) und stellt eine Methode des Testens dar, die durch Dan North geprägt wurde. Im Vordergrund stehen Szenarien, die in anwenderfreundlicher Form beschrieben werden. Dieses Vorgehen findet Anwendung in agilen Projekten und Teams und bringt einige Vorteile, aber auch Pitfalls mit sich.
| „GWT - mehr als nur eine Testmethode in agilen Projekten durch ATDD“ |
In diesem Beitrag stellen wir eine innovative Methode vor, wie Akzeptanzkriterien in agilen Projekten mithilfe von Given, When, Then und der modernen Methode Acceptance Test-Driven Development (ATDD) dokumentiert werden können. Wir sehen uns an, wie User Stories durch GWT/ATDD beschrieben werden können und welche Vor- und Nachteile damit verbunden sind. Dabei nutzen wir Given, When, Then nicht nur für Tests, sondern bereits in einem frühen Stadium zur Beschreibung von User Stories.
Eine genauere technische Beschreibung und Umsetzung von Testfällen nach GWT kann im Beitrag Demokratisierung von Softwaretests nachgelesen werden.
Das Vorgehen GWT ist in der Entwicklung keine Unbekannte, hat seinen Ursprung aber weiterhin beim Testen. Durch das Vorschalten mittels Acceptance Test-Driven Development, entfallen die klassischen Akzeptanzkriterien bei User Stories und werden durch Szenarien ersetzt. So werden alle Team-Mitglieder und relevanten Stakeholder (Kunden, Fachexperten, Programmierer und Tester) mit den verschiedensten Perspektiven einbezogen. Bevor eine User Story in die Umsetzung geht, erarbeiten die Team-Mitglieder gemeinsam die Akzeptanzkriterien. Durch diesen gemeinsamen und engen Austausch können die Anforderungen und daraus resultierende User Stories von allen Perspektiven besser hinterfragt und beschrieben werden. Dabei nimmt jede Rolle eine bestimmte Position ein, um die Anforderung und Akzeptanzkriterien zu hinterfragen.
Was uns weiterhin erhalten bleibt, ist die generelle User Story, welche nun aber nicht mehr durch eine Auflistung von Akzeptanzkriterien erweitert wird, sondern durch vollständig zu beschreibende Szenarien. Diese helfen dabei, die Anforderung weiter zu beschreiben.
User Story
Als Sales-Mitarbeiter möchte ich mein Dashboard anpassen können, um die nur für mich wichtigen Informationen direkt einsehen zu können.
User Story mit klassischen Akzeptanzkriterien |
User Story mit Given When Then / Szenarien |
Ich kann meinem Dashboard neue Widgets aus einer vordefinierten Liste von verfügbaren Widgets hinzufügen.
|
Szenario 1: Hinzufügen eines Widgets zum Dashboard Given der Benutzer sieht die Liste der verfügbaren Widgets. When der Benutzer ein Widget auswählt und hinzufügt. Then erscheint das ausgewählte Widget auf dem Dashboard. |
Ich kann die Reihenfolge der Widgets auf meinem Dashboard ändern, indem ich sie in einem Anpassungsmodus an die gewünschte Stelle ziehe und ablege (Drag & Drop). |
Szenario 2: Anordnung meiner Widgets verändern Given der Benutzer befindet sich nicht im Anpassungsmodus des Dashboards Then kann der Anwender keine Widgets verschieben. Given, der Benutzer ist im Anpassungsmodus des Dashboards And es sind mindestens zwei Widgets im Dashboard When der Benutzer ein Widget verschiebt Then wird das Widget an der abgelegten Stelle in der Reihenfolge hin verschoben. |
Der Aufwand kann teilweise höher ausfallen, vor allem zu Beginn, wenn GWT zuvor nicht angewandt wurde. Dennoch bietet diese Art der Dokumentation seinen Mehrwert. Unter anderem entsteht ein einheitliches Verständnis unter allen Stakeholdern, die Funktionalität und das Verhalten des Systems sind aus Benutzersicht besser zu verstehen. Die Szenarien verdeutlichen die Abläufe und Interaktionen, die von den Akzeptanzkriterien der User Story abgedeckt werden, und bieten klare Schritte, um sicherzustellen, dass die Funktionalität erfolgreich implementiert ist.
Im Nachfolgenden werden die Vor- und Nachteile dieser Dokumentationsart aufgezeigt. Dabei ist dieses Vorgehen nicht die ultimative Lösung für jedes IT-Projekt im agilen Rahmen. Hier muss immer auf das Setting des gesamten Teams geachtet werden.
Gleiches Verständnis
Durch eine vorgegebene Syntax, die auch anwenderverständlich ist, kann ein einheitliches Verständnis der Anforderungen und der zugehörigen Bedingungen innerhalb des Teams ermöglicht werden. Bei einer frühzeitigen Einbindung dieser Methode hilft es dem Kunden und weiteren Stakeholdern, die Akzeptanzkriterien besser und einfacher zu verstehen. Einer der Haupterfolgsfaktoren bei der Nutzung von GWT ist das einheitliche und schnelle Verständnis.
Testautomatisierung
Ein weiterer Vorteil der Verwendung des GWT/ATDD ist, dass es das Schreiben automatisierter Tests erleichtern kann. Akzeptanzkriterien geschrieben nach GWT bieten die Möglichkeit, entweder manuell oder mittels Tools wie FitNesse und Cucumber automatisierter getestet zu werden. Wartbare und verständliche, automatisierte Tests unterstützen klare und eindeutige Akzeptanzkriterien. Durch die Verwendung des GWT-Formats lassen sich die Akzeptanzkriterien leicht in automatisierte Tests übersetzen bzw. teilweise direkt nutzen. Diese können aber nicht unbedingt alle Fehler erkennen, so zum Beispiel tiefergehende Performance-Probleme, die Barrierefreiheit und Usability-Probleme.
Wenn Sie ein Interesse an der Testautomatisierung in der Praxis haben und sich tiefergehend damit beschäftigen müssen, empfehlen wir Ihnen den Beitrag Demokratisierung von Softwaretests.
Frühzeitige Identifikation von Anforderungen
GWT kann auch dazu beitragen, fehlende oder unvollständige Anforderungen in einem frühen Stadium des Entwicklungsprozesses zu erkennen. Indem ein Feature in seine Bestandteile zerlegt wird, ist es einfacher, Lücken oder Inkonsistenzen zu erkennen. Dies kann besonders bei iterativen Entwicklungsprojekten und Projekten mit sich häufig ändernden Anforderungen hilfreich sein.
Zusammenarbeit
Die Förderung der Zusammenarbeit zwischen den Teammitgliedern ist ein weiterer Vorteil. GWT-Akzeptanzkriterien sollten gemeinsam mit dem gesamten Team erstellt werden, einschließlich Kunde/Fachexperten, Entwicklern und Testern. So wird sichergestellt, dass alle an einem Strang ziehen und es keine Missverständnisse gibt. Durch die Zusammenarbeit bei der Erstellung von Akzeptanzkriterien gewinnen die Team-Mitglieder auch ein besseres Verständnis für die Rollen und Verantwortlichkeiten der jeweils anderen.
Klare Kommunikation
Schlussendlich kann die Verwendung von Given When Then / ATDD die Kommunikation innerhalb des Teams und mit den Beteiligten verbessern. Durch die Verwendung eines strukturierten Formats werden die Akzeptanzkriterien von allen leicht verstanden, unabhängig von ihren technischen Kenntnissen. So wird sichergestellt, dass alle Beteiligten auf derselben Seite stehen und es keine Missverständnisse gibt. Eine klare Kommunikation trägt auch dazu bei, Vertrauen zwischen den Team-Mitgliedern und den Beteiligten aufzubauen.
Mögliche Nachteile bei der Nutzung von GWT und ATDD
Wie bei jeder Methode und jedem Tool geht es darum, die Entscheidung zur Nutzung zu evaluieren. Dazu müssen die Vor- und Nachteile mit allen Projektbeteiligten besprochen und individuell bewertet werden.
Ein großer Vorteil von GWT ist, dass es auch zu einem späteren Zeitpunkt problemlos in ein Projekt integriert werden kann, falls man sich im Verlauf für Tests basierend auf GWT entscheidet. Es ist jedoch wichtig zu beachten, dass man in diesem Fall auf die klare und einfache Verständlichkeit von User Stories und deren Akzeptanzkriterien verzichtet, die in Form von Szenarien dargestellt werden und die damit verbundenen Vorteile bieten. Deshalb ist es ratsam, frühzeitig zu entscheiden, ob ATDD und damit GWT im Projekt eingesetzt werden sollen.
Durch den Einsatz von GWT haben Kunden, Fachexperten, Entwickler und Tester die Möglichkeit, sich vollständig in die Beschreibung der Akzeptanzkriterien einzubringen und dies auf einer Ebene zu tun, die für alle verständlich ist.
Man könnte fast von einer WIN-WIN-WIN Situation für alle Projektbeteiligten sprechen: