Trotz aller Bemühungen zeigt die Erfahrung, dass selbst eine vollständige und widerspruchsfreie Spezifikation nicht notwendigerweise gute Software garantiert. Doch woran liegt das und wie können wir dem Problem begegnen?
Ein klassisches Beispiel zeigt Ihnen nochmal, wie die Vorgehensweise in vielen Projekten ist. Sie werden merken, dass das ein wenig an „Stille Post“ erinnert
- Der Kunde bespricht seine Produktidee mit dem RE häufig anhand von Beispielen.
- Der RE abstrahiert dann und formuliert eine Spezifikation.
- Der Entwickler entwickelt dann die Software auf Basis dieser Spezifikation.
- Der Tester erstellt seine Testfälle anhand dieser Spezifikation.
- Der Kunde nimmt die Software schließlich anhand seiner Akzeptanzkriterien ab. Diese Kriterien beinhalten stets die Beispiele aus 1, die er zur Erläuterung seiner Ideen mit dem RE verwendet hat.
Nun stellt sich die Frage, warum die Beispiele, über die ganz am Anfang geredet wurden, nicht bereits zu Testfällen gemacht werden? Diese können dann, wenn möglich, automatisiert ausgeführt werden und zu automatisierten Akzeptanztests werden:
Das Vorgehen ist bekannt als ATDD (Acceptance Test Driven Development). Die Idee des ATDD ist: Beispiele reflektieren zunächst die Anforderungen. Dann werden die Beispiele zu Tests, die dann möglichst automatisiert die Anforderungen verifizieren.
Wie entstehen Akzeptanztests? Und wer formuliert diese?
Der Requirements Engineer und der Entwickler entwickeln zusammen die Akzeptanztests. Die Tests werden in natürlicher Sprache formuliert. Durch die gemeinsame Erarbeitung der Tests wird das vorrangige Ziel verfolgt, ein gemeinsames Verständnis der Anforderungen zu gewinnen.
Möchte man die Tests „einheitlich“ formatieren, bietet sich als Format eine Satzschablone an. Satzschablonen ermöglichen es, später daraus Test-Code zu generieren. Dies ist u.a. eine Idee des sog. Behavior Driven Developments. Ein Behavior wird durch einen Satz beschrieben, der wie folgt aufgebaut ist: „Given“, „When“, „Then“ (http://martinfowler.com/bliki/GivenWhenThen.html). Ziel ist es, das Verhalten der Software möglichst einfach aber sehr konkret zu beschreiben, so dass auch die Umsetzung in einen automatisierten Test für den Entwickler leicht möglich ist.
Nochmal zum Vergleich – das klassische Vorgehen: In diesem Fall findet der Akzeptanztest erst spät statt und es gibt bei Software-Fehlern sowohl einen Rückweg zur Entwicklung, aber bei fachlichen Fehlern auch eine Weg zum RE und bei einem grundsätzlichen Infrage-Stellen noch mal den Rückweg zum Kunden.
Im Vergleich dazu das ATDD-Vorgehen: Hier setzen sich RE und Entwicklung zusammen und entwickeln zusammen Akzeptanztests. Dadurch werden fachliche Fehler und generelle Inkonsistenzen bereits zu diesem Zeitpunkt erkannt, d.h. die Feedbackschleife ist kürzer.
Wenn alles optimal verläuft, entdeckt die QA dann nur noch Implementierungsfehler.
Zusammenfassung
Eingangs habe ich gefragt, wie gute Dokumentation entstehen kann. Dabei sind ein strukturierter Aufbau und einfache unmissverständliche Sätze ein Schlüssel zum Erfolg. Trotz aller Bemühung kann es zwischen den Stationen Kunde, RE, Entwickler, Tester immer noch viele Missverständnisse geben, wenn man als Schnittstelle zwischen den Akteuren ausschließlich die schriftliche Ausarbeitung (Spezifikation) verwendet (klassisches Vorgehen). Eine agile Methode, die im Zuge der Test Driven Development (TDD) entstand, ist das Acceptance Test Driven Development (ATDD). Es setzt wie alle agilen Methoden darauf, die Kommunikation zwischen den Stakeholdern zu verbessern. Durch das gemeinsame Entwickeln von Akzeptanztests entsteht ein einheitliches Verständnis der Anforderungen, Missverständnisse werden früher erkannt, und aus den Ergebnissen lassen sich schon in dieser Phase automatisierte Tests entwickeln.
