Behaviour Driven Development

Behaviour-Driven Development (BDD) ist eine Evolution des Denkens hinter Test Driven Development. Dabei wird die Sapir-Whorf Hypothese auf das Schreiben von Tests angewandt. Diese besagt: „zwischen den grammatikalischen Kategorien der Sprache, die eine Person spricht und wie diese Person die Welt versteht und sich in ihr bewegt, besteht eine systematische Beziehung“. Siehe Language, Thought and Reality. Selected Writings von Benjamin Lee Whorf.

Die Sapir-Worf Hypothese ist in der Linguistik umstritten. Unstrittig ist jedoch das Sprache unser Denkenin gewisser weise beeinflusst. Diese Aussage kann bis auf Wilhelm von Humboldts Essay „Über das vergleichende Sprachstudium“ von 1820 zurückgeführt werden.

Bei BDD wird im Vergleich zu TDD nicht ein Testfall definiert, sondern ein Erwartung. Das Ziel ist nicht eine Ansammlung von Tests sondern eine ausführbare Spezifikation der zu entwickelnden Software. Nach Astels „arbeitet man bereits mit BDD wenn man TDD richtig anwendet“. Es existieren spezielle BDD Frameworks die Softwareunterstützung für BDD bieten. BDD kann aber auch mit den bekannten xUnit Frameworks umgesetzt werden.

 

Extreme Programming

Extreme Programming (XP) ist ein iteratives Vorgehensmodell der Softwaretechnik, welches eine sehr flexible Arbeitsweise erlaubt. Es wurde von Kent Beck, Ward Cunningham und Ron Jeffries entwickelt.

XP basiert auf 5 zentralen Werten:

  • Respekt
  • Kommunikation
  • Einfachheit
  • Feedback
  • Mut 

Auf diesen Werten basierende Praktiken bilden das Vorgehensmodell Extreme Programming. Kent Beck hat diese in Extreme Programming zusammengefasst:

  • Das Planungsspiel – Der Umfang einer Version wird festgelegt, indem Geschäftsprioritäten mit technischen Aufwandsschätzungen kombiniert werden. Der Plan muss ständig an die Realität angepasst werden.
  • Kurze Releasezyklen – Ein einfaches System soll so schnell wie möglich in Produktion gehen. Darauf folgend sollen in möglichst kurzen Iterationsschritten neue Versionen eingeführt werden.
  • Metapher – Sämtliche Entwicklungen werden an einer gemeinsamen, einfachen Metapher ausgerichtet. Diese Metapher soll für Geschäftsseite und Entwicklerseite gleichermassen verständlich sein. Dadurch soll die einfache Kommunikation zwischen Kunden und Entwicklern sichergestellt werden. 
  • Einfaches Design – Das System soll zu jedem Zeitpunkt so einfach wie möglich strukturiert sein.
  • Testen – Es werden für jeden Teil des System fortwähren Komponententests geschrieben, die fehlerfrei ausgeführt werden müssen.
  • Refactoring – Das System unterliegt einem ständigen Refactoring, um Redundanzen zu verhindern, den Programmcode zu vereinfachen oder flexibler zu gestalten.
  • Programmieren in Paaren – Der gesamte Produktionscode wird von 2 Programmieren geschrieben, die gemeinsam an einem Rechner sitzen.
  • Gemeinsame Verantwortlichkeit – Jeder kann jederzeit beliebigen Code im System ändern.
  • Fortlaufende Integration – Das System wird ständig integriert. Immer dann, wenn eine Aufgabe erledigt worden ist.
  • 40 – Stunden Woche – Man arbeitet prinzipiell nicht mehr als 40 Stunden in der Woche. Überstunden werden nie länger als eine Woche geleistet.
  • Kunde vor Ort – Dem Team soll ein echter, lebender Benutzer angehören, der während der gesamten Arbeitszeit zur Beantwortung von Fragen zur Verfügung steht.
  • Programmierstandards – Programmierer schreiben sämtlichen Code entsprechend Regeln, die die Kommunikation mithilfe des Codes erleichtern.

Diese Best Practices waren schon vorher bekannt und werden teilweise bereits lange genutzt. XP fasst diese Praktiken zu einem funktionierenden Gesamtkonzept zusammen, definiert diese jedoch nicht als Allheilmittel. Wo sie nicht den individuellen Anforderungen eines Projektes genügen sollen sie angepasst werden. 

Test Driven Development

Test Driven Development (TDD) bezeichnet eine Methode zur Entwicklung von Software bei der Tests vor der eigentlichen Softwarekomponente entwickelt werden. Test Driven Development folgt dabei einem iterativen Prozess aus drei Schritten: 

  1. Rot – Schreibe einen Test für die nächste Funktion, der fehlschlagen muss.
  2. Grün – Sorge mit möglichst wenig Quellcode dafür, dass wieder alle Tests laufen (grüner Balken für alle Tests).
  3. Refaktorisiere – Eliminiere alle Duplikationen und führe notwendige Abstraktionen ein.

