Given/When/Then und ATDD  - Eine Win-Win-Win-Situation!?

Akzeptanzkriterien frühzeitig durch fachliche Szenarien beschreiben

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.

Was ist Given When Then und ATDD?

| „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.

Warum GWT früher einbinden und wann?

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.

• Kunde/Fachexperte: Welche Probleme versuchen wir zu lösen?
• Entwicklung/Fachexperte: Wie können wir diese Probleme lösen?
• Testing: Was passiert bei Kombination von [..] & [..], wenn [..]?

Hands-on / Beispiel

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.

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.

Vor-/Nachteile

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

• Es erfordert eine Umgewöhnung, die Dokumentation mittels der vorgegebenen Syntax zu beschreiben.
• Alle Szenarien (positive and negative Testfälle) müssen beschrieben werden. Erkannte Szenarien können zwar detaillierter in ihre Bestandteile heruntergebrochen werden, dennoch besteht die Gefahr, dass Szenarien vergessen werden, da z.B. nicht jeder Negativ-Fall abgedeckt wird.
• GWT-Tests funktionieren besser, wenn der Code mit Business-Logic (Geschäftsregeln) getestet wird. Beim Testen von Klassen, die eher mit Infrastruktur, Dienstprogrammen, Datenmanipulation usw. zu tun haben, ist GWT nicht die beste Wahl. Hier ist es eher umständlich GWT-Tests zu definieren und die Erstellung kann sich erzwungen anfühlen.
• Es entsteht ein höherer Aufwand bei der Beschreibung der Szenarien. Im Fall von normalen Akzeptanzkriterien kann auf eine reine positiv-Beschreibung gesetzt werden. Dies bedeutet, dass keine negativen Fälle mit einbezogen werden.
• Bei Szenarien mit einer hohen Anzahl an Given- oder When-Schritten, können diese schnell unleserlich werden. Eine Möglichkeit zur Lösung dieses Problems besteht darin, die Szenarien nach fachlichen Aspekten zu trennen, sofern dies möglich ist. Dies wiederum erhöht allerdings auch die Anzahl an Szenarien.
• Mittels GWT wird meist nur ein Bruchteil der relevanten Testfälle erzeugt. Möchte man ein Feature bis ins Detail beschreiben und Testen, kann die Anzahl an Szenarien überhandnehmen.
• Nur das Nutzen von GWT-Akzeptanzkriterien ist kein Garant für ein perfektes Testen – In der Praxis müssen entsprechend spezifische Tools eingesetzt werden. Ein Risiko besteht daher darin, dass die gewählten Tools den Hauptzweck dieser Praxis eher behindern als fördern. Solche Tools sollten unbedingt an die Bedürfnisse des Teams und des Product Owners angepasst werden und nicht umgekehrt.
  
  

Fazit

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:

1. Fachbereiche können ihr Fachwissen recht einfach dokumentieren.
2. Entwickler können die Funktionalität und das Verhalten des Systems aus Benutzersicht besser verstehen und können so ihre technischen Aspekte einfließen lassen.
3. Tester sind durch ihre frühzeitige Einbindung in die fachlichen Aspekte gut vertraut und können die Tests basierend auf den GWT-Akzeptanzkriterien leichter durchführen. Sie achten auch auf die korrekte Verwendung der GWT-Syntax und stellen sicher, dass die Dokumentation korrekt ist, während sie ihre Teststrategie umsetzen.