Hallo, Carsten und Christoph. Ihr habt für die Oktober-Ausgabe 2020 der iX einen Artikel mit dem Titel „Nicht zu unterschätzen“ über Behaviour-Driven Frameworks geschrieben.
Worum geht es in dem Artikel?
Carsten Weise: Behaviour Driven Development ist eine Software-Entwicklungsmethode, bei der Anforderungen semiformal als sogenannte Behaviours spezifiziert werden. Diese können als Akzeptanzkriterium verwendet werden und sind somit für die Testherleitung geeignet. BDD-Frameworks unterstützen bei der Umsetzung der Behaviours in automatisierte Testfälle. Im Artikel geben wir einen Überblick über aktuelle BDD-Frameworks, z.B. Cucumber, Gauge, Catch2 und viele andere.
Christoph Singer: Da so ein Framework zur Technologie passen muss, die bei der Entwicklung des Software-Produkts verwendet wird, decken wir im Artikel eine große Brandbreite von Frameworks ab: unterschiedliche Betriebssysteme, Programmiersprachen wie Java, C++, Javascript, C#, Python, etc. und auch verschiedene Herangehensweisen an die Spezifikation eines Behaviours - insbesondere Gherkin, aber auch z.B. den describe/it-Ansatz. -.
Carsten Weise: Um dem Leser bei der Auswahl des richtigen Werkzeugs zu helfen, evaluieren wir die Werkzeuge auf Basis eines umfassenden Kriterienkatalogs. Das sind Kriterien wie unterstützte Testobjekte (Webapplikationen, GUIs, APIs etc.), die Anbindung an Entwicklungsumgebungen und auch weitere Details der technischen Implementierung. Wir erläutern im Artikel, wo wir die Stärken und Schwächen der Frameworks sehen. Verraten kann ich an dieser Stelle, dass wir alle Frameworks als nützlich empfunden haben. Christoph und ich haben mit allen Werkzeugen dasselbe Beispiel umgesetzt, um ein Gefühl für das Arbeiten mit den Frameworks zu bekommen.
Christoph Singer: Uns war wichtig, dass wir uns durch die Umsetzung eines konkreten Beispiels mit jedem Tool intensiv auseinandersetzen. Somit ist es uns auch möglich, eine Aussage darüber treffen zu können, wie schnell man sich in das jeweilige Werkzeug einarbeiten kann und wie gut und hilfreich die Dokumentation oder andere zur Verfügung stehenden Hilfequellen sind. Wir haben bei unserem Beispiel den von uns viel erprobten Ansatz einer mehrschichtigen Architektur gewählt. Hierbei wird auch auf die Vorteile einer Trennung von Spezifikation und technischer Umsetzung aufgezeigt. Sollte es auf Grund von Technologieänderungen, Abkündigung eines Tools oder ähnlichem nötig sein das Automatisierungstool zu ersetzen, können die bereits formulierten Testfälle weiterhin verwendet werden.
Carsten Weise: Unser Ziel im Artikel war auch dem Leser verständlich zu machen, dass ein Framework kein Selbstläufer ist: man muss sich in die technischen Details des Frameworks einarbeiten, um es effizient einsetzen zu können. Um den grundlegenden technischen Aufbau der Frameworks verständlich zu machen, haben wir deren ihre Architekturen in Beziehung zur generischen Testautomatisierungsarchitektur (gTAA) gesetzt, die z.B. im ISTQB im Rahmen des Lehrplans "Testautomatisierungsentwickler" als Grundlage für Testautomatisierung verwendet wird.
Ihr habt eben Gherkin erwähnt, was ist das?
Carsten Weise: Gherkin ist eine Methode, um Behaviours zu spezifizieren. Man darf Gherkin dabei wohl als de-facto-Standard bezeichnen, der von fast allen Werkzeugen unterstützt wird. In Gherkin beschreibt man Behaviours möglichst natürlichsprachlich mit Hilfe von Schlüsselwörtern „Given“ – die Vorbedingungen –, „When“ – der Auslöser –, und „Then“ – das erwartete Ergebnis. Hinter den Schlüsselwörtern stehen Beschreibungen der Schritte, die nötig sind, um ein Behaviour umzusetzen. Die natürlichsprachliche Beschreibung dieser Schritte sollte sich an der Benutzerlogik des Anwenders orientieren, und für ihn leicht verständlich sein.
Das Abheben am Geldautomaten könnte z.B. so als Behaviour in Gherkin beschrieben werden:
Given an ATM showing a login screen
When I log in with my debit card
And enter an amount to withdraw from my account
Then the ATM pays out the desired amount
Die Schritte im Behaviour - z.B. "I log in with my debit card" - müssen von einem Testautomatisierer in ausführbare Funktionen oder Skripts übersetzt werden. Anschließend kann man mit dem BDD-Framework das Behaviour automatisch testen, und damit sicherstellen, dass die Anwendungen ihre Anforderungen erfüllen.
Christoph Singer: Durch die verschiedenen Abstraktionsgrade der Schichten kann jede der im Testprozess beteiligten Personen innerhalb der für sie gewohnten Fachlichkeit bzw. Fachsprache (Domain Specific Language, DSL) arbeiten.. Somit beschreibt ein Fachtester die Testfälle in seiner gewohnten Sprache und der Testautomatisierer übernimmt die technische Umsetzung. Dies wirkt auch dem oft vorhandenen Engpass zwischen vielen zu automatisierenden Testfällen und zu wenig Testautomatisierern entgegen.
Was hat der Ansatz mit dem agilen Umfeld zu tun?
Carsten Weise: Im Agilen ist Testautomatisierung sehr wichtig – durch die vielen Iterationen durchläuft das Softwareprodukt auch viele Änderungen, wodurch wir insbesondere einen häufigen Regressionstest brauchen. Die hohe Schlagzahl, die man in der Agilen Softwareentwicklung anstrebt, kann man nur erreichen, wenn man umfassend Testautomatisierung nutzt. Behaviours sind nah an einer natürlichsprachlichen Spezifikation - aus einer User Story ein Behaviour zu machen, ist dabei nur noch ein kleiner Schritt.
Christoph Singer: Agile Softwareentwicklung geschieht in einer intensiven Zusammenarbeit zwischen Entwicklungsteam und Kunde. Dies erfordert eine Formulierung der Anforderungen, die von den Programmierern, von den Testern, und natürlich insbesondere auch von den Nutzern oder Kunden der Software verstanden wird. Hierfür ist BDD natürlich hervorragend geeignet. Zudem zielen die agilen Prinzipien unter anderem auf schnelle, kurze Releasezyklen und funktionierende Software als wichtigstes Fortschrittsmaß des aktuellen Softwarestandes hin. Durch die Verwendung eines BDD-Testautomatisierungsframeworks müssen bereits automatisierte Schritte nicht neu programmiert, sondern können wiederverwendet werden. Dadurch ist es möglich, automatisierte Testfälle zügig umzusetzen und den Entwicklern ein schnelles Feedback zum aktuellen Stand der Software und deren Funktionsfähigkeit liefern zu können.
Was macht imbus im Rahmen von BDD?
Christoph Singer: Wir setzen die Frameworks auch in unseren Testautomatisierungsprojekten ein. Dabei entwickeln wir speziell auf den Kunden und seine Infrastruktur maßgeschneiderte Lösungen, d.h. wir unterstützen beim ganzen Prozess der Testautomatisierung: von der Erstellung einer zum Projekt passenden Automatisierungsstrategie, über die Tool-Evaluierung mit Pilotprojekt, um das richtige Framework zu finden, der Implementierung des Frameworks, bis hin zum Roll-Out, der zum Beispiel auch ein Coaching umfasst. Ebenso bieten wir die Möglichkeit den Automatisierungsprozess komplett an unser imbus Testcenter auszulagern.
Carsten Weise: In unseren Schulungen zum Softwaretest, z.B. unsere ISTQB-Certified-Tester-Schulungen, gehen wir auch auf das BDD als Entwicklungsmethode und Testansatz ein. In unserer Schulung zum ISTQB Testautomatisierungsentwickler beschäftigen wir uns mit einem generischen Architektur-Ansatz für Testautomatisierung, der hervorragend zum Aufbau von BDD-Frameworks passt.
Wir bedanken uns für das Interview!
Weiterführende Inhalte:
Kurse für Testautomatisierungsentwickler
