Brandneues Live-Webinar für Testmanager & Testautomatisierer: Verbessern Sie Ihre Lasttests und Website Performance mit Cloud-Lösungen und DevOps!

Brandneues Live-Webinar für Testmanager & Testautomatisierer: Verbessern Sie Ihre Lasttests und Website Performance mit Cloud-Lösungen und DevOps!

Mehr erfahren

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

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

Behaviour Driven Testing - BDD Bedeutung, Szenarien, Einsatz, Vorteile, Nachteile, Testautomatisierung
Lesedauer: 3 Minuten

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.

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.

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.

Kostenlosen Testautomatisierungs Workshop mit unseren Testexperten unverbindlich vereinbaren. Kostenlosen Testautomatisierungs Workshop mit unseren Testexperten unverbindlich vereinbaren.
06. November 2023

Über den Autor

Bild des Benutzers Moritz Salein
Senior Testmanager und Test Automation Engineer
Ich bin seit über 20 Jahren in der IT tätig, aber vor über 10 Jahren begann meine Passion des Softwaretestens. Seit dieser Zeit übernehme ich immer mehr Aufgaben die im Softwaretest, Testmanagement und auch ganz speziell in der Testautomatisierung anfallen. Dadurch bin ich in die unterschiedlichsten, meist international aufgestellten Unternehmen und Projekten beschäftigt gewesen. Auch in der agilen Softwareentwicklung fand ich großen Gefallen, so dass ich schon seit über 8 Jahren Erfahrungen mit verschiedensten Vorgehensweisen, wie Scrum, Kanban oder SAFe sammeln konnte.

Finden Sie weitere interessante Artikel zum Thema: