Fachliche Testbarkeit von User Stories bezeichnet die Eigenschaft, dass ein Tester alle nötigen Informationen vorliegen hat, um gezielt testen zu können. User Stories sind Planungsartefakte, keine dauerhaften Anforderungsdokumente. Akzeptanzkriterien halten fest, was konkret vorführbar funktionieren muss. Ergänzende Spezifikationen wie Entscheidungstabellen oder Ablaufdiagramme werden nur dort hinzugefügt, wo sie dem Team wirklich helfen.
Das Wichtigste in Kürze
- User Stories sind Planungsartefakte, keine Requirements: nach dem Sprint können sie weggeworfen werden, weil nachhaltige Dokumentation an anderer Stelle gepflegt werden muss.
- Akzeptanzkriterien werden in vielen Projekten verschenkt, weil dort zusätzliche Anforderungen stehen statt konkreter Beispiele, die der Product Owner in der Demo sehen will, um abzunehmen.
- Wer im Refinement fragt, welche Spezifikation dem Team im Sprint beim Entwickeln und Testen helfen würde, erzielt den stärksten Hebel für fachliche Testbarkeit.
- Jede User Story lässt sich nach drei Testaktivitäten angehen: Akzeptanztests immer, explorative Tests immer, systematische Testentwurfsverfahren nur bei entsprechendem Risiko.
- Requirements Engineering ist im Umstieg auf Agilität vielerorts weggefallen, obwohl formale Methoden wie Entscheidungstabellen oder Ablaufdiagramme keinen Widerspruch zu agilen Prinzipien darstellen.
User Stories sind keine Anforderungen, sondern Arbeitspakete
Eine User Story ist kein Requirement. Sie ist ein Planungsartefakt, das ein Team an ein Board hängen, schätzen und durch einen Sprint ziehen kann. Wer diese Unterscheidung übergeht, baut auf falschem Fundament.
Daraus folgt eine unbequeme Konsequenz: Stories sind nicht für die dauerhafte Anforderungsdokumentation gedacht. Nach der erledigten Iteration darf man sie wegwerfen. Genau hier reiben sich viele Teams, weil sie die Story als Langzeitspeicher für Wissen missbrauchen, das eigentlich woanders hingehört.
Christian Brandes verortet hinter dieser Verwechslung ein größeres Muster. Mit dem Umstieg auf agile Modelle sei in vielen Teams das Requirements Engineering über Bord gegangen, oft mit der Begründung: “Requirements brauchen wir jetzt nicht mehr, wir haben jetzt Stories.” Diese Gleichsetzung hält der Praxis nicht stand.
Die Verantwortung wandert dann häufig stillschweigend zum Product Owner. Doch die wenigsten Product Owner sind ausgebildete Requirements Engineers. So entsteht eine Lücke zwischen Anforderung und Test, die niemand explizit füllt.
Was bedeutet fachliche Testbarkeit?
Fachliche Testbarkeit heißt: Wer eine Story testen soll, hat alle Informationen, die er neben seiner Intuition für den Test braucht. Das ist die zentrale Frage, die über den Wert einer Story für den Test entscheidet.
Davon zu trennen ist die technische Testbarkeit. Sie fragt, ob sich Tests überhaupt durchführen lassen, ob also Kontrolle über Testumgebung, Datum und Uhrzeit besteht. Beide Formen sind wichtig, aber sie lösen verschiedene Probleme.
Das Invest-Kriterium “testable” nicken in der Praxis alle ab. Auf die Nachfrage, wie man Testbarkeit konkret herstellt, folgt dagegen oft Schweigen. Brandes vergleicht das mit dem Qualitätsbegriff: schwer zu definieren, aber sofort spürbar, wenn er fehlt.
Der praktische Hebel gegen dieses Schweigen ist simpel. Steckt in einer Story Fachlogik, gehört eine Spezifikation dazu, die der Tester nicht erst mühsam zusammensuchen muss. Steht dort nur “Rabattberechnung prüfen”, braucht das Team die Information, was prüfen hier überhaupt heißt.
Akzeptanzkriterien werden in vielen Projekten verschenkt
Akzeptanzkriterien sind keine zusätzlichen Anforderungen, auch wenn sie in vielen Projekten so behandelt werden. Sie beantworten eine andere Frage: Was muss am Ende nachweislich funktionieren, damit der Product Owner die Story guten Gewissens abnimmt?
Die saubere Methode dahinter ist Specification by Example nach Gojko Adzic. Der Product Owner schreibt als Akzeptanzkriterien die konkreten Beispiele auf, die er in der Demo sehen will, um überzeugt zu sein. Abnahme ist auch im Agilen Vertrauenssache, und genau diese Beispiele schaffen das Vertrauen.
In ein klassisches Requirement passt diese Logik nicht hinein. Sie gehört in die Sektion Akzeptanzkriterien, und dort ist sie ein bereits gelöstes Problem.
Akzeptanzkriterien haben für den Test einen weiteren Vorteil: Sie schreien danach, automatisiert zu werden. Was dem Product Owner so wichtig ist, dass er es vorgeführt bekommen will, willst du als Tester immer wieder prüfen.
Die Story als Container: der mittlere Raum entscheidet
Eine tragfähige Story besteht aus drei Zonen. Der Name beschreibt den Problemraum nach dem bekannten Template: Als Rolle will ich Funktionalität, um Business Value zu erreichen. Die Akzeptanzkriterien beschreiben, was am Ende vorführbar funktionieren muss.
Dazwischen liegt ein optionaler Raum, die Story Specification oder Story Description. Sagt das Team “das haben wir schon zehnmal gemacht”, bleibt dieser Raum leer. Braucht das Team eine Handskizze, eine Entscheidungstabelle oder eine Verlinkung auf Details, kommt das hier hinein.
Viele Tools verleiten hier zu einer schiefen Aufteilung. Das User-Story-Template landet in der Description, der Name schrumpft auf zwei Wörter. Besser ist es, den Namen als aussagekräftigen Kurznamen zu führen und die Description für alle Detailinformationen freizuhalten, die dem Team helfen.
In diesen Raum gehören auch Risikohinweise. Wenn der Product Owner markiert, an welchem Detail tunlichst kein Fehler passieren darf, ist das für den Test ein wertvolles Signal.
Wie steuert ein Team, welche Spezifikation es wirklich braucht?
Der stärkste Hebel ist eine einzige Frage im Refinement. Nachdem der Product Owner die Story vorgestellt hat, fragt er das Team: Welche Spezifikation würde euch im Sprint helfen, das zu entwickeln und zu testen?
Das Wort “helfen” ist hier der Maßstab. Dokumentiert wird, was für jemanden einen Nutzen hat, nicht alles und nicht nichts. Das löst den Scheinwiderspruch zwischen “Communication over Documentation” auf, denn das “over” verbietet Dokumentation nicht, es priorisiert nur das Gespräch.
Die Wahl des Formats richtet sich nach dem Inhalt. Fachlogik passt in eine Entscheidungstabelle. Ein Prozess mit Varianten passt in ein Ablaufdiagramm, ob nun BPMN oder UML, ohne dass man es so nennen muss.
Davor warnt Brandes ausdrücklich: nicht jedes Beispiel in Gherkin-Syntax pressen, nur weil ein Team auf BDD umgestellt hat. Wo das Format nicht passt, reicht oft eine Skizze, ein Wertebereich oder eine Tabelle, die man auch lesen kann.
Wir dokumentieren nur, was für irgendjemanden einen Wert oder Nutzen hat. Wenn das dem Team hilft, dann machen wir das auch im Agilen. — Christian Brandes
Dauerhafte Dokumentation gehört neben die Story, nicht in sie
Wenn eine Spezifikation Bestand haben soll, lebt sie nicht in der Story. Sie lebt in einer Produktdokumentation, die parallel zum Produkt von Iteration zu Iteration wächst.
Brandes beschreibt dafür eine getrennte Struktur aus Soll und Ist, beide mit identischem inhaltlichem Aufbau nach fachlichen Komponenten. Sagt das Team, eine Spezifikation würde helfen, wird sie im Soll-Bereich dokumentiert. Die Story referenziert nur darauf: Details findest du hier.
Ist die Funktion entwickelt und getestet, zieht die Spezifikation in den Ist-Stand um. Es bleibt fast nichts zu tun, weil die Dokumentationsarbeit im Vorfeld schon geleistet wurde. Die Story selbst wird danach weggeworfen.
Das löst auch eine wiederkehrende Trace-Frage. Testfälle werden nicht mit der wegalternden Story verknüpft, sondern mit der Spezifikation und später mit der Produktdokumentation. So entsteht eine nachvollziehbare Spur, ohne dass kurzlebige Arbeitspakete zum Trace-Anker werden müssen.
| Artefakt | Lebensdauer | Zweck |
|---|---|---|
| User Story | nur für den Sprint, danach wegwerfbar | Planung, Schätzung, Arbeitspaket |
| Spezifikation (Soll) | wächst mit jeder Iteration | Detailwissen, das dem Team hilft |
| Produktdokumentation (Ist) | dauerhaft | Trace-Anker für Testfälle, Produktwissen |
Nicht-funktionale Anforderungen brauchen keinen Sonderweg
Für nicht-funktionale Anforderungen ist nichts Neues nötig. Die Story bietet Raum für Spezifikationen, also spezifiziert man dort eben Performance, Sicherheit oder andere Qualitätsmerkmale.
Auch hier gibt es Hilfsmittel aus dem Requirements Engineering. Statt “das System muss schnell sein” liefert eine Satzschablone eine prüfbare Aussage: Diese Funktion muss in 99 Prozent der Fälle unter definierten Rahmenbedingungen eine Antwort in höchstens so und so viel Zeit liefern.
Der Product Owner entscheidet, wie sichtbar das Thema wird. Ist es ihm wichtig genug, hebt er es als Akzeptanzkriterium hoch und lässt es sich vorführen. Andernfalls vertraut er den Testaktivitäten des Teams im Systemtest.
Drei X: eine leichtgewichtige Teststrategie für Stories
Wenn eine Story fachlich testbar ist, springen drei Aktivitäten aus ihrem Aufbau heraus. Brandes fasst sie als Triple-X-Strategie zusammen: Acceptance, Exploratory, Risks.
- Acceptance: Die Akzeptanzkriterien werden immer getestet und immer automatisiert. Sie sind das, was unbedingt funktionieren muss.
- Exploratory: Jede Story wird explorativ getestet, auf Basis der Kriterien, der Spezifikation oder der Intuition. Ziel sind schnelles Feedback, frühe Fehlerfindung und Systemverständnis.
- Risks: Optional kommt ein systematisches Testentwurfsverfahren dazu, wenn Risiko und Spezifikation es rechtfertigen. Hier fordert der Tester eine Testbasis ein, etwa eine Entscheidungstabelle.
In dieser Reihenfolge steckt eine Umkehrung. Akzeptanz- und Explorativtests laufen immer, systematische Verfahren nur, wenn sie helfen. Das systematische Testen wird damit zur Ergänzung des erfahrungsbasierten Tests, während das Foundation Level den Satz genau andersherum kennt.
Modellbasiertes Testen passt auch ins Agile
Modellbasiertes Testen generiert Testartefakte aus formalen Modellen wie UML oder BPMN. Die wichtigste Unterscheidung trennt Systemmodelle von Testmodellen.
Systemmodelle beschreiben das System und kommen oft vom Requirements Engineer, etwa als Use-Case-Modell oder Klassendiagramm. Ein Testmodell sieht ähnlich aus, beschreibt aber den Test des Systems. Es gehört dem Test und lässt sich um Testentscheidungen und konkrete Testdaten anreichern, die in einer Systemspezifikation nichts verloren haben.
Aus Systemmodellen lassen sich über Pfadgeneratoren abstrakte Tests ableiten, was viel Fleißarbeit abnimmt. Aus Testmodellen lassen sich sogar konkrete Tests generieren. Kommt mit einer risikobehafteten Story ein solches Modell daher, ist die Brücke zur Teststrategie gebaut.
Dass modellbasiertes Testen im Agilen kaum ankommt, führt Brandes auf ein doppeltes Missverständnis zurück. Modelle gelten als bloße Doku, und Doku gilt im Agilen als verzichtbar. Beide Annahmen sind falsch. Wo ein Modell hilft, das Biest durchzutesten, gehört es dazu.