Das Verlagern der Tests vor das Entwickeln von Softwarekomponenten bietet einige Vorteile. So wird die Spezifikation nach und nach in die Testsuite überführt. Daraus ergibt sich eine ausführbare Spezifikation, die in maschinell prüfbarer Form vorliegt. Es besteht weiterhin nicht die Gefahr das Tests, die beim klassischen Wasserfallmodel am Ende des Entwicklungsprozesses stehen, aus Zeitmangel nicht durchgeführt werden. Zusätzlich erleichtert eine Testsuite Refaktorisierungen massgeblich. 

Kent Beck hat in Test Driven Development das Vorgehen anhand von Beispielen beschrieben und nennt ausführliche Test Patterns.

Refactoring

Der Begriff Refactoring wurde von William Opdyke geprägt der, 1992, zu diesem Thema promovierte. Refactoring bedeutet: „Verbesserung des Designs von Quellcode nachdem er geschrieben wurde, ohne die Funktion zu verändern“.

Dabei soll insbesondere die Lesbarkeit, Verständlichkeit, Testbarkeit und Erweiterbarkeit verbessert werden. Martin Fowler hat in Refactoring dieses in aller Ausführlichkeit beschrieben. Fowler listet Bad Code Smells auf, die Hinweise geben an welchen Stellen des Quellcodes möglicherweise ein Refactoring notwendig sein könnte und behandelt Methoden, wie verschiedenen Arten von Refactorings durchgeführt werden können.

Refactoring ist heute ein allgemein anerkanntes Werkzeug der Softwareentwicklung. Zahlreiche freie und kommerzielle, meist in IDEs integrierte, Refactoring Browser belegen dies. Für agile Softwareentwicklung ist ständiges Refactoring des Quellcodes eine Grundvorraussetzung.

Usability Test

Ein Usability Test soll die Usability einer Software oder Hardware evaluieren. Dabei werden Versuchspersonen typische Aufgaben an dem zu testenden Produkt gestellt und beobachtet welche Schwierigkeiten auftreten. Die Testperson wird angehalten die Methode des lauten Denkens anzuwenden.

Zur Auswertung der Daten können in einem Usability Labor Tastatur und Maus Aktionen aufgezeichnet, sowie der Bildschirminhalt aufgenommen werden. Weitere Hilfen bei der Auswertung bieten Filmaufnahmen der Testperson und physiologische Werte, die Aussagen über den Streßlevel geben (Puls, Blutdruck oder Herzrhythmus). Um die genaue Orientierung innerhalb einer Bildschirmanwendung aufzuzeichnen, können Eye-Tracking-Systeme eingesetzt werden.

Usability Tests können in jeder Phase der Entwicklung durchgeführt werden. Papierprototypen, Modelle (bei Hardware) und Prototypen eignen sich dazu, bereits in der Anfangsphase der Entwicklung mögliche Fehler zu erkennen und zu beseitigen. In Usability Engineering werden alle Aspekte eines Usability Tests beschrieben. 

Neben Usability Tests mit Benutzern besteht die Möglichkeit von Experten Reviews. Der Hauptunterschied zwischen diesen Verfahren liegt in den beteiligten Akteuren. Für die Durchführung von Experten-Reviews gibt es nach Ben Shneiderman folgende Methoden:

  • heuristischen Evaluation
  • Styleguidereviews
  • Konsistenzinspektion
  • kognitiver Durchgang 
  • formalen Usability Inspektion

Der Hauptvorteil eines Experten Reviews ist, dass erfahrene Tester viele nicht offensichtliche Einschränkungen erkennen können.

Das KISS-Prinzip

Das Akronym KISS steht für Keep it simple, stupid. Es besagt, dass stets die einfachste Lösung für ein Problem gewählt werden sollte. Bereits 1654 wurde vom deutschen Philosophen Johannes Clauberg die bekannte Formulierung aufgestellt, dass „Entitäten nicht über das Notwendige hinaus vermehrt werden dürfen“.

Johannes Clauberg bezog sich in seinem Buch auf wissenschaftliche Theorien. Vereinfacht ausgedrückt bedeutet die Aussage: Eine Theorie sollte möglichst einfach gestaltet sein und trotzdem alle wesentlichen Zusammenhänge erklären.

Das KISS-Prinzip verallgemeinert Claubergs Aussage und kann auf Softwaretechnik angewandt, als eine der Vorraussetzungen für agile Softwarentwicklung angesehen werden.