Qualität ist mehr als Testen: User Stories und Akzeptanzkriterien

Grafik: Pixabay / Geralt - Lizenz

Im klassischen Projektmanagement ist die Rolle des Testers relativ klar umrissen: irgendwann in einer lang zurückliegenden Projektphase hat jemand eine Feinspezifikation geschrieben. Aus der hat ein Testmanager Testfälle abgeleitet, die er in Form einer detaillierten Klickanleitung aufgeschrieben hat. Und die wird dann durchgeklickt. Wieder und wieder und wieder.

In agilen Projekten gibt es weder Feinspezifikationen noch Klickanleitungen, so dass der Tester wesentlich selbstständiger arbeiten muss. Konkret bedeutet das nicht nur, dass er die Testfälle selbst verfassen muss (dazu ein anderes mal mehr) - auch für die Anforderungen auf denen die Testfälle beruhen ist er (mit)zuständig. Spätestens an dieser Stelle der Erzählung ist es in den letzten Jahren regelmässig vorgekommen, dass sowohl Tester als auch Fachabteilungsmenschen Schnappatmung bekommen haben. "Was?? Test schreiben geht ja gerade noch, aber an den Anforderungen mitarbeiten? Das klappt doch niemals. Das kann ein Tester gar nicht."¹
Soweit die Zweifler dieser Welt. Ich sage aber: es geht und es ist gar nicht schwer. Und zwar so:

Qualitätssicherung der Anforderung/User Story

User Stories bestehen in ihrer ursprünglichen Reinform aus einem einzigen Satz nach dem Muster "Als [User mit Rolle A] möchte ich [Aktion B durchführen können] um [Mehrwert C zu haben]." Um ein Beispiel zu nennen: Als Kunde möchte ich in meinem Login-Bereich meine Lieferadresse eingeben können, damit mir meine Waren zugeschickt werden können. Die Aufgabe des Testers wären hier folgende Überprüfungen:

• Ist die Story klar genug beschrieben ("Ich möchte im Login-Bereich meine Adresse eingeben können" statt "Ich will meine Adresse eingeben")? 
• Ist die Story klar zu anderen Anforderungen abgegrenzt ("Ich möchte meine Lieferadresse eingeben können" statt "Ich will alle meine Daten pflegen")? 
• Ist ein Mehrwert erkennbar (endet die Story mit einem Zwecksatz)? 
• Ist die Story testbar (" Ich will Daten eingeben können" statt "Ich will ein Eingabefeld haben, das in einer späteren User Story eine Funktion bekommen wird")? 

Sind diese Kriterien nicht gegeben ist eine Rücksprache mit dem Verfasser der Story zu empfehlen, da hier noch Verbesserungsbedarf besteht. Wenn die User Story so abgesichert ist folgt der zweite Teil, das Verfassen der Akzeptanzkriterien.

Verfassen der Akzeptanzkriterien

Akzeptanzkriterien sollten ähnlich wie die User Story selbst nicht in eine Feinspezifikation ausarten, sondern in einfacher, auch für den Nicht-Informatiker verständlicher Sprache geschrieben sein. Sie sollten vom Verfasser der Story gemeinsam mit dem Tester erarbeitet werden und beantworten im Idealfall die folgenden Fragen: Wer bin ich?, Wo kann ich eine neue Aktion durchführen?, Was für eine Aktion ist das?, Welchen Effekt löse ich damit aus? und Welche Voraussetzungen müssen dafür gegeben sein? Beim oben genannten Beispiel sähe das so aus:

• Wenn ich mich als User mit Rolle "Kunde" einlogge sehe ich in der Kopfnavigation den neuen Menüpunkt "Lieferadresse pflegen"
• Nach einem Klick auf den Menüpunkt werden Eingabefelder für Strasse, Hausnummer, Postleitzahl und Stadt angezeigt sowie ein Save-Button
• Wenn die Daten eingegeben und gespeichert werden erscheinen sie in der nur für User mit der Rolle "Lieferant" sichtbaren Tabelle "Kundendaten"
• Voraussetzungen: Die User Stories "Login" und "Kundendaten" müssen abgeschlossen sein bevor diese User Story begonnen wird

Und das ist es auch schon. Damit ist die Software-Anforderung fertiggestellt.

AberAberAber!!

Jedem der schon einmal eine klassische (Fein)Spezifikation gesehen hat wird spätestens jetzt ein Gedanke kommen: Dem Entwickler wird hier ja gar nicht gesagt wie er zu entwickeln hat! Und es gibt gar keine pixelgenaue Vorgabe wo und in welcher Farbe welches Element erscheinen soll!! Die Antwort darauf ist - natürlich nicht! Darauf zu verzichten und darauf zu vertrauen, dass das Entwicklungsteam (in Absprache mit PO und Tester) von sich aus die beste und effizienteste Lösung finden wird, das gehört zum agilen Vorgehen dazu. Und wenn man das einmal verinnerlicht hat kommt man auch schnell zu der Einsicht, dass eine "nur" aus User Story und Akzeptanzkriterien bestehende Anforderung auch von einem Tester mitbearbeitet werden kann - und auch mitbearbeitet werden sollte, wenn man denn Wert auf Qualität legt.

¹Wörtliches Zitat