Das Behaviour Driven Development in agilen Projekten der Automobilbranche. Ein Vergleich mit den Techniken Cucumber und Spock

Textbook , 2021 , 78 Pages

Computer Science - Commercial Information Technology

Softwaretests werden in der Automobilbranche zunehmend automatisiert. Das Behaviour Driven Development ist eine Technik der agilen Softwareentwicklung, die automatisierte Tests ermöglicht. Dabei wählen Softwareentwickler Testwerkzeuge nach bestimmten Prinzipien aus und wenden diese bei Tests wie dem Akzeptanztest an.

Aber welches Framework eignet sich zur Automatisierung von Akzeptanztests? Welche Probleme ergeben sich beim Einsatz von Werkzeugen des Behaviour Driven Development? Und welche Kriterien sind bei der Auswahl eines Testframeworks wichtig?

Pascal Mödinger vergleicht anhand eines Testszenarios die Tools Cucumber und Spock miteinander. Er implementiert diese und prüft nach ausgewählten Kriterien, welches Framework sich zur Automatisierung von Akzeptanztests besser eignet.

Aus dem Inhalt:
- Behaviour Driven Development;
- Agile Projekte;
- Softwaretest;
- Akzeptanztest;
- Automobilbranche;
- Testautomatisierung

Inhaltsverzeichnis

Abstract

Inhaltsverzeichnis

1 Einleitung, Motivation und Überblick

2 Problemstellung und Forschungsfrage

3 State of the Art von Softwaretesting
3.1 Testautomatisierung
3.2 Test Driven Development (TDD)
3.3 Behaviour Driven Development (BDD)
3.4 Unterschied zwischen TDD und BDD
3.5 Aktuelle Forschungsarbeiten zu dem Thema

4 Methodisches Vorgehen

5 Ergebnis
5.1 Vorstellung und Auswahl der BDD-Frameworks
5.2 Testszenario
5.3 Kriterienkatalog
5.4 Ergebnisse der Implementierung mit Cucumber
5.5 Ergebnisse der Implementierung mit Spock
5.6 Vergleich der Frameworks

6 Fazit
6.1 Zusammenfassung
6.2 Limitations
6.3 Next Steps
6.4 Lessions Learned
6.5 Contribution to Practice
6.6 Contribution to Science

Abbildungsverzeichnis

Tabellenverzeichnis

Literaturverzeichnis

Anhang

Abstract

Das Ziel dieser Arbeit ist es herauszufinden, was die Probleme beim Automatisieren von Tests nach den Behaviour Driven Development (BDD) Prinzipien sind und welches Testwerkzeug sich für die Automatisierung am besten eignet. Zudem soll herausgefunden werden, welche Kriterien wichtig für die Auswahl von Testtools sind. Dazu wird folgende Forschungsfrage aufgestellt: „Welches Behaviour Driven Development Framework eignet sich zur Automatisierung von Akzeptanztests am besten?“. Zur Beantwortung der Forschungsfrage werden noch die Fragen, „Welche Probleme gibt es bei dem Einsatz von BDD-Tools in agilen Softwareprojekten?“ und „Welche Kriterien sind bei der Auswahl eines Testframeworks wichtig?“ in dieser Arbeit aufgegriffen und bearbeitet. Zur Beantwortung dieser Fragen wird eine Online-Umfrage durchgeführt, um die Problemstellungen beim Einsatz von BDD-Frameworks herauszufinden. Die BDD-Frameworks werden anhand eines Testszenarios implementiert und mit aufgestellten Kriterien verglichen, die aus den Problemstellungen herausgearbeitet werden. Für den Vergleich werden die Frameworks Cucumber und Spock ausgewählt. Der durchgeführte Vergleich hat ergeben, dass sich Cucumber im Rahmen des aufgestellten Testszenarios besser als Spock für die Testautomatisierung eignet. Die Online-Umfrage hat gezeigt, welche Probleme beim Testen auftreten. Beispielsweise werden Testdaten in den Testfällen eingebaut, wodurch Änderungen der Testdaten sehr viel Aufwand nach sich ziehen. Aber auch eine fehlende oder schlechte Möglichkeit der Darstellung der Testfallergebnisse wurde unter anderem als Problem bei der durchgeführten Umfrage deutlich. Die Gewichtung aufgestellter Kategorien für den Vergleich hat gezeigt, dass eine gute Auswertung der Ergebnisse ausschlaggebend für die Wahl eines Frameworks zur Testautomatisierung ist. Aufgrund der Ergebnisse empfiehlt sich die Wahl eines Frameworks, welches verschiedene und umfassende Möglichkeiten bietet um die Testergebnisse anzuzeigen.

1 Einleitung, Motivation und Überblick

Behaviour Driven Development (BDD) ist sowohl in der Forschung als auch in der Praxis ein relevantes Thema. Besonders in Projekten, die nach agilen Projektmanagementmethoden vorgehen hat BDD in den vergangenen Jahren immer mehr an Bedeutung gewonnen. Es gibt mittlerweile eine Vielzahl an Testwerkzeugen, die bei der Testautomatisierung von Softwaretests nach den BDD Prinzipien herangezogen werden können. Dabei ist es nicht immer einfach, ein Werkzeug für die speziellen Anforderungen in einem Projekt auszuwählen. Bei der Auswahl eines Testwerkzeuges ist auch darauf zu achten, welche Ebene von Softwaretests automatisiert werden soll. Diese Arbeit soll einen Überblick über gängige Tools zur Testautomatisierung nach den BDD-Prinzipien geben und bei der Auswahl eines Behaviour Driven Development Frameworks helfen. Dazu werden in dieser Arbeit verschiedene BDD-Tools miteinander verglichen.

Aktuell gibt es in dem Projekt die Herausforderung mit der Automatisierung der Softwaretests. In diesem Projekt für die Arbeit wird ein Konfigurator für KFZ-Fahrzeuge entwickelt. Dieser Konfigurator stellt verschieden Schnittstellen zur Verfügung, die beispielsweise den Preis und die Emissionswerte für ein konfiguriertes Fahrzeug errechnen und zurückgeben. Die eigens entwickelten Funktionen des Konfigurators sollen entsprechend mit Akzeptanztests abgedeckt werden. Ein Akzeptanztest ist eine bestimmte Art von Softwaretest und wird zu einem späteren Zeitpunkt in Kapitel 3.1.2 noch genauer vorgestellt. Derzeit werden noch viele Akzeptanztests der Konfigurator-Software manuell ausgeführt. Dabei müssen teilweise die Preise für konfigurierte Fahrzeug noch manuell errechnet, und mit dem richtigen Preis abgeglichen werden. Für den implementierten Konfigurator wurden aber auch schon einige Akzeptanztests mit dem Behaviour Driven Development (BDD) Werkzeug Cucumber automatisiert. Allerdings schlagen die bereits automatisierten Tests fehl, wenn veraltete Testdaten verwendet werden. In dem entwickelten Konfigurator werden sehr häufig neue Fahrzeugkonfigurationen hinzugefügt und veraltete Fahrzeuge entfernt. Diese veralteten Konfigurationen von Fahrzeugen müssen sehr zeitaufwändig manuell entfernt und mit neuen, gültigen Fahrzeugkonfigurationen ersetzt werden.

Zu Beginn dieser Arbeit wird beschrieben, welche Vorteile Testautomatisierung von Softwaretests gerade in Agilen Projekten mit sich bringt. Danach werden in Kapitel 3.1.1 die verschiedenen Testebenen, in die Softwaretests unterschieden werden können, vorgestellt. Da in dieser Arbeit Akzeptanztests im Mittelpunkt der Testautomatisierung stehen, werden diese noch einmal gesondert näher vorgestellt. In Kapitel 3.1.3 wird aufgezeigt, was es bei der Testautomatisierung in agilen Projekten zu beachten gilt. Dabei wird auch der Bezug zur Problemstellung dieser Arbeit deutlich. Anschließend werden die beiden Ansätze Test Driven Development und Behaviour Driven Development und deren Unterschiede vorgestellt. In Kapitel 4 wird das methodische Vorgehen dieser Arbeit beschrieben. Danach wird eine Übersicht über die gängigsten Tools, die den Ansatz BDD verfolgen, gegeben. Dazu werden die Frameworks sowie die Stärken und Schwächen in einseitigen Factsheets beschrieben. Zwei Factsheets sind in Kapitel 5.1 abgebildet. Weiter Factsheets von BDD-Frameworks sind im Anhang abgebildet. Anhand dieser Factsheets werden die Frameworks für den Vergleich ausgesucht. In Kapitel 5.2 wird ein Testszenario beschrieben. Dieses Testszenario wird mit den zu vergleichenden BDD-Tools implementiert. Im darauffolgenden Abschnitt wird ein Kriterienkatalog beschrieben. Die darin enthaltenen Kriterien sind mithilfe einer Umfrage erarbeitet worden. An der Umfrage haben Entwickler teilgenommen die bereits Erfahrung mit BDD-Tools haben. Daneben sind dem Kriterienkatalog weitere Kriterien hinzugefügt worden, die durch die Literaturrecherche ebenfalls als wichtig erachtet werden. In Kapitel 5.4 und Kapitel 5.5 sind die Ergebnisse der Implementierung des Cucumber und des Spock Frameworks abgebildet. Anhand der Ergebnisse aus der Implementierung und den festgelegten Kriterien entsteht ein Vergleich der Frameworks, der in Kapitel 5.6 aufgeführt wird. Der Vergleich der Frameworks wird mithilfe einer Nutzwertanalyse durchgeführt. Zum Abschluss dieser Arbeit wird noch ein Fazit in Kapitel 6 gegeben. Dieses beinhaltet zu Beginn eine Zusammenfassung der Hauptereignisse mit anschließendem Aufzeigen der Einschränkungen und der nächsten Schritte dieser Arbeit. Was es bei einem erneuten Vergleich von verschiedenen Frameworks zu beachten gibt, wird in Kapitel 6.4 gezeigt. Die beiden letzten Punkte dieser Arbeit erläutern anschließend, welchen Beitrag diese Arbeit zur Praxis und Forschung liefert.

2 Problemstellung und Forschungsfrage

Es gibt mittlerweile viele Tools, die nach den BDD Prinzipien die Testautomatisierung ermöglichen. Aber nicht jedes dieser Werkzeuge eignet sich für die Anforderungen in einem Projekt. In dem aktuellen Projekt soll eine Software mit Akzeptanztests nach den BDD Prinzipien getestet werden. Dabei tritt das Problem auf, dass immer wieder bereits automatisierte Tests aufgrund veralteter Testdaten fehlschlagen. Auch werden einige Tests noch manuell ausgeführt und auf Richtigkeit überprüft. Die Wahl des richtigen Frameworks für die Bedürfnisse eines Projektes ist nicht immer leicht zu treffen. Diese Arbeit beschäftigt sich mit der Forschungsfrage: „Welches Behaviour Driven Development Framework eignet sich zur Automatisierung von Akzeptanztests am besten?“. Zur Beantwortung der Forschungsfrage werden noch die Fragen, „Welche Probleme gibt es bei dem Einsatz von BDD-Tools in agilen Softwareprojekten?“ und „Welche Kriterien sind bei der Auswahl eines Testframeworks wichtig?“ aufgegriffen und bearbeitet.

3 State of the Art von Softwaretesting

3.1 Testautomatisierung

Das manuelle Testen von Software kostet viel Zeit und nicht zuletzt Geld. Ohne das Testen von Software ist es nur schwer möglich, Software mit guter bis sehr guter Qualität auszuliefern. Zudem muss theoretisch bei jeder Änderung an der Software die Funktionalität erneut manuell getestet werden. Nur so lässt sich die Qualität sicherstellen. Um das zu vereinfachen bzw. zu verhindern können wiederholt auftretende Testfälle automatisiert werden (Witte, 2016). Witte hat in seinem Buch „Testmanagement und Softwaretest“ die Unterschiede zwischen manueller und automatisierter Ausführung von Softwaretests, wie in Tabelle 1 dargestellt, beschrieben. Besonders bei Softwareprojekten mit vielen Releases, bei denen immer wieder die Basisfunktionalitäten getestet werden, lohnen sich die Maßnahmen der Testautomatisierung (Witte, 2016).

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Vergleich manueller und automatisierter Testdurchführung (Witte, 2016)

Die Entwicklung einer Software ist in verschiedene Abschnitte, sogenannte Releases unterteilt (Henning & Bleek, 2011). Bei jedem Release werden dem Softwareprodukt neue Funktionen hinzugefügt (Henning & Bleek, 2011). Viele Releases sind vor allem in agilen Entwicklungsmethoden wie Scrum oder Kanban wiederzufinden. Wie Frank Witte (2016) feststellt, ist die manuelle Testdurchführung in agilen Projekten wie Scrum oder Kanban nicht möglich. Zu groß ist der Testaufwand, der in jeder Iteration wiederholt werden muss. Nur durch die Automatisierung von Tests mithilfe von unterschiedlichsten Werkzeugen ist die konsequente Entwicklung mit agilen Vorgehensmethoden erst möglich geworden (Baumgartner, 2018). Das Automatisieren von Tests bringt aber auch neue Aufgaben mit sich. Neben dem Schreiben des Testskripts müssen die einzelnen Testruns auch richtig konfiguriert und die Testergebnisse nachträglich dokumentiert, abgelegt und richtig interpretiert werden (Witte, 2016). Der Automatisierungsaufwand von Test hängt mit der Art des zu automatisierenden Tests zusammen. Mike Cohn (2010) beschrieb mit dem Konzept der Testpyramide die ungefähre Verteilung der Arten von Tests in einem Softwareprojekt. In Abbildung 1 ist die Testpyramide dargestellt. Demnach sollen mehr einfach zu automatisierende Unit Tests erstellt werden und mit zunehmender Komplexität der Tests dann auch immer weniger Testfälle geschrieben werden (Cohn, 2010). Tests die beispielsweise das komplette System über Eingaben im User Interface testen, sind sehr komplex und aufwändig zu automatisieren. Im Folgenden Abschnitt werden die einzelnen Testebenen beschrieben, anhand der Tests unterschieden werden können.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Testpyramide nach Mike Cohn (Cohn, 2010)

3.1.1 Testebenen

Softwaretest können in unterschiedliche Ebenen oder auch Stufen unterteilt werden. Es gibt durchaus unterschiedliche Bezeichnungen für die einzelnen Ebenen. Je nachdem welchen Umfang des Systems der Test abdeckt, kann dieser in die Ebene des Komponententests, Integrationstests oder Systemtests eingeteilt werden (Middeke, 2007). In Abbildung 2 sind die Testebenen von Softwaretests dargestellt. Darauf ist zu erkennen, dass sich die gerade vorgestellten Arten von Tests nach dem Umfang der abgedeckten Funktionalität unterscheiden. Wie schon der Name verrät werden bei Komponententests einzelne Komponenten des Systems getestet (Middeke, 2007). In der Objektorientierung ist eine einzelne Komponente einfach gesagt eine Klasse oder auch eine Funktion einer Klasse. Integrationstest sind auf das Zusammenspiel mehrerer Klassen untereinander fokussiert (Middeke, 2007). Auch bei einem Systemtest wird das Zusammenspiel mehrerer Klassen bzw. die Funktionsweise des ganzen Systems betrachtet. Der wesentliche Unterschied zu einem Integrationstest besteht allerdings in der Sichtweise des Tests (Middeke, 2007). Der Tester prüft hier aus Sicht des Anwenders, ob dessen Erwartungen erfüllt werden. Zusätzlich zu diesen drei Testebenen gibt es noch zwei besondere Testarten, die auf allen Testebenen durchgeführt werden können. Bei Änderungen an einzelnen Komponenten sind Regressionstests notwendig. Diese sollen nachweisen, dass durch die Änderungen keine neuen Fehler an bereits getesteten Funktionen der Software entstanden sind (Middeke, 2007). In agilen Vorgehensmodellen muss die in vorangegangenen Iterationen geschaffenen Funktionen nach jeder Iteration mit umfangreichen Regressionstests erneut getestet werden (Baumgartner, 2018).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Testebenen von Softwaretests

Iterationen sind kurze immer wiederkehrende Zeiteinheiten innerhalb deren eine detaillierte Planung der nächsten Arbeitsschritte erfolgt (Henning & Bleek, 2011). Die zweite Art von Test, die auf allen drei Testebenen durchgeführt wird, ist der Akzeptanztest. Dieser wird auch als Abnahmetest, Verfahrenstest oder auch User Acceptance Test bezeichnet (Witte, 2016). In Abbildung 2 ist ebenfalls zu erkennen, dass die beiden besonderen Testarten auf allen Ebenen von Tests erstellt werden können. Da in der bereits beschriebenen Problemstellung in Kapitel 2 die Akzeptanztests betroffen sind, werden diese in dem folgenden Kapitel genauer beleuchtet.

3.1.2 Akzeptanztests

Wie bereits in Kapitel 3.1.1 beschrieben, kann ein Akzeptanztest auf allen drei Testebenen ausgeführt werden. Der Akzeptanztest dient nicht mehr dazu Fehler der Software aufzudecken. Er soll zeigen, dass die Software die vereinbarten Funktionen aus Sicht des Kunden erfüllt (Witte, 2016). In agilen Vorgehensmodellen, wie beispielsweise Scrum, ist es nicht unüblich, dass Akzeptanztests in Iterationen mit aufgenommen werden. Akzeptanztests werden am besten direkt vom Kunden selbst formuliert. Diese kennen die geforderten Anforderungen und haben nicht den rein technischen Blick auf die Software wie die Entwickler der Software. Ein häufiges Problem das dabei auftritt, sind die fehlenden Programmierkenntnisse des Kunden bzw. der Fachabteilung (Middeke, 2007). Der Ansatz des Behaviour Driven Development, wie er in Kapitel 3.3 vorgestellt wird, schafft dafür Abhilfe. Dabei werden Tests in natürlicher Sprache formuliert. So kann der Fachexperte auch ohne Programmierkenntnisse die Tests für die gewünschten Anforderungen der Software selbst schreiben. Die in Kapitel 5.1 vorgestellten Frameworks setzen den Ansatz des Behaviour Driven Development um und machen die in natürlicher Sprache formulierten Test ausführbar. So kann der Test direkt vom Fachexperten, der die entsprechende Anforderung an die Software hat, geschrieben werden. Der Umfang der durchzuführenden Akzeptanztests hängt von der Art der Software ab. Bei der Entwicklung von Individualsoftware für den Kunden sind mehr Akzeptanztests notwendig wie bei der Einführung von Standardsoftware (Spillner, 2012).

3.1.3 Zu beachtenden Themen bei der Testautomatisierung

Um langfristig mit der Testautomatisierung in agilen Projekten Erfolg zu haben, gibt es einige Dinge zu beachten. Manfred Baumgartner beschreibt in seinem Buch „Agile Testing“ sieben schlechte Ideen für die Testautomatisierung. Häufig werden aus Kostengründen Testwerkzeuge unternehmensweit eingeführt und eingesetzt (Baumgartner, 2018). Da aber die einzelnen Projekte unterschiedliche Anforderungen an das Testwerkzeug haben, kann sich schnell herausstellen, dass das Werkzeug an sich eine gute Lösung ist, aber nicht das eigentliche Problem in einem Projekt ansteuert (Baumgartner, 2018). Die Auswahl des Testwerkzeuges sollte daher nach den eigenen Anforderungen im Projekt ausgewählt werden. Keinesfalls soll ein Testwerkzeug nur verwendet werden, weil es in vielen Projekten verwendet wird (Baumgartner, 2018). Daneben sollten in agilen Projekten keinesfalls Testdaten in den Tests selbst stehen (Baumgartner, 2018). Wie in der Problemstellung dieser Arbeit beschrieben ist es ein enormer Aufwand, wenn Tests wegen veralteter Daten angepasst werden müssen. Diesen Aufwand gilt es so gut wie möglich zu vermeiden. Um das zu erreichen sollten die Testdaten zentral in Testdatentabellen oder anderen alternativen Dateien verwaltet werden (Baumgartner, 2018). So müssen Änderungen nur einmal und nicht an jedem Test einzeln vorgenommen werden. Weitere Fehler die es bei der Testautomatisierung zu beachten gibt, werden in dem Buch „Agile Testing“ von Manfred Baumgartner beschrieben. Dort werden auch Empfehlungen für die jeweiligen Probleme, die dadurch entstehen, gegeben.

3.2 Test Driven Development (TDD)

Test Driven Development (TDD) ist eine Methode der Softwareentwicklung, bei der zuerst der Test geschrieben wird, bevor der eigentliche Code der getestet werden soll geschrieben wird (Chelimsky, 2010). Der Prozess des Test-Driven Development besteht vereinfacht aus folgenden drei Schritten (Osherove, 2015):

1. Schreibe einen Test der fehlschlägt.
2. Füge dem Programmcode die fehlende Funktionalität hinzu.
3. Refactoring des implementierten Codes.

Diese drei Schritte laufen dann wie folgt ab. Zuerst wir der Test geschrieben.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Test Driven Development (TDD) - Ablauf der einzelnen Schritte dargestellt in einem Aktivitätsdiagramm

Dieser Test wird dann ausgeführt und schlägt fehl, da der zu testende Code noch nicht existiert. Im nächsten Schritt wird der fehlende Code zu dem Test implementiert. Dies wird solange wiederholt, bis der Test funktioniert. Nach erfolgreicher Durchführung des Tests wird der Code Refactored. Das bedeutet, dass der Code zwar verändert wird, die Funktionalität jedoch bleibt gleich (Osherove, 2015). In diesem Fall soll sämtlicher überflüssiger Code und Duplikationen im Test und im Code selbst entfernt werden. Funktioniert der Test und ist kein Refactoring mehr notwendig, so kann ein neuer Test geschrieben werden. Dieser Vorgang wird solange wiederholt bis alle Funktionen implementiert sind. Ziel des Test Driven Developments ist es sauberen und funktionierenden Code zu schreiben (Beck, 2003). Roy Osherove beschreibt in seinem Buch „The Art of Unit Testing“ mehrere Vorteile des Test Driven Development. So hat die Software beispielsweise eine höhere Code-Qualität und weniger Bugs im Code (Osherove, 2015). Auch das Vertrauen der Entwickler in den Code ist größer und dadurch, dass die Tests zuerst geschrieben werden, hat sich das Code-Design verbessert (Osherove, 2015). Um mehr über Test-Driven Development und dessen Anwendung zu erfahren ist das Buch „Test-driven Development: by example“ von Kent Beck zu empfehlen. In wird der Prozess des Test Driven Developments mit den notwendigen Zwischenschritten noch einmal bildlich dargestellt.

3.3 Behaviour Driven Development (BDD)

Behaviour Driven Development wurde zuerst im Jahr 2003 von Dan North als Antwort auf häufig auftretende Probleme und Fragen mit dem Ansatz des Test Driven Development vorgestellt (North, 2006). Der Ansatz des TDD wurde bereits in Kapitel 3.2 vorgestellt. Dan North entwickelte das BDD Framework JBehave (North, 2006). Dieses Framework testet das Verhalten der Software (North, 2006). David Chelimsky (2010) beschrieb das Problem des Test Driven Development in seinem Buch The RSpec Book wie folgt:

„The problem with testing an object´s internal structure is that we´re testing what an object is instead of what it does. What an object does is significantly more important.”

Stakeholder haben kein primäres Interesse daran, wie etwas umgesetzt wird sondern nur, dass es richtig umgesetzt wird (Chelimsky, 2010). Behaviour Driven Development fokussiert das Verhalten der Software und nicht die interne Struktur der Software (Chelimsky, 2010). Bei Entwicklern die Test Driven Development anwenden, kommen häufig die Fragen auf, wo mit der Entwicklung gestartet werden soll und wie die Tests benannt werden sollen (North, 2006). Oft fehlt auch das klare Verständnis der Entwickler warum ein Test fehlschlägt (North, 2006). Diese auftretenden Fragen sollen mit dem Ansatz des Behaviour Driven Development beantwortet werden. Demnach soll mit dem Feature gestartet werden, das den größten Geschäftswert für die Software liefert (North, 2006). Die Priorisierung der Features verhindert, dass unnötige Zusatzfunktionen vor wichtigen Funktionen, die etwas zu dem Geschäftswert der Software beitragen, implementiert werden. Auch die Namengebung ist beim BDD anders als beim TDD. Die Namen der Tests sollen ganze Sätze bilden um die Lesbarkeit der Tests zu verbessern (North, 2006). Dabei wird das Wort „test“ zu Beginn der Methode entfernt und die darauffolgenden Wörter im Camel-Case in ganze Sätze formatiert (North, 2006). Diese klare Benennung der Testfälle hilft bei dem Verständnis, warum bestimmte Tests fehlschlagen. Durch die ganzen Sätze sagen die Testnamen eindeutig aus, welches Verhalten der Software getestet wird und somit auch fehlschlägt oder funktioniert.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2: Drei Gründe warum Tests fehlschlagen nach Dan North

Nach Dan North (2006) gibt es drei verschiedene Möglichkeiten warum Tests fehlschlagen und dazu Lösungen, was bei jeder Möglichkeit zu tun ist. Diese drei Möglichkeiten werden in Tabelle 2 dargestellt. Zusätzlich nutzt BDD zur Formulierung von Tests eine natürliche Sprache. Durch die Verwendung von natürlicher Sprache, die auch der Geschäftsbereich versteht ist der formulierte Test auch für außenstehende und nicht nur für die Entwickler verständlich (North, 2006). Diese Art der Sprache nennt sich Domain Specific Language (Abhishek, 2017). Die Zusammenarbeit und Kommunikation zwischen den technischen und nicht technischen Teilnehmern am Projekt wird so einfacher (North, 2006). Dabei werden die Akzeptanzkriterien von User Stories verwendet und ausführbar gemacht. Die Akzeptanzkriterien beschreiben das geforderte Verhalten der Software. Das hat den Vorteil, dass Änderungen der Akzeptanzkriterien in der User Story auch automatisch die automatisierten Tests ändern (Baumgartner, 2018). Das Verhalten der Software wird in sogenannten Szenarien beschrieben. Szenarien sind beispielsweise mit den Wörtern Given, When und Then aufgebaut und werden von jedem Projektteilnehmer gleichermaßen verstanden (Chelimsky, 2010). In Abbildung 4 ist die Bedeutung der einzelnen Wörter dargestellt. Wie später in Kapitel 5.4 zu sehen sein wird, nutzt Cucumber diese Art des Aufbaus von Testszenarien.

