Vor einiger Zeit habe ich darüber berichtet, dass wir in unserem laufenden Projekt über die Definition of Done (DoD) gesprochen haben, um diese zu überprüfen und zu erneuern. Dabei kam von den Teammitgliedern der Vorschlag, Cucumber (www.cukes.info) als Teil der DoD einzusetzen. Ein großartiger Gedanke, wie sich herausstellte.
BDD – Ein kurzer Exkurs
Behavior Driven Development (BDD) ist eine Form des agilen Entwickelns, welches es den Softwareentwicklern und Testern eines Teams sowie dem Business Verantwortlichen (oder Stakeholdern) ermöglicht, auf einer Ebene zu kommunizieren. Das bedeutet, die Testfälle werden so geschrieben, dass die Stakeholder sie lesen können – in „Plain Text“. Es wird dabei nicht wie in der testgetriebenen Entwicklung (TDD) ein Testfall definiert, sondern eine Erwartung. Diese kann bspw. ein Akzeptanzkriterium für ein Backlog Item darstellen. Man kann somit sagen, dass eine ausführbare Spezifikation des zu entwickelnden Features geschrieben wird.
Was es uns bringt
Mal davon abgesehen, dass es dem Team Spaß macht mit Cucumber zu arbeiten und die Implementierung sehr schmerzfrei verlief, führt es dazu das:
- das Team schneller und sicherer entwickelt
- alle Beteiligten mehr miteinander kommunizieren
- alle verstehen, welche Erwartungen/Anforderungen bestehen
- ein besseres Verständnis über das gewünschte Ergebnis entsteht
- die Nebenwirkungen von Code-Änderungen offensichtlicher sind bzw. zeitnaher entdeckt werden
- besserer Code geschrieben wird (siehe auch das eher technische Video Good Test, Better Code – From Unit Testing to Behavior-Driven Development)
- die Testumgebung für andere Projekte nutzbar gemacht werden kann
Weitere Tools für den Einsatz von BDD finden Sie hier.
Hallo Robert,
mich würde interessieren warum der Einsatz von Cucumber die Kommunikation fördert bzw. warum ohne dieses Tool weniger kommuniziert wird?
Gruß,
Andree
Hallo Andree,
es liegt schon an der Methode an sich, die eine bessere Zusammenarbeit zwischen den Entwicklern, Testern und Auftraggebern (oder anderen Interessengruppen) ermöglicht. Das Verfassen einer Erwartung in einer allgemein verständlichen Form führt dazu, dass Missverständnisse minimiert werden. Die Vorteile liegen darin, dass alle in „derselben Sprache“ kommunizieren und das Verständnis der (Business) Anforderungen verbessert wird.
In der täglichen Arbeit bedeutet es für uns, dass die Anforderungen die vom Product Owner gestellt werden nun zusätzlich in Cucumber Tests transformiert werden. Dies führt beim Erstellen eines Cucumber Tests zu einer erhöhten Kommunikation zwischen Entwickler und Tester. Man setzt schon viel früher gemeinsam an, den Test gemeinsam erfolgreich durchzuführen, als die Schritte nacheinander zu verlagern: 1. Entwicklung, 2. Testing.
Dieses Infoblatt zum Thema, verdeutlicht den Punkt noch einmal:
http://www.techtalk.at/getdoc/54fe09e7-115e-4c9b-9942-f599c9e66eaf/BDD_FolderSmall.aspx
Beste Grüße,
Robert