Wir haben in den vergangenen Blogs gesehen, wie wir Spezifikationen für Kunden und Spezifikationen für Entwickler schreiben. Wir schreiben jedoch auch eine Spezifikation für Tester. Was aber brauchen Tester in einer Spezifikation?
Tester sollen anhand von Tests nachweisen, dass sich die Software verhält, wie erwartet. Da es aber neue Software ist, können sie nicht auf Erfahrungen mit ihr zurückgreifen – sondern sie können “nur” auf das beschriebene Verhalten in der Spezifikation zurückgreifen. Daher muss klar sein, wie das Verhalten sein soll und die Tester brauchen klare Beschreibungen, was wirklich verlangt ist.
Oftmals ist dies nicht so klar und aus der Spezifikation werden Dinge herausgelesen, die so eigentlich nicht verlangt wurden. Das führt zu unnötigen Diskussionen oder sogar zu Bugfixes von Bugs, die eigentlich gar keine sind. Um hier die Abgrenzung klar zu machen und Testern eine klare Hilfestellung zu geben, brauchen Anforderungen klare Akzeptanz-Kriterien. Diese Kriterien enthalten alles, was gebraucht wird, um zu beurteilen, ob eine Anforderung akzeptiert werden kann – oder eben nicht.
Akzeptanz-Kriterien können hierbei auch Modelle enthalten, z.B. ein Status-Übergangsmodell für verschiedene Status eines Business-Objekts oder aber auch die schon in der Kundenspezifikation verwendeten Mockups. Hilfreich ist es hier an Akzeptanz-Kriterien in Form von Checklisten zu denken. Ist ein Punkt dieser Checkliste nicht erfüllt, kann die Software nicht abgenommen werden.
User Stories für Alle
Um aber die Risiken für eine Nicht-Abnahme zu verringern, kann die Software in kleine Stories – sogenannte User Stories – geteilt werden. Die Summe dieser User Stories ist dann die Gesamt-Software. Eine User Story beschreibt einen kleinen durch den Benutzer wahrgenommenen Vorteil der Software. Jede dieser User Stories hat ihre Akzeptanz-Kriterien. Dadurch erreichen wir zum einen, dass wir die Software Schritt für Schritt aufbauen können und zum anderen erreichen wir, dass unter Umständen eine nicht-abgenommene User Story nicht zur Nicht-Abnahme der Gesamt-Software durch den Kunden führt.
User Stories sind ein wichtiges Hilfsmittel für Spezifikationen und werden von allen drei Zielgruppen verstanden. Sie werden immer aus Benutzer-Sicht geschrieben, wobei sie die Rolle des Benutzers, die auszuführende Funktion und das zu erreichende Ziel bei der Ausführung enthalten:
Ich als Buchhalter möchte einer Rechnung eine Position hinzufügen, damit alle Positionen – auch nachträglich bestellte – in die Rechnung einfließen. Die entsprechenden Akzeptanzkriterien könnten dann wie folgt aussehen:
- Ein Benutzer in der Rolle eines Buchhalters kann eine Position in eine Rechnung hinzufügen.
- Die Position kann aus dem Katalog ausgewählt werden oder als Freitextposition hinzugefügt werden.
- Nach Bestätigung durch den Benutzer wird die Rechnung neu kalkuliert und das neue Printlayout dem Benutzer angezeigt.
Hierzu würden dann die entsprechenden Mockups und die Statusübergänge der Rechnung – Entwurf – Neue Position – Rekalkuliert – Bestätigt gehören.
Da User Stories aus Benutzer-Sicht geschrieben werden, können sie gut vom Kunden verstanden werden. Vielmehr noch beschreiben sie auch die Motivation hinter einer technischen Funktion. So kann auch der Kunden die Wichtigkeit oder auch Unwichtigkeit einzelner Funktionen erkennen und diese priorisieren. Um die vorgenannten Business-Prozesse abzubilden, sollten sie in der Reihenfolge der Business-Prozess-Schritte aufgebaut werden.
Da sich User Stories auf die Business-Objekte beziehen, die wir vorher im Domain-Model beschrieben haben, werden sie auch von Entwicklern verstanden.
Da User Stories immer Akzeptanz-Kriterien enthalten, können sie gut von Testern verwendet werden, um klare Aussagen über die Funktionsfähigkeit der Software zu treffen.
Zusammenfassung
Wir schreiben Spezifikationen für Kunden, Entwickler und Tester. Jeder dieser Zielgruppen braucht spezifische Informationen, die hier nochmal aufgeführt sind:
- Business-Prozess-Beschreibung als grafische und sprachliche Beschreibung
- Domain-Modell als grafische und sprachliche Beschreibung
- User Stories als benutzer-zentrierte Beschreibung der geforderten Funktionalitäten
- Akzeptanz-Kriterien für die Abnahme mit folgenden (optionalen) Anteilen
- Mockups mit Beschreibung der Benutzer-Oberfläche
- Status-Diagramme, um Status-Übergänge für Business-Objekte zu zeigen
- Aktivitäten-Diagramme, um komplexe Abläufe leichter aufzuzeigen
Mit diesem Inhalt werden wir gut verstanden – aber das heißt nicht, dass wir nicht mit dem Kunden, den Entwicklern und den Testern sprechen müssen 🙂 .