Das Wort „Given“ ist der Vorbereitungsschritt, mit dem das System in den gewünschten Zustand gebracht wird um getestet werden zu können. In einem einfachen Beispiel, in dem der Inhalt von Strings überprüft werden soll, wird hier der String initialisiert. Mit dem Wort „When“ wird die Benutzerinteraktion der zu testenden Funktionalität ausgeführt. Es muss hier aber nicht zwingen eine Benutzerinteraktion sein. Sehr einfach gedacht und an das Beispiel von gerade angelehnt, wird hier die Methode aufgerufen, die den String beispielsweise in Großbuchstaben umwandelt. Mit dem Wort „Then“ wird dann das erwartete Ergebnis mit dem tatsächlichen Ergebnis verglichen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Aufbau eines Szenarios mit den Wörtern Given, When und Then.

3.4 Unterschied zwischen TDD und BDD

Wie bereits in Kapitel 3.3 beschrieben, wurde Behaviour Driven Development als Antwort von Dan North auf die Probleme, die Tester mit dem Ansatz Test Driven Development haben, entwickelt. BDD Tests werden in einem anderen Detail geschrieben als Test im TDD (Abhishek, 2017). Der Ansatz des Test Driven Development, wie er in Kapitel 3.2 vorgestellt wurde, zielt darauf ab einzelne Funktionen aus technischer Sicht zu testen. Die Tests zielen in viel größerem Detail darauf ab, wie die technische Umsetzung der Software aussieht. Der eigentliche Geschäftswert den der Teil der Software liefert, wird aus dem Test nicht ersichtlich. Für Außenstehende ist es daher schwer erkennbar, was da gerade getestet wird. Beim Ansatz des Behaviour Driven Development hingegen wird das Verhalten der Software getestet. Dieses Verhalten wird von den Geschäftsanforderungen abgeleitet (Abhishek, 2017). Die Tests beschreiben im Gegenteil zum TDD nicht wie etwas technisch umgesetzt wird, sondern nur das die Funktionalität vorhanden ist. Durch die Formulierung der Tests in der sogenannten Domain Specific Language (DSL) ist der Test auch für außenstehende aus dem Geschäftsbereich verständlich (Abhishek, 2017). In Tabelle 3 sind die soeben beschriebenen Unterschiede tabellarisch dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3: Unterschiede zwischen TDD und BDD

3.5 Aktuelle Forschungsarbeiten zu dem Thema

Es gibt mehrere Forschungsarbeiten zu der Thematik Behaviour Driven Development. In der Arbeit von Binamungu, Embury und Konstantinou (2018b) wurden die Chancen und Herausforderungen von BDD herausgearbeitet. Zudem konnte festgestellt werden, dass auch in Zukunft BDD eine große Rolle spielen wird. In der Arbeit wird zudem auch herausgefunden, welche Frameworks aktuell am meisten verwendet werden (Binamungu, et al., 2018b). Als Vorteile beim Einsatz von BDD konnte die Verständlichkeit der Spezifikationen von Endnutzern und die dadurch resultierende bessere Kommunikation unter den Projektteilnehmern herausgefunden werden (Binamungu, et al., 2018b). Die Herausforderungen von BDD liegen vor allem in der Veränderung des Ansatzes der Softwareentwicklung und darin, dass die Vorteile von BDD hart zu quantifizieren sind (Binamungu, et al., 2018b).

Zwei Arbeiten befassen sich mit dem Vergleich von BDD-Toolkits. Die Arbeit von Solís und Wang (2011) liefert ein grundsätzliches Verständnis über BDD und zeigt dessen Charakteristiken auf. Anschließend wird gezeigt welche BDD-Toolkits diese Charakteristiken aufgreifen (Solís & Wang, 2011). Okolnychyi und Fögen (2016) befassen sich in ihrer Arbeit „A Study of Tools for Behavior-Driven Development“ ebenfalls mit mehreren BDD-Tools für die Java Welt. Diese werden anhand der unterstützen Features miteinander verglichen. Die Arbeit kam zu dem Ergebnis, dass Spock und easyb eher für das Testen auf Unit-Level und JBehave, Concordion und Cucumber für Integrations- und Akzeptanztests ausgelegt sind (Okolnychyi & Fögen, 2016).

Rai (2016) befasst sich mit der Durchführbarkeit des Akzeptanztestens nach den BDD-Prinzipien und der Verständlichkeit und Erlernbarkeit der Sprache Gherkin. Die Forschungsarbeit zeigt, dass es für Personen mit wenigen bis mittleren Programmierkenntnissen einfach ist, die Anforderungen des Kunden in ausführbare Spezifikationen nach den BDD-Prinzipien zu übersetzen (Rai, 2016). Zudem zeigt die Arbeit, dass die Mehrheit der Personen, die beruflich keine Programmierer sind, die Sprache Gherkin gut erlernbar und gut verständlich finden (Rai, 2016).

Die Arbeiten von Rahman und Goa (2015) und Shafiee, et al. (2018) befassen sich mit dem Einsatz von BDD in Projekten mit bestimmten Problemstellungen. Rahman und Gao (2015) greifen das Problem auf, dass der Einsatz eines BDD-Testframeworks in einer Microservice-Architektur mit sich bringt. Das Ergebnis der Arbeit ist ein wiederverwendbarer Prototyp zur Automatisierung von Akzeptanztests in einer Microservice-Architektur (Rahman & Gao, 2015). Die Forschungsarbeit „Behaviour-Driven Development in Product Configuration Systems“ versucht einen Ansatz zu entwickeln, in dem BDD in den Entwicklungsprozess von Produktkonfigurierungssystemen unter Verwendung von Scrum-Methoden mit einbezogen wird (Shafiee, et al., 2018).

