In Teil 1 des Artikels haben wir dargelegt, dass es sich lohnt, den häufig unscharfen Begriff der „Testbarkeit“ aus einer Tester-Perspektive zu konkretisieren, und konnten als erste konkrete Maßnahme daraus die Bedeutung von Akzeptanzkriterien ableiten. Diese zahlen spürbar auf die Testbarkeit einer Story ein, wenn sie selbst keine weiteren Anforderungen sind, sondern – mit Verweis auf „Specification By Example“ – konkrete Beispiele, die den Abnehmenden (z.B. Product Owner) von der gewünschten Umsetzung der Story überzeugen.
In Teil 2 nun stellen wir zwei weitere Testbarkeits-Maßnahmen vor und garnieren das ganze mit Praxistipps fürs Refinement und einer initialen leichtgewichtigen Teststrategie für agile Teams.
Maßnahme 2: Risikohinweise
In der kurzen Test-Einführung in Teil 1 des Artikels habe ich mehrfach betont, wie fundamental wichtig Risiken als Input für den Test sind. Idealerweise enthält eine User Story also Hinweise auf potenzielle Probleme mit dem fertigen Produkt, die der Product Owner tunlichst nicht erleben möchte! Das geht ganz einfach über eine z.B. zusätzliche Sektion im Story-Template und/oder eine zusätzliche Frage zu jeder Story im Refinement:
Was darf als Ergebnis dieser Story auf keinen Fall passieren?
(Alternativ: Worauf sollte das Team achten, oder: Was sollte auf jeden Fall geprüft werden?) Alles, was dem PO auf diese Frage einfällt, wird informell in die Story geschrieben, und das genügt schon.
Übrigens: Es gibt eine Spielart des bekannten Story-Templates, die uns bei dieser Testbarkeits-Maßnahme unterstützen kann. Die Literatur spricht hier unterschiedlich von „Non-Stories“ oder auch „Risk Stories“, und das bekannte Template wird dabei leicht abgewandelt zu:
„Als <…> will ich NICHT, dass <…> passiert, weil sonst <…>.“
Dieses Format kann aber auch problemlos als Hilfsmittel in „normale“ Stories integriert werden, um Risiken pro Story schnell formuliert zu kriegen.
Maßnahme 3: Story-Beschreibungen mit RE-Arbeitsprodukten
Ich habe es unzählige Male in Projekten erlebt: Eine User Story beschreibt einen fachlichen Bedarf (z.B. „Als Sachbearbeiter will ich, dass neue Anträge auf Plausibilität geprüft werden, bevor sie in meinem Eingangskorb erscheinen, damit ich keine Zeit in ungültige Anträge investiere“), aber die fachlichen Details – Business Rules, Fachlogik, Prüfvorschriften, Berechnungen, Abläufe – werden in der Story mit ein paar Sätzen in natürlicher Sprache abgespeist. Schon erste QS-Maßnahmen auf solchen Story-Beschreibungen führen zu Rückfragen wegen Unvollständigkeiten („Und was soll passieren, wenn die hier skizzierte Konstellation NICHT vorliegt?“), Mehrdeutigkeiten, Widersprüchen, Verständnisproblemen, oder sind einfach einer unterschätzten Komplexität geschuldet.
Die gute Nachricht: Dafür gibt es erprobte Lösungen – einen Werkzeugkasten voller Dokumentationstechniken aus dem Requirements Engineering. Und damit habe ich das böse Wort ausgesprochen: Dokumentation. 
Verstehen Sie mich nicht falsch: Die Botschaft hier ist nicht, dass agile Teams wieder anfangen sollen, alles zu dokumentieren – und schon gar nicht vor dem 1. Sprint. Wir reden hier von einem nutzbringenden Zusammenspiel zwischen Agilität (leichtgewichtig, iterativ) und RE (dokumentenlastig, gefürchtet), das sich grob so skizzieren lässt:
- Dokumentieren ist Aufwand. Deshalb wird nur dokumentiert, was für irgendjemanden einen Nutzen und Wert hat, d.h. nur dann, wenn etwas dokumentiert werden muss oder wenn die Dokumentation dem Team hilft.
- Die zum Produkt gehörende Dokumentation entsteht – wie das Produkt selbst – inkrementell, typischerweise im Zuge der Definition of Done (Story ist „done“ heißt: fertig entwickelt, fertig getestet… und fertig dokumentiert).
- Es gibt definitiv Stories, bei denen der direkte Austausch im Team ausreicht und keine Dokumentation nötig ist. Aber es gibt auch Stories, bei denen das allein nicht genügt und RE-Arbeitsprodukte dem Team die Arbeit erleichtern. In solchen Fällen beschließt das Team, die Story um RE-Artefakte anzureichern (z.B. grafische Modelle, Entscheidungstabellen, Skizzen u.s.w.), die im Zuge der Story-Fertigstellung dann typischerweise in die zur „doneness“ benötigte Dokumentation umgezogen werden. Das passiert vor allem dann, wenn die Story – wie in der Test-Einleitung erwähnt – hohe Komplexität und/oder hohe Risiken mit sich bringt, denn dann lohnt sich diese zusätzliche Investition in formalere Dokumentation. Die Erstellung von RE-Artefakten pro Story als Teamentscheidung – etwa im Refinement-Meeting – in den Prozess zu integrieren, ist im Grunde die einfachste Umsetzung des Prinzips „so viel RE wie nötig, aber so wenig wie möglich“.
Was hat der Test davon? Er kann bei Stories mit hohen Risiken dann aus formalen RE-Arbeitsprodukten systematisch(!) Testfälle ableiten und diese mit den getesteten Anforderungen vertracen (z.B. mit den Regeln/Spalten in einer Entscheidungstabelle) – was schwierig ist, wenn die Story-Beschreibung nur aus ein paar flüchtigen Prosasätzen besteht.
Dass formale Dokumentationen agilen Teams helfen können, möchte ich mit 2 Beispielen belegen:
- Hier eine Übungs-Story zum Thema „Prüfung auf Schaltjahr“. Die Story-Beschreibung wurde um ein RE-Artefakt angereichert (wahlweise ein Modell oder eine Tabelle, eben was dem Team mehr liegt) – und die Akzeptanzkriterien sind, wie oben empfohlen, konkrete Beispiele, die dem PO wichtig sind. Diese Story werden die meisten Tester:innen als „testbar“ bezeichnen. (Übrigens: Im Grunde ist es zweitrangig, ob ein RE-Arbeitsprodukt direkt in der Story abliegt oder die Story einen Link darauf enthält. Ich habe aber agile Teams erlebt, die sich gegen eine Verlinkung entschieden haben, weil ihnen der eine zusätzliche Klick zu aufwändig war – bis hin zu redundantem Copy & Paste von Diagrammen direkt in die Story.)
2. Und um eine Lanze für den leichtgewichtigen und bedarfsgesteuerten Einsatz von Modellen in User Stories zu brechen, verweise ich auf eine frühere Publikation [8], in der ich den Nutzen diverser modellbasierter Techniken für agile Teams an einem durchgängigen Beispiel illustriere.
Die Erfahrung zeigt: Eine Story, die durch Einsatz einer zusätzlichen Dokumentationstechnik viele Unklarheiten gar nicht erst aufkommen lässt, wird auch von agilen Teams wertgeschätzt. Als ich dieses Vorgehen einem Unternehmen in der Medizinbranche vor Jahren einmal in einem Workshop nahebringen durfte, erreichte mich am nächsten Tag eine SMS der dortigen Scrum-Masterin:
Anders gesagt: Wie bei allen angemessen gewählten QS-Maßnahmen erzeugen formalere Artefakte zwar Mehraufwand, der sich aber auf lange Sicht auszahlt – weil Fehler früher gefunden, Anforderungen seltener missverstanden und so teuere späte Fehlerbehebungen vermieden werden.
Einordnung, Umsetzung & Tipps zum Abschluss
Fassen wir zusammen: Die 3 konkreten Schritte zu mehr Testbarkeit – „Beispiele als Akzeptanzkriterien”, „Risikohinweise” und „RE-Arbeitsprodukte bei Bedarf” – lassen sich auch als 3 Fragen formulieren, die z.B. in einem Backlog Refinement gestellt werden können (und sollten):
(1) Team an PO: Was willst du in einer Demo der fertigen Story sehen?
(2) Team an PO: Auf welche Risiken sollte das Team besonders achten?
(3) PO an Team: Welche Details/Dokumente/Artefakte würden euch bei dieser Story helfen – beim Verständnis und bei der Umsetzung?
Die beiden Maßnahmen „Beispiele als Akzeptanzkriterien“ und „Risikohinweise“ sind dabei vergleichsweise einfach und kostengünstig umsetzbar; Maßnahme 3 ist hingegen ein deutlich dickeres Brett, bedeutet es doch den Aufbau und Einsatz von RE-Skills und die Definition eines agilen und iterativen Anforderungsprozesses – von der initialen Erfassung über Backlog Items bis hin zu Dokumentation und Tracing.
Triple-X-Teststrategie für User Stories
Und um die erreichte Testbarkeit nochmal in der Gesamtheit darzustellen: Eine initiale Teststrategie für User Stories namens “Triple-X-Strategie” lässt sich mit drei “X” gut merken und gibt folgende Antwort auf die Frage, wie eine Story vom agilen Team getestet werden kann:
mit explorativen Tests, basierend auf den Akzeptanzkriterien (= konkrete Beispiele), den Risikohinweisen und, wenn vorhanden, der Story-Beschreibung (“eXploratory”)
mit Akzeptanztests, also automatisierten Tests der Akzeptanzkriterien, die dank GIVEN-WHEN-THEN ja schon Testfälle beschreiben (“aXeptance“)
und – je nach Risiko und/oder Komplexität (“risX“) – mit systematischen Tests, basierend auf den RE-Artefakten, die die Story in diesem Fall begleiten.
Sie bekommen mit den 3 Maßnahmen also gleichzeitig noch eine leichtgewichtige und pragmatische Teststrategie für Ihre Stories an die Hand – mehr Testbarkeit geht nicht.
(Übrigens: Mit den 3 Maßnahmen aus den beiden Artikeln (Teil 1 & 2) gewinnen Ihre Stories zwar an fachlicher Testbarkeit, aber nicht zwangsläufig an technischer, wie in der Testeinführung erwähnt. Testdaten und Testumgebungen können weiterhin große Probleme bereiten. Wenn Sie auch hier tiefer einsteigen wollen, verweise ich auf [9].)
Mein letzter Vorschlag an Sie: Probieren Sie’s aus! Das Schöne an agilen Arbeitsweisen ist ja, dass sie das Experimentieren erleichtern – arbeiten Sie also z.B. für 2-3 Sprints mit konkreten Beispielen als Akzeptanzkriterien und bewerten Sie das Ergebnis dieser Maßnahme danach in einer Sprint-Retrospektive. Und falls Sie Unterstützung benötigen, hilft die Anforderungsfabrik natürlich gerne!
Links & Literatur
[1] IREB-CPRE-Glossar: CPRE Online Glossary
[2] INVEST: INVEST (mnemonic)
[3] ISTQB CTFL Syllabus: https://istqb.org/wp-content/uploads/2024/11/ISTQB_CTFL_Syllabus_v4.0.1.pdf
[4] Mucha, Julia: “Gemeinsam agil und kontrolliert – Praxisleitfaden für nachhaltige Traceability-Strategien“, https://anforderungsfabrik.de/blog/traceability-strategie-praxisleitfaden/
[5] Rupp/SOPHISTen: „Requirements-Engineering und -Management“, Hanser 2002 (7. Auflage 2020)
[6] Adzic, Gojko: „Specification By Example“, Manning 2011
[7] Gärtner, Markus: „ATDD in der Praxis“, dPunkt 2013
[8] Brandes, Christian, „Modellieren im agilen Requirements Engineering – wohldosiert und leichtgewichtig“: Wie wohldosiertes Modellieren im agilen Requirements Engineering unterstützen kann
[9] Brandes, Christian: „Architektur und Testbarkeit: Eine Checkliste (nicht nur) für Architekten“: https://www.sigs-datacom.de/uploads/tx_dmjournals/brandes_et_al_OS_02_16_mKqG.pdf
