Behaviour Driven Testing - Klare Testprozesse und glückliche Endnutzer!

Haben Sie sich auch schon darüber geärgert, dass sehnlichst erwartete Features in Ihrem Softwareprodukt fehlerhaft oder ganz anders implementiert wurden, als Sie sich das als Auftraggeber vorgestellt haben?

Vielleicht haben Sie sich mit den Ursachen beschäftigt und jetzt suchen Sie nach Wegen, um die Anforderungen in künftigen Projekten von Anfang an eindeutig und glasklar festzulegen. Und Sie wollen die Umsetzung und Abnahme der Anforderungen systematisch sicherstellen.

Behaviour Driven Testing ist in einer solchen Situation eine hervorragende Vorgehensweise.

Was bedeutet Behaviour Driven Development (BDD)?

Behaviour Driven Development (BDD) ist im Wesentlichen eine Strategie in der Softwareentwicklung, die sicherstellt, dass das Endprodukt den Erwartungen der Benutzer gerecht wird.

Zur Umsetzung der Strategie werden oft Szenarien verwendet, die in einfacher Sprache beschreiben, wie die Software in bestimmten Situationen funktionieren soll. Szenarien werden auch als Anwendungsfälle oder “User Stories” bezeichnet. Diese Szenarien dienen als Basis für Tests, um sicherzustellen, dass die Software so funktioniert, wie sie soll.

Das Ziel von BDD ist es, Missverständnisse zwischen denjenigen, die die Software bauen, und denjenigen, die sie prüfen oder verwenden, zu minimieren.

• Qytera Podcast: Behaviour Driven Development - Szenarien, Einführung, Einsatz, Testautomatisierung

Was hat BDD mit Testen zu tun?

In der agilen Softwareentwicklung hat sich die Bedeutung des BDD-Ansatzes in den letzten Jahren gewandelt. Ursprünglich als Mittel zur besseren Verständigung zwischen Fachbereich und Entwickler gedacht, hat es sich als Werkzeug für alle Projektteilnehmer etabliert.

Dafür sorgt nicht zuletzt die ubiquitäre Sprache, eine einheitliche Fachsprache, die in der Softwareentwicklung verwendet wird, um alle Aktivitäten der Projektteilnehmer mit einzubinden. Dies hat den Vorteil, dass die Kommunikation zwischen Projektteilnehmern aus verschiedenen Fachbereichen, dazu zählen Softwareentwickler, Softwaretester und Stakeholder, verbessert und die jeweiligen Aufgaben und Verantwortungen definiert werden.

Das Softwarelifecycle zwingt in der Entwicklung eine kontinuierliche Qualitätssicherung zu betreiben. Hierfür müssen zu den Anforderungen die Gesichtspunkte des Softwaretests einfließen. Hierzu ermöglicht die BDD-Syntax, mit der Definition der Ein- und Ausgangsbedingen, hervorragend Testfälle abzuleiten. Im Prozess ermöglicht dies, die Testfälle vor der Entwicklung entstehen zu lassen, analog zum Test-Driven-Development (TDD). Die Softwareentwicklung gilt dann als erfolgreich, wenn diese funktionsfähig ist und den Anforderungen entspricht.

Der Gedanke hinter Behaviour Driven Testing ist also das Testen des Verhaltes einer Software im Vordergrund zu sehen (Blackbox-Testing). Es beschäftigt sich damit “was” die Software leistet und nicht “wie” sie es leistet.

Wie sieht Behaviour Driven Testing in der Praxis aus?

In der Welt der IT gibt's einige Tools, die die Idee von Behaviour Driven Testing verfolgen. Das bekannteste ist Cucumber, das sich der Gherkin-Syntax bedient. In Gherkin ist ein Testfall Teil eines Features, das in Scenarios und Steps (Schritte) unterteilt ist. Ein Feature entspricht einem Anwendungsfall und beinhaltet mehrere Scenarios, die wiederum in Given-, When- und Then-Steps unterteilt sind:

• Given (Precondition): Beschreibt die Vorrausetzung vor dem Test.
• When (Aktion): Beschreibt die Interaktion des Testfalls mit dem Testobjekt, also die Testdurchführung.
• Then (Postcondition): Validiert das Ergebnis mit dem erwartetem Ergebnis.

Diese werden in so genannte Feature-Files zusammengefasst:

 
 Feature: Der Administrator soll die Nutzerdaten dem neuen Benutzer eintragen und abspeichern können.
 Szenario: Der Administrator gibt gültige Nutzdaten ein und speichert diese ab.
 Given: Ich habe mich erfolgreich als Administrator eingeloggt.
 When: Ich trage die Nutzerdaten auf der Registrierungsseite ein und speicher diese ab.
 Then: Sollte der neue Benutzer angelegt sein.
 

Nun stellt sich die Frage in welchem Bereich der Software Behaviour Driven Testing am sinnvollsten genutzt werden sollte. Es macht wenig Sinn beispielsweise Behaviour Driven Testing in Komponententests anzuwenden, da die Implementierung einer einzelner Komponente getestet wird, nicht das Verhalten des Systems. Am Sinnvollsten kommen zwei Bereiche in Betracht:

• UI-Testing: Zum UI-Testing bietet sich Behaviour Driven Testing gut an, da die Fachbereiche ihre Anforderungen meist auf Basis des UI formulieren.
• API-Testing: Wird beispielweise das Backend eines Systems über HTTP-Anfragen getestet, so verleiht Behaviour Driven Testing den Testfällen eine übersichtliche Struktur.
• Qytera Schulung: Behavior Driven Development & Testautomatisierung mit Cucumber

Was sind die Vorteile und Nachteile von Behaviour Driven Testing?

Vorteile:

• Die strukturierte und übersichtliche Testfallbeschreibung von Behaviour Driven Testing sorgt für eine schnellere Qualitätsverbesserung der Software.
• Verbesserung der Kommunikation der Projektteilnehmern untereinander. Das mindert Rücksprachen, was zu Zeitersparnis führt.
• Dokumentation in der ubiquitären Sprache sorgt für besseres gemeinsames Verständnis und mindert somit Produkt- /Projektrisiken.

Nachteile:

• Einarbeitung in eine neue Syntax, die eine Disziplin erfordert, die konsequent umzusetzen ist.
• Anfänglich kommt es zu höheren Aufwänden bei Anforderungsdefinition.
• Die Vorteile von Behaviour Driven Testing kommen erst durch eine einheitliche Verwendung der natürlichen Sprache voll zur Geltung.

Fazit

Die Erfahrung mit Behaviour Driven Testing in Projekten zeigt, dass diese nie zu hundert Prozent angewendet wird. Aber es ist ein guter Ansatz um Projekteilnehmern dazu zu bewegen, sich früh Gedanken über die Testfallbeschreibung der Software vor der eigentlichen Implementierung zu machen. Dies kann den Entwicklungsprozess einer Software beschleunigen, gleichzeitig aber werden Missverständnisse zwischen den Fachbereichen gemindert und somit die gewünschte Funktionalität geliefert, die von den Stakeholdern gewünscht wird.

Image