In der Forschungsarbeit „Detecting Duplicate Examples in Behaviour Driven Development Specifications“ wir ein neuer Ansatz entwickelt, der Duplikationen in BDD-Spezifikationen erkennen soll (Binamungu, et al., 2018a). Die Arbeit zeigt, dass bestehende Tools noch Schwierigkeiten haben, Duplikationen zu erkennen (Binamungu, et al., 2018a). Mit dem neu entwickelten Ansatz werden die Duplikationen in den Spezifikationen wesentlich besser erkannt (Binamungu, et al., 2018a).

Im Anhang sind die erwähnten Forschungsarbeiten noch einmal in Tabelle 9 alphabetisch nach Autoren und den eingeteilten Kategorien aufgelistet und beschreiben. Alle vorgestellten Arbeiten beziehen sich auf den Ansatz des Behaviour Driven Developments. Teilweise werden auch schon Tools für die Testautomatisierung miteinander verglichen. Allerdings werden diese Testwerkzeuge nicht anhand der Implementierung eines konkreten Testszenarios verglichen. Die Arbeit von Okolnychyi und Fögen (2016) vergleicht die Testwerkzeuge anhand der allgemeinen Charakteristiken von Behaviour Driven Development. Solís und Wang (2011) gibt einen Überblick welche BDD-Toolkits Behaviour Driven Development am besten umsetzen. Diese Arbeit ergänzt diese beiden Arbeiten in dem BDD-Tools anhand von konkreten Problemstellungen, die in Projekten auftreten, verglichen werden.

All diese Forschungsarbeiten stehen im Zusammenhang mit dieser Arbeit. Einige der Arbeiten haben ebenfalls schon BDD-Tools miteinander verglichen. Andere versuchen die aktuellen Schwierigkeiten von BDD herauszufinden oder entwickeln dafür Lösungen. Diese Arbeit stellt gewissermaßen eine Ergänzung dar. Wie in der Problemstellung in Kapitel 2 beschrieben, werden Frameworks anhand eines implementierten Testszenarios miteinander verglichen.

4 Methodisches Vorgehen

In dieser Arbeit werden zwei Behaviour Driven Development Frameworks miteinander verglichen. Das methodische Vorgehen dazu ist in Abbildung 5 dargestellt. Der zentrale Punkt für den Vergleich ist ein aufgestelltes Testszenario. Das Testszenario ist die Grundlage des durchgeführten Experiments. In dem Szenario soll ein Konfigurator von Fahrzeugen getestet werden. Der Konfigurator stellt zwei REST Schnittstellen bereit, deren Funktionalität in dem Testszenario getestet werden soll. Eine Schnittstelle liefert bei einer GET-Anfrage den Preis eines konfigurierten Fahrzeuges zurück. Eine sogenannte GET-Methode liefert beim Aufruf einer bestimmten URL Informationen (Fielding, et al., 1999). Die andere Schnittstelle der Konfigurator-Software liefert ebenfalls bei einer GET-Anfrage den Bereich der ausgestoßenen Emissionen wieder. Bei den durchgeführten Tests des Testszenarios soll sichergestellt werden, dass die Applikation nur Werte zu gültigen Konfigurationen zurückliefert. Das Testszenario wird in Kapitel 5.2 genauer beleuchtet. Da für ein Behaviour Driven Development Framework die Akzeptanzkriterien die Grundlage des gewünschten Verhaltens der Software bilden, werden zwei entsprechende User Stories mit Akzeptanzkriterien verfasst. Diese sind die Ausgangslage anhand der die Frameworks Tests automatisieren sollen. Die gesamte Implementierung der einzelnen Frameworks ist die Grundlage für die Bewertung und den Vergleich.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Darstellung des methodischen Vorgehens

In dem durchgeführten Experiment werden zwei Frameworks miteinander verglichen. Mit beiden Frameworks wird das aufgestellte Testszenario, wie es soeben kurz beschrieben wurde, implementiert. Die zwei Frameworks für den Vergleich werden aus neun Frameworks ausgewählt. Dazu wird jedes Framework in einem einseitigen Factsheet beschrieben. Das Factsheet gibt einen kurzen Überblick über beispielsweise das Einsatzgebiet, die Kosten und die Dokumentationsmöglichkeiten eines Frameworks. Der Aufbau dieser Factsheets ist für jedes vorgestellte Framework identisch. Anhand dieser Factsheets werden zwei Frameworks für den Vergleich ausgewählt.

Für den Vergleich der Frameworks anhand des Testszenarios wird ein Kriterienkatalog aufgestellt. Dieser Kriterienkatalog wird in drei Kategorien unterteilt. Die „Usability des Frameworks“, die „Auswertung der Ergebnisse“ und die „Wiederverwendbarkeit des Frameworks in weiteren Projekten“. Anschließend wird jede der drei Kategorien gewichtet. Dazu wird eine Person Befragt, die schon viele Jahre Erfahrung im Projektmanagement und in Testen von Software hat. Die Kriterien innerhalb jeder Gruppe sind gleichgewichtet. In einer Umfrage werden Kriterien anhand von Problemstellungen, die beim Testen mit BDD-Tools auftreten, herausgearbeitet. Diese Kriterien werden in einem Kriterienkatalog festgehalten. In der Umfrage werden Personen befragt, die bereits Erfahrung mit dem Umgang von Behaviour Driven Development Frameworks haben.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 4: Übersicht der befragten Personen zur Aufstellung des Kriterienkatalogs

Diese Personen schreiben entweder die Tests für die Automatisierung oder sind mit der Verwaltung und Ausführung der Test vertraut. In Tabelle 4 wird dargestellt welche Personen alles an der Befragung teilgenommen haben. Dazu wird die berufliche Stellung und Tätigkeit zu jeder Person mit angegeben. Die Umfrage wird in Form einer Online-Umfrage durchgeführt. Dazu werden die Teilnehmer per E-Mail eingeladen. In dieser E-Mail wird auch kurz die behandelte Problemstellung dieser Arbeit erläutert. Anschließend haben alle eingeladenen Personen zu dieser Umfrage eine Woche Zeit an der Umfrage teilzunehmen. Zusätzlich zu den herausgearbeiteten Kriterien aus der durchgeführten Umfrage werden dem Kriterienkatalog noch weitere Kriterien hinzugefügt. Dazu wird eine Studie des Fraunhofer Instituts für Experimentelles Software Engineering herangezogen. In dieser Studie werden unter anderem die Performance und Laufzeit der Testfalldurchführung, die Kosten die Einbaubarkeit in andere Projekte als wichtig erachtet (Amiry, et al., 2005). Mit der Einbaubarkeit in andere Projekte ist die Anzahl der unterstützten Programmiersprachen gemeint. Diese drei Kriterien aus der Studie werden dem Kriterienkatalog hinzugefügt.

Die Bewertung der Frameworks zu den aufgestellten Kriterien des Kriterienkataloges erfolgt von unterschiedlichen Personen. Ein Teil der Kriterien wird von dem Autor dieser Arbeit bewertet. Dieser hat auch die Implementierung des Testszenarios mit den beiden für den Vergleich gewählten Frameworks durchgeführt. Bei anderen Kriterien wird die Bewertung von erfahrenen Mitarbeitern aus dem IT-Umfeld als sinnvoller erachtet. Dazu wurden je nach Kriterium unterschiedliche Personen mit unterschiedlichen Stellungen im Unternehmen befragt.

Mit dem aufgestellten Kriterienkatalog, der Gewichtung der Kategorien und der Bewertung der Kriterien der zwei Frameworks wird eine Nutzwertanalyse durchgeführt. Nach Durchführung der Nutzwertanalyse wird ein Ranking der zwei Frameworks aufgestellt. Dieses gibt an, welches Behaviour Driven Development Framework sich am besten für den Einsatz in dem aufgestellten Testszenario eignet.

5 Ergebnis

5.1 Vorstellung und Auswahl der BDD-Frameworks

Die bekanntesten und am meisten verwendeten Frameworks sind laut einer Studie Cucumber, FitNesse, JBhave, Concordion, Spock, easyb und speckflow (Binamungu, et al., 2018b). Daneben werden in dieser Arbeit noch die Frameworks HipTest und TestLeft vorgestellt. Um herauszufinden, welche Frameworks für den Vergleich in dieser Arbeit implementiert und getestet werden sollen, wurden neun Frameworks in einseitigen Factsheets zusammengefasst. Ein Factsheet gibt einen kurzen Einblick in das Einsatzgebiet, die anfallenden Kosten, die unterstützten Programmiersprachen und die bestehenden Integrationen und Plug-Ins des Frameworks. Zudem wird zu jedem vorgestellten Framework ein abschließendes Fazit gegeben. Darin wird aufgeführt, was positiv und negativ an dem Framework aufgefallen ist. Später in diesem Kapitel sind die Factsheets zur Beschreibung der BDD-Frameworks Cucumber und Spock abgebildet. Das Factsheet für Cucumber ist in Abbildung 6 und das Factsheet für Spock in Abbildung 7 dargestellt. Die Informationen auf den Factsheets können auf der jeweiligen Homepage und in der Dokumentation zu den Frameworks entnommen werden. Die Factsheets der anderen Tools sind im Anhang in Abbildung 21 bis Abbildung 27 zu finden. In Tabelle 5 sind die neun BDD-Frameworks, die auch schon in Factsheets beschrieben sind, aufgeführt und kurz beschreiben. Weitere Informationen zu den Tools sind in den Factsheets zu finden. Für den Vergleich wurden die Frameworks Cucumber und Spock ausgewählt. Das Testframework Cucumber wurde gewählt, da dieses Tool bereits in mehreren Projekten zur Testautomatisierung von Akzeptanztests genutzt wird. Durch den Vergleich mit Cucumber soll herausgefunden werden, ob nicht ein anderes Tool die Anforderungen an das Testwerkzeug besser erfüllt. Spock wurde für den Vergleich ausgewählt, da das Framework ebenfalls die Programmiersprache Java und die wichtigsten Integrationen für das aufgestellte Testszenario unterstützt. Zudem nutzt Spock die Sprache Groovy um die Tests zu verfassen. Durch die Nutzung einer anderen Sprache um die Tests zu erstellten wird angenommen, dass sich neue Möglichkeiten ergeben.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 5: Übersicht über bestehende BDD-Frameworks

[...]

• Author: Pascal Mödinger (Author)
• Publication Year: 2021
• Pages: 78
• Catalog Number: V583908
• ISBN (eBook): 9783960959458
• ISBN (Book): 9783960959465
• Language: German
• Tags: Behaviour Driven Development, Cucumber, Spock, Agile Projekte, Softwaretest, Akzeptanztest, Testautomatisierung, Test Driven Development