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
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
Zielsetzung & Themen
Die Arbeit untersucht Probleme bei der Automatisierung von Akzeptanztests nach BDD-Prinzipien in agilen Projekten der Automobilbranche und ermittelt das am besten geeignete Testwerkzeug durch einen Vergleich von Cucumber und Spock.
- Analyse der Herausforderungen bei der Testautomatisierung in agilen Projekten.
- Entwicklung eines Kriterienkatalogs zur Bewertung von BDD-Frameworks.
- Vergleich der Test-Frameworks Cucumber und Spock anhand eines konkreten Konfigurator-Szenarios.
- Durchführung einer Nutzwertanalyse zur fundierten Werkzeugauswahl.
- Ableitung von Empfehlungen für die Praxis zur Auswahl und Implementierung von BDD-Tools.
Auszug aus dem Buch
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.
Zusammenfassung der Kapitel
1 Einleitung, Motivation und Überblick: Einführung in die Thematik der Testautomatisierung mittels BDD und Darlegung der Herausforderungen innerhalb eines spezifischen Fahrzeugkonfigurator-Projekts.
2 Problemstellung und Forschungsfrage: Definition der zentralen Forschungsfrage bezüglich des optimalen BDD-Frameworks für Akzeptanztests unter Berücksichtigung von Testdatenproblemen.
3 State of the Art von Softwaretesting: Theoretische Grundlagen zu Testautomatisierung, TDD, BDD und relevanten Forschungsarbeiten in diesem Bereich.
4 Methodisches Vorgehen: Beschreibung des experimentellen Designs, basierend auf einem Testszenario für REST-Schnittstellen, sowie des Auswahlprozesses für die Frameworks.
5 Ergebnis: Detaillierte Vorstellung der Frameworks, der Kriterien, der Implementierungsergebnisse und abschließender Vergleich mittels Nutzwertanalyse.
6 Fazit: Zusammenfassende Bewertung, Diskussion der Limitations der Arbeit, Ausblick auf zukünftige Schritte und Einordnung der Ergebnisse in Praxis und Wissenschaft.
Schlüsselwörter
Behaviour Driven Development, BDD, Testautomatisierung, Akzeptanztest, Cucumber, Spock, Softwaretesting, Agile Softwareentwicklung, Framework-Vergleich, Testqualität, Nutzwertanalyse, Gherkin, Software-Konfigurator, REST-Schnittstelle, Qualitätssicherung.
Häufig gestellte Fragen
Worum geht es in dieser Arbeit grundsätzlich?
Die Arbeit befasst sich mit der Herausforderung, Software in agilen Projekten der Automobilbranche mittels BDD-Prinzipien effektiv zu testen und Akzeptanztests zu automatisieren.
Was sind die zentralen Themenfelder?
Zentrale Themen sind Software-Testmethoden (TDD vs. BDD), Testautomatisierung, Framework-Auswahl anhand von Kriterienkatalogen und die praktische Evaluierung von Werkzeugen.
Was ist das primäre Ziel oder die Forschungsfrage?
Das Hauptziel ist die Beantwortung der Frage: „Welches Behaviour Driven Development Framework eignet sich zur Automatisierung von Akzeptanztests am besten?“.
Welche wissenschaftliche Methode wird verwendet?
Es werden ein systematischer Vergleich mittels einer Nutzwertanalyse durchgeführt, sowie eine Online-Umfrage unter Entwicklern zur Erhebung relevanter Auswahlkriterien genutzt.
Was wird im Hauptteil behandelt?
Der Hauptteil umfasst den State-of-the-Art der Testmethodik, das methodische Vorgehen bei der Implementierung eines Fahrzeugkonfigurators sowie die detaillierte Evaluierung der Frameworks Cucumber und Spock.
Welche Schlüsselwörter charakterisieren die Arbeit?
Die wichtigsten Begriffe sind Behaviour Driven Development (BDD), Testautomatisierung, Cucumber, Spock, Akzeptanztests und Nutzwertanalyse.
Warum schneidet Cucumber im Vergleich zu Spock besser ab?
Cucumber bietet umfassendere Möglichkeiten zur Darstellung von Testergebnissen, was im Rahmen der Nutzwertanalyse aufgrund der hohen Gewichtung dieses Kriteriums ausschlaggebend war.
Welche Rolle spielen Testdaten in dieser Untersuchung?
Veraltete Testdaten wurden als signifikantes Problem identifiziert; die Untersuchung bewertet, wie gut die Frameworks bei der Verwaltung und Pflege dieser Daten unterstützen.
Was ist die Bedeutung der "Domain Specific Language" (DSL)?
Die DSL (in Form von Gherkin bei Cucumber) ermöglicht es, Tests in natürlicher Sprache zu formulieren, was die Kommunikation zwischen Fachabteilung und technischer Entwicklung erheblich verbessert.
- Arbeit zitieren
- Pascal Mödinger (Autor:in), 2021, Das Behaviour Driven Development in agilen Projekten der Automobilbranche. Ein Vergleich mit den Techniken Cucumber und Spock, München, GRIN Verlag, https://www.grin.com/document/583908
