BDD bietet die Chance, Entwicklungsprozesse zu verbessern. Wo wir sind, wohin wir wollen und wie wir dies erreichen können, darum geht es in diesem Blog-Post.
Bestandsaufname
Manchmal schreiben wir BDD inspirierten Code, doch wir erreichen nicht das wesentliche Ziel von BDD: "Q&A und nicht-technische Projektteilnehmer sollen besser gemeinsam arbeiten können".
Vereinzelt wird eine Spezifikation im BDD-Style einem Kunden vorgelegt, doch unsere User-Stories sind eher Aufgabensammlungen die komplett losgelöst von der Implementierung stehen. Überspitzt gesagt, ist BDD-Style bei uns eher TDD, mit einer anderen Namenskonvention.
Wo soll es hin
Ich würde vorschlagen, dass wir die zentrale Idee von BDD auch für uns übernehmen, also: "Wir möchten BDD Nutzen um die Kommunikation zwischen Auftraggeber, UI-Team, Entwicklern und Q&A zu verbesseren." Was bedeutet das für die einzelnen Rollen:
Product Owner/ Auftraggeber
- Arbeitet mit User-Stories und Szenarien in einem vorgegebenem Format
- Bekommt Vogelperspektiven Sicht auf Implementierungsfortschritt
Tester/ Q&A
- Automatische Tests werden aussagekräftiger, der Quelltext wird zugänglicher, weil leichter verständlich
- Kann Testszenarien in Entwickler-freundlicher Sprache formulieren und den Umsetzungfortschritt (passiv) nachvollziehen
- Kann Testszenarien direkt im Quelltext definieren
- Ist wie ein "Product-Owner" für die Q&A Sicht
UI-Team
- Hat einen besseren Blick auf die Entwicklungsgeschehnisse
- Kann leichter beim Spezifizieren unterstützen und gleich das richtige Format für Projektmanager, Kunden und Entwickler liefern
Entwickler
- Implementierungsschritte und Fortschritt werden von Nicht-Technikern nachvollzogen
- Muß in einer Form arbeiten, die die tatsächliche Implementierung der Spezifikationen an das nicht technische Team-dokumentiert
Konkrete Schritte
1: Anforderungserfassung: Der erste Schritt den wir gehen müssen ist es Anforderungen, User-Stores etc. in einem BDD tauglichen Format zu erfassen. (Siehe dazu auch weiter unten das Template)
2: Implementierungsfeedback: Damit alle sehen können wo wir sind, benötigen wir einen Feedback-Mechanismus der Teil der Buildprozess ist, also am Besten vom Continous-Integrations-Server erzeugt wird.
(Screenshot zeigt StoryQ HTML-Report)
Template für BDD-Spezifikation
Das Template für die BDD-Spezifikation ist Denglish, hier sollten wir überlegen ob wir Deutsch verwenden, wobei wir Methoden und Klassen (dort wo die Konzepte auch in englisch existieren) eigentlich in Englisch umsetzen
Titel (Beschreibung der User-Story, auch Mehrzeilig)
- Die User-Story erzählt:
- As a [Rolle]
- I want [Features]
- So that [Nutzen]
Akzeptanz Kriterium: (als Szenarien)
- Szenario 1: Title
- Given [Kontext]
- And [Mehr Kontext]...
- When [Ereignis]
- Then [Ergebniss]
- And [Anderes Ergebniss]...
- Szenario 2: ....
- Szenario 3: ...
Framework oder Konvention
Frameworks gibt es wie Sand am Meer. Welches ist das Richtige? Wie sieht unser Prozess aus, wie wird aus einer User-Story Code? Wie können wir dafür sorgen, dass die Umsetzung und der Umsetzungstand nicht nur beim Implementierer bleibt, sondern auch für alle zur Verfügung steht. Folgende Kriterien könnten wir verwenden:
- Alle Teammitglieder, insbesondere nicht-technische sollen einfachen Zugriff auf den Implementierungsstand erhalten. Das Framework sollte gute Reports erzeugen oder die Reports sollten gut zu erweitern sein.
- Ideal wäre eine Integrationsmöglichkeit mit Target-Process (hier können wir aber vielleicht die entsprechenden User-Stories-Ids angeben und so zumindest Links erzeugen). Eine Integration über die Testfälle wäre denkbar?
Spezifikation != Test-Driven-Development
Mir scheint es wichtig, dass Spezifikationen nicht mit TDD verwechselt werden und das eine BDD Prozess der viele Rollen umschließt, ergänzend zu Unit- und Integrationstests steht. Unsere Kunden oder das UI-Team interessieren Implementierungsdetails, die vielleicht Test-Getrieben mit Unit-Tests entwickelt wurden nicht. BDD in meinem Verständniss sollte Geschäftslogik-relevant sein. Um BDD-Tests von anderen Tests abgrenzen zu können, könnten sollten Sie vielleicht in einer eigenen Ordnerstruktur landen. Eine Datei und Klassen Namenskonvention sollte BDD-Tests deutlich abheben.
Das Feedback (z.B.: HTML Reports) über den Implementierungsstatus und die Spezifikation an Nicht-Entwickler sollte also nur BDD-Tests umfassen bzw. diese zumindest alleine stellen.
Links: