Behavior Driven Development

Behavior Driven Development (BDD) wurde 2003 von Dan North als Antwort auf Test Driven Development entwickelt. BDD legt den Schwerpunkt darauf, Software zu entwickeln, die für die Anwender von Belang ist. Dazu wird bei der Anforderungsermittlung neben den User Stories (Schema: "As a <ROLLE> I want <AKTION> so that <MEHRWERT>") auch das Verhalten (Behavior) in Form von Vor- und Nachbedingung erfasst. Das Hilfsmittel hierfür ist das Schema "Given - When - Then", was mit "Vorbedingung - Aktion - Nachbedingung" beschrieben werden kann. Somit lassen sich für eine User Story mehrere Szenarien mit unterschiedlichen Randbedingungen erstellen. Diese beschreiben in natürlicher Sprache, wie sich die Software dann jeweils verhalten soll. Im Folgenden wird dies kurz am Beispiel eines Geldautomaten erläutert. Die User Story für das Abheben eines Geldbetrages lautet:

Rolle: Als Kunde

Aktion: möchte ich Geld am Geldautomaten abheben

Mehrwert: damit ich mich nicht am Schalter anstellen muss

Hierbei gibt es verschieden Szenarien zu betrachten, zum Beispiel:

  • Ist das Konto gedeckt?
  • Ist die Karte gültig?

Diese Szenarien werden wie folgt beschrieben:

  1. Given:  Unter der Bedingung, das Konto ist gedeckt UND die Karte ist gültig UND die Geheimzahl wurde richtig eingegeben UND in der Ausgabe ist ausreichend Geld
  2. When: WENN der Kunde Geld abheben will
  3. Then: DANN prüfe, ob das Konto gedeckt ist UND stelle sicher dass das Geld ausbezahlt wird UND stelle sicher dass die Karte zurückgegeben wird

Wie an diesem Beispiel zu erkennen ist können mehrere Bedingungen mit "Und" verknüpft werden. Hat man auf diese Weise die Anforderungen beschrieben so wird als erstes die Oberfläche entwickelt. Die Oberfläche ist das, was die Anwender zu Gesicht bekommen. Sie wird abgestimmt und entsprechend dem Feedback der Anwender überarbeitet. Ausgehend von der Oberfläche wird der Rest der Anwendung Schritt für Schritt implementiert.

Bewertung BQI Research

Behavior Driven Development schneidet nur im Requirements-Management (RM) sehr gut ab, gefolgt vom Qualitäts-Management (QM). Keine Punkte gibt es im Bereich Wartung (W), Betrieb (B) und Projekt-Management (PM). Die Disziplinen Systemdesign (SD), Implementierung (IMP), Test (T) und Integration (INT) schwächeln.

  • Bekanntheitsgrad und Verbreitung sind gering.
  • Es existiert spezielle Tools-Unterstützung.
  • Die Methode ist nicht normiert/standardisiert oder zertifiziert.
  • Keine Lizenzierung erforderlich.
  • Kein Support verfügbar.

zurück zur Studie