Requirements Testing

Mit BDD zur gemeinsamen Quelle der Wahrheit

So hab ich das aber nicht gemeint und überhaupt hab ich keine Ahnung, was hier passiert. Wo finde ich die aktuelle Dokumentation?“ Ein Satz, der im Alltag vorkommt und meistens nichts Gutes erahnen lässt. Wie lässt sich vor dem Kundenreview feststellen, ob die Anforderungen richtig verstanden und korrekt umgesetzt wurden?

Pascal Moll

Author

30.04.2024
Lesezeit: 9 Minuten
54 Views

In vergangenen Projekten gab es häufig Missverständnisse bei den Anforderungen und somit war eine falsche Implementierung oftmals die Folge. Dieser Sachverhalt hat sich dann erst beim Review herausgestellt. Nur mit dem Programmcode ausgerüstet wird es im Allgemeinen für das Dev-Team schwierig, mit dem Fachbereich eine gute Diskussionsgrundlage zu schaffen. Oft sind technische Prozesse für die Fachabteilung unverständlich und schwer nachvollziehbar, gleichzeitig ist deren Know-how aber unverzichtbar für den Projekterfolg.

In diesem Artikel zeige ich mithilfe von Behaviour Driven Development, wie Missverständnisse vermieden werden können und dabei eine lebende Dokumentation entsteht. Veranschaulicht wird diese Methode mit dem Werkzeug Cucumber und einem Demo-Onlineshop.

Was genau ist eigentlich BDD

Behaviour Driven Development oder kurz BDD bezeichnet einen szenariogetriebenen Ansatz, bei dem die Beschreibung eines Features für konkrete Testfälle verwendet wird. Ein Vorteil dieser Methode ist das Zusammenbringen aller Stakeholder und Teammitglieder, sowohl mit als auch ohne technischen Hintergrund. Alle Beteiligten können dabei das Verhalten der Software definieren, noch bevor die Programmierung beginnt. Diese Beschreibung erfolgt in für das Team verständlicher Prosa und wird später in Programmcode übersetzt.

BDD ist sowohl vom Framework als auch von der Umgebung unabhängig, dabei ist eines der bekanntesten Werkzeuge zweifelsohne Cucumber.

Was ist Cucumber?

Cucumber ist ein Framework, welches Testszenarien mit der eigene Beschreibungssprache, Gherkin, unterstützt. Cucumber selbst interpretiert die einzelnen Szenarioschritte und verknüpft diese sogenannten Featurefiles mit dem zugehörigen Programmcode, den Stepfiles, wie Abbildung 1 veranschaulicht.

Abb.1: Cucumber-Prozess. FeatureFiles rufen Step-Definitionen auf, die den Testcode beinhalten

Während sich in den Stepfiles der ausführbare Testcode befindet, beinhaltet ein Featurefile die Beschreibung eines Szenarios und die zugehörigen Schritte bei der Durchführung. Dies geschieht mit der Given-When-Then-Syntax.

Given-When-Then: das erste Feature wird beschrieben

Cucumber verwendet die eigene Sprache Gherkin, um Features und zugehörige Szenarien zu beschreiben. Dabei wird dem Feature zuerst ein Name gegeben. Für dieses Beispiel soll ein Loginscreens eines Onlineshops getestet werden (siehe Abbildung 2).

Abb. 2: Loginscreen

Es geht darum, sowohl einen Testfall mit korrekten als auch mit falschen Benutzerdaten durchzuführen. Zu aller erst wird das Feature definiert und mit einem beschreibenden Namen versehen. Anschließend erfolgt die Bennenung des eigentlichen Testfalls in Form eines Szenarios.

Durch das Schlüsselwort Given wird die Vorbedingung festgelegt, also in diesem Beispiel, dass der Benutzer die passende Webseite öffnet, auf der getestet werden soll. Das Schlüsselwort When beschreibt die eigentliche Aktion des Anwenders und das Schlüsselwort Then prüft das erwartete Ergebnis, beispielsweise ob der Login mit gültigen Daten klappt oder fehlschlägt.

Ausgeschrieben und mit Beispieldaten sieht dieser Testfall dann wie in Abbildung 3 aus.

Abb. 3: Testfall in Gherkin

Je nachdem, wieviel Example-Daten hinterlegt wurden, erfolgt eine Durchführung entsprechend oft. In diesem Beispiel wird der Testfall zweimal ausgeführt, einmal mit Benutzer und einmal mit Benutzer2.

Sämtliche Schritte und Testdaten werden in einer Datei hinterlegt, die mit .feature endet, daher auch die Bezeichnung Featurefile. Selbstverständlich können hier weitere Szenarien ergänzt werden, beispielsweise ein Fall, bei dem zusätzlich auch noch die „Remember me“-Checkbox gesetzt wird. Alle Tests für ein gemeinsames Feature sollten sich auch immer im gleichen Featurefile befinden, um die Zugehörigkeit zu signalisieren.

Doch wie entsteht daraus nun ein Testfall mit zugehörigem Ausführungscode?

Stepfiles: der erste ausführbare Code

Cucumber und Gherkin sind für die meisten gängigen Programmiersprachen leicht einsetzbar, mithilfe von passenden Plug-ins unterstützt auch die Entwicklungsumgebung komfortabel mit Codevervollständigung, Einrückungen und weiteren Erleichterungen.

In dem Beispiel Onlineshop kommt als Testframework zusätzlich noch Selenium zum Einsatz, damit lassen sich entsprechende Elemente auf der GUI bedienen. Natürlich sind auch andere Werkzeuge leicht einzubinden und somit ist Cucumber für sämtliche Testarten einsetzbar.

Wie bereits erwähnt, befindet sich in den Stepfiles der ausführbare Testcode, passend zu den vorher definierten Schritten im Featurefile. Cucumber verwendet hier Annotationen, um Methoden auf die entsprechenden Schritte zu mappen. Konkret sieht dies wie in Listing 1 aus.

Listing 1: Annotationen in Stepfile

Somit ist der Schritt „Navigation zur Login-Seite“ mit entsprechender Prüfung ausprogrammiert. Es wird ein neuer Firefoxdriver initialisiert, die vorgegebene URL aufgerufen und die entsprechende Web Page geladen. Anhand des Title-Tags erfolgt noch eine Prüfung, ob denn auch die erwartete Seite mit der aktuellen übereinstimmt.

Diese Ausprogrammierung aller Steps ist nun für sämtliche Schritte notwendig. Entsprechende Plug-ins der Entwicklungsumgebung erleichtern dies allerdings, sodass auf Knopfdruck die entsprechenden Funktionsköpfe bereits generiert werden können (siehe Listing 2).

Listing 2: Ausprogrammierung aller Steps

Somit können auch keine Steps vergessen werden und mühsame Arbeit wird einem erspart.

Parametrisierung in Cucumber

Selbstverständlich ist es in Cucumber auch möglich, mit Variablen zu arbeiten. Somit sind einzelne Testschritte leicht wiederverwendbar und entsprechend flexibel. Variablen können vielseitig angewendet werden, entweder in Form eines einzelnen Datentyps oder direkt als ganze Datentabelle.

Nehmen wir an, die Suchfunktion unseres Onlineshops soll getestet werden, dieses Szenario könnte wie in Listing 3 aussehen.

Listing 3: Test der Suchfunktion unseres Onlineshops

Der blau hinterlegte Text hebt den Parameter hervor. Mithilfe des zugehörigen Codes ist eine Wiederverwendung denkbar einfach:

Ein Tutorium, die ersten Cucumber-Tests

In den Abschnitten zuvor wurden bereits der BDD-Aspekt und die zugehörige Featurebeschreibung erläutert, doch wie sieht nun der vollständige Code zum vorherigen Beispiel mit der Suchfunktion unseres Shops aus? Der Einfachheit halber wurden einige Funktionen zusammengefasst, die sonst in unterschiedliche Unterfunktionen ausgelagert worden wären.

Schritt 1: Given ein Benutzer navigiert erfolgreich zur Startseite

Listing 4 zeigt Schritt 1.

Listing 4: Schritt 1

In diesem Step wird zum einen die Verbindung zum Selenium Driver aufgebaut, die zu testende Seite geladen und geprüft, ob die Zielpage korrekt ist. Die Prüfung erfolgt durch einen Vergleich des Pagetitels. Treten hier keine Fehler auf, folgt direkt Schritt 2.

Schritt 2: When Benutzer gibt Begriff {string} ins Suchfeld ein

Im zweiten Step (siehe Listing 5) kommt die zuvor eingeführte Variable zum Tragen.

Listing 5: Schritt 2

Der Suchbegriff wird in der Variable searchterm abgelegt und via Selenium in das Suchfeld unseres Shop eingetragen. Anschließend erfolgt das Absenden der Suche durch einen Klick auf den OK-Button und die Ergebnisprüfung in Step 3 wird eingeleitet.

Schritt 3 hat je nach Testfall zwei Ausgangspunkte. Entweder wird erwartet, dass kein Ergebnis gefunden wurde, oder mindestens eines.

Schritt 3a: Benutzer findet mindestens ein Ergebnis

Betrachten wir zunächst den Fall, in dem mindestens ein Ergebnis gefunden wurde. Wie in den meisten Tests gibt es mehrere Möglichkeiten, dies zu prüfen. Eine einfache Variante ist der Vergleich des Title-Tags. Bei keinem Ergebnis existiert hier ein anderer (siehe Listing 6).

Listing 6: Schritt 3a

Somit wird der Title-Tag ausgelesen und mit einem definierten String verglichen.

Nahezu identisch ist das Vorgehen in Schritt 3b.

Schritt 3b: Benutzer findet kein Ergebnis

Der einzige Unterschied in Listing 7 zu Schritt 3a ist der Vergleich des Title-Tags, denn hier wird schlicht nur auf den Titel „NICHTS GEFUNDEN“ verglichen und damit gilt der Test als erfolgreich.

Listing 7: Schritt 3b

Vor- und Nachteile von BDD und Cucumber

Wie bei allen Methoden und Werkzeugen existieren auch hier einige Vor- und Nachteile. BDD fördert die Zusammenarbeit aller Projektbeteiligten und die Kommunikation. Durch die gemeinsame Sprache ist für jeden ersichtlich, was bei den einzelnen Testschritten geschieht, und alle können mitreden. Dadurch lassen sich Fehler und Unklarheiten frühzeitig erkennen und beheben. Gerade durch die Featurefiles entsteht eine Dokumentation, die nie veralten kann, da sie auch die Basis des Testcodes bildet. Dies bringt auch Sicherheit bei der Softwareentwicklung und sorgt für Vertrauen, das Richtige zu entwickeln.

Dem gegenüber stehen jedoch vergleichsweise hohe Initialkosten. Die Grundstruktur muss geschaffen werden und die beteiligten Personen müssen sich auch darauf einlassen. Teams, in denen Spannungen herrschen, werden dadurch auch nicht mehr kommunizieren, was gerade bei diesem Ansatz hinderlich ist.

Fazit und Schlusswort

In diesem Artikel wurden die Grundlagen von BDD vorgestellt und die Vor- und Nachteile aufgezeigt. Anhand des Beispiels eines Onlineshops wurde diese Methode mit dem Werkzeug Cucumber näher gebracht. Selbstverständlich bietet Cucumber noch weitaus mehr Features und ist zudem durch Plug-ins erweiterbar. Nicht behandelt wurde zum Beispiel die Integration in eine DevOps-Umgebung oder das automatische Erstellen verschiedenster Reports.

Aus meiner persönlichen Erfahrung kann ich diese Methode nur empfehlen, da sie die Zusammenarbeit aller Beteiligten fördert und entsprechende Testschritte überschaubar darstellt, es lässt sich somit eine gemeinsame Quelle der Wahrheit erschaffen.