BDD ... so nicht! - Die TOP 5 BDD Irrtümer

Was ist Behavior Driven Development (BDD) ?

Bevor wir uns mit den Antipatterns bei der Anwendung von Behavior Driven Development (BDD) beschäftigen, ist es wichtig, sich mit den darunterliegenden Konzepten auseinanderzusetzen.

Eine ausführliche Einführung von BDD würde den Rahmen von diesem Beitrag sprengen. Wir empfehlen hierzu folgende Bücher:

• BDD in Action von John Ferguson Smart
• Specification By Example von Gojko Adzic

Zusammengefasst ist das primäre Ziel von BDD das Richtige effizient zu tun. Denn, was bringt die perfekt programmierte und bestdokumentierte Software, wenn sie am Ende das Falsche macht? Falsch kann sich dabei auf die Anforderungen des Stakeholders oder aber auch auf die Erwartungen des Endanwenders beziehen.

Genau für dieses Problem bietet BDD eine bewährte Lösung:

Die Prinzipien von BDD. Quelle: Eigene Darstellung

Durch das frühzeitige Einbinden zur kontinuierlichen Kollaboration aller Experten wird ein gemeinsames Verständnis der Anforderungen aufgebaut.

Hierzu werden konkrete Beispiele als Diskussionsgrundlage, z.B. im Refinement Meeting, verwendet. Das fördert auch das Auffinden möglicher fachlicher Lücken. Die Beispiele werden dabei in natürlicher Sprache ausformuliert (z.B. mit der sog. Gherkin Syntax) und später auch automatisiert. Hier spricht man auch von Akzeptanztests, welche die korrekte Umsetzung der Anforderung validieren.

Die Berichte aus den (automatisierten) Beispielen werden als Teil der Produktdokumentation gepflegt. Daraus entsteht eine sogenannte Lebende Dokumentation bzw. Living Documentation. Also eine Dokumentation, die für alle Experten verständlich ist und automatisch kontinuierlich validiert wird.

Bekannte BDD Werkzeuge / Plattformen sind Serenity BDD, Cucumber oder FitNesse.

TOP 5: Die Falle „Übergaben“ – Zaun 1

Folgendes Szenario zur Anwendung von Behavior Driven Development (BDD) : Der Fachbereich bzw. die Fachtester schreiben ihre Testfälle  im Given-When-Then Format und übergeben sie als Teil der Anforderungsspezifikation an das Entwicklungsteam. Die Entwickler kümmern sich dann um die Automatisierung der Testfälle.

Das ist natürlich eine Verbesserung gegenüber klassischer Ansätze, in denen die Tester ihre Testfälle unabhängig vom Entwicklungsteam festlegen und durchführen. Ein Kernelement von BDD wird jedoch dadurch ignoriert: die Diskussion.

Die Diskussion ist nicht nur ein Kernelement von BDD, sie wird auch als wesentliches Element bei der Ausarbeitung von User Stories empfohlen. Wir denken hier an Ron Jeffries 3C´s.

Denn nur der „Live“- Austausch zwischen den Experten reduziert das Risiko von Fehlinterpretationen und versteckten fachlichen Lücken.

Hierfür ist eine wichtige erste Verbesserungsmaßnahme, die Tester bzw. die Testaktivitäten in die Entwicklungsteams zu integrieren. Das fördert die Identifikation und Verantwortung des Teams für die Produktqualität.

Als nächstes empfehlen wir die Refinement-Meetings zu Specification Workshops umzugestalten. Alle Experten sind dabei involviert und diskutieren die Anforderungen anhand von Schlüsselbeispielen um:

• ein gemeinsames Verständnis von Anforderungen herzustellen: Ist ein „Tag“ 24 Stunden oder ein Kalendertag oder ein 8h-Arbeitstag?
• fachliche Lücken zu identifizieren: Haben wir an Feiertage gedacht ? Was ist mit Sonntag/Wochenende?
  

Das Konzept nennt Gojko „The Three Amigos„. In Lisa Crispin und Janet Gregory´s Agile Testing Bibel ist die Rede von „Power Of Three“

TOP 4: Dedizierte Tester – Zaun 2

Viele Entwicklungsteams stehen unter Zeit- und Lieferdruck. Um sie zu entlasten, wird häufig die Testaktivität in externe oder dedizierte Teams ausgelagert. Oft erhofft man sich dabei auch Kostenersparnisse. Das ist aber eine andere Diskussion und einen eigenen Blogbeitrag wert 🙂

Auch in diesem Fall schleicht sich die (fälschliche) Annahme ein, dass die Probleme durch den Einsatz der Gherkin-Syntax sowie eines BDD Tools entschärft werden. Ein Irrtum!

Denn Qualität ist und bleibt Team-Verantwortung. Probleme über den Zaun zu werfen macht sie nicht kleiner, sondern tendenziell deutlich größer!

Wie wir in unserem Quality Engineering Modell darstellen, ist die Automatisierung der Akzeptanztests fester Bestandteil der Umsetzung von Funktionalität und muss entsprechend eingeplant werden. Auch sollte jedes entwicklungsnahe Teammitglied in der Lage sein, die Tests zu automatisieren.

Das zeichnet ein gut funktionierendes und crossfunktionales Team aus, dass alle Experten beherbergt, welche für die Entwicklung der Anwendung benötigt werden. Darüber hinaus können alle Teammitglieder bei Bedarf „einspringen“ und helfen um eine zeitnahe Fertigstellung der Anforderung zu ermöglichen.

TOP 3: Die Monsterszenarien

In den ersten Gehversuchen mit Behavior Driven Development (BDD) behalten die meisten Tester ihre „klassische“ Brille aus den Zeiten des manuellen Testens. Sie definieren die Akzeptanztests aus dem Blickwinkel der Benutzungsoberfläche (meist ein Graphical User Interface).

Das führt in der Regel zu gigantischen Szenarien. Verstärkt wird diese Entwicklung dadurch, dass die meisten BDD Werkzeuge parametrisierbare Szenarien (z.B. Data tables in Cucumber) unterstützen.

BDD Monstertabellen. Quelle: Eigene Darstellung

Die Lösung bedarf aus unserer Sicht ein gewisses Umdenken im Testdesign.

Der erste Schritt wäre das strukturbasierte Testdesign. Akzeptanztests müssen nämlich nicht unbedingt als GUI-Tests (Klicktests) umgesetzt und geschnitten werden. Sie können auch als Unit-, Modul- oder API-Tests implementiert sein. Wie im Blog-Beitrag von unserem Kollegen ausführlich beschrieben, ist für diesen Schritt eine gewisse Kenntnis der Software Struktur notwendig. Willkommen in der Whitebox !

Dieser Ansatz bringt einige Vorteile mit sich:

• Die Testszenarien werden deutlich übersichtlicher und verständlicher
• Die Fehlersuche wird einfacher, da die Fehlerlokalisierung gezielter ist
• Wenn die Fachlichkeit auf Unit- oder Modulebene getestet wird, werden die betroffenen Einheiten isoliert betrachtet und alle externen Abhängigkeit simuliert. Das öffnet die Türen für deutlich mehr Szenarien, vor Allem welche, die in einer Testumgebung schwer bis kaum herzustellen sind.
• Die Ausführung der Tests ist deutlich schneller (=> Testpyramide)
• Die Tests sind deutlich stabiler und zuverlässiger
• und, und, …

TOP 2: Im Tool die Rettung sehen!

Viele BDD Werkzeuge sind mittlerweile ausgereift und bringen eine Menge von Erweiterungen und Funktionalitäten mit. Das verleitet dann nicht selten zur Annahme, dass die meisten Herausforderungen durch das Tool gelöst werden.

Aber auch hier gilt : “ A Fool with a tool is still a fool “

Auch mit den besten Werkzeuge kann man Vieles falsch machen.

Unsere Empfehlungen:

• Auf das Testdesign achten: Die Tests an sich müssen einfach und „dumm“ gehalten werden. Die unterliegende Automatisierungsschicht darf/soll jedoch ausgeklügelt sein um eine hohe Stabilität und Wiederverwendung zu erreichen
• Den Fokus bei der Wiederverwendung nicht auf Testebene aufbauen sondern nur in der Automatisierungsschicht
• Die Tests aus fachlicher Sicht und für eine nicht technisch affine Zielgruppe entwerfen
• Testcode wie produktiven Code behandeln.
• Das richtige Werkzeug auswählen: Die vorhandenen BDD Tools haben unterschiedliche Stärken, Schwächen und Einsatzzwecke. Diese sollen bei der Auswahl berücksichtigt werden

And the Winner is … TOP 1: Umsetzung als Klicktests

Eine der häufigsten Fehler bei der Spezifikation von Akzeptanztests im Gherkin Format is es, sie als Klickskripte zu definieren.

Ein Beispiel:

Dieses Antipattern vereint eigentlich mehrere gleichzeitig.

• Das WAS wird mit dem WIE vermischt: WAS will ich testen vs. WIE will ich den Test ausführen
• Eine testumgebungsspezifische Konfiguration im Test fest verdrahtet obwohl der Test an sich umgebungsunabhängig sein muss
• Der Aufbau der Benutzungsoberfläche und der Interaktionsablauf auch im Test festgeschrieben.
• Der Testfallspezifikation kann nur schwer entnommen werden was eigentlich getestet wird.
  • Navigation/Verfügbarkeit?
  • Browser-Kompatibilität?
  • Registrierung?
  • Eingabefelder?

Unsere Empfehlungen:

• Das WAS vom WIE zu trennen. Ob der Test als UI , API oder Unit umgesetzt wird, ist für die Validierung der Fachlichkeit nicht relevant. Diese Entscheidung soll in die Automatisierungsschicht verlagert werden.
• Technische Aspekte wie die Testumgebung, Art der Automatisierung, Clickreihenfolgen, usw. sind nicht teil der Testfallspezifikation
• Auf die Fachlichkeit fokussieren

Beispiel:

Kommen Dir diese Irrtümer bekannt vor?

Hast Du andere Erfahrungen gesammelt?

Wir freuen uns auf Eure Kommentare und den Austausch!