Dass User Stories testbar sein sollen, ist ein Allgemeinplatz in agilen Teams. Die Definitionen von „Testbarkeit” bleiben jedoch meist abstrakt und geben selten konkrete Maßnahmen an die Hand, die man unmittelbar in seinem Projekt anwenden kann. Wir werden im vorliegenden zweiteiligen Artikel nicht nur diese Konkretisierungsarbeit leisten, sondern aus Perspektive eines Testers – der ja von eben dieser Testbarkeit in seinen Arbeitsschritten profitieren soll – anhand von Beispielen anschaulich zeigen, worauf es wirklich ankommt.
Die Herausforderung mit der Testbarkeit
Das Qualitätsmerkmal „Testbarkeit“ bringt eine generelle Herausforderung mit sich, egal ob wir (agil) von testbaren Stories oder (klassisch) von testbaren Anforderungen reden: Genau wie beim Merkmal „Qualität“ selbst ist es in der Praxis erstaunlich schwer, „Testbarkeit“ im Vorfeld einer Produktentwicklung fassbar und messbar zu beschreiben – aber man bemerkt umgekehrt sofort, wenn sie später im Entwicklungsprozess fehlt.
Dabei hilft auch kein Blick in die Testbarkeits-Definitionen aus den üblichen RE-Standards: Laut IREB-Glossar [1] ist Testbarkeit (im Deutschen: Überprüfbarkeit) „the degree to which the fulfillment of a requirement (…) can be verified“, d.h. der Fokus liegt auf der Verifikation, nicht der Validierung (diese wird für Anforderungen in der ISO/IEC/IEEE 29148 zusätzlich gefordert).
Und für User Stories gibt es aktuell offenbar überhaupt keine vergleichbar etablierte Begriffsklärung – „Testbarkeit“ wird von Teams meist pragmatisch umgesetzt, und das Akronym INVEST [2] für „gute“ Stories sorgt lediglich dafür, dass das Thema zumindest nicht vergessen wird.
Ein Perspektivwechsel
In diesem Blogbeitrag wollen wir die Frage beantworten: Was macht eine User Story aus Tester-Sicht testbar?
Dahinter steckt das Prinzip, dass die Qualität eines Arbeitsproduktes nicht von dessen Autor (dem „Sender“ oder „Einbrocker”) beurteilt wird, sondern vom Leser (dem „Empfänger“ oder „Ausbader”), der ja damit weiterarbeiten muss und am besten weiß, was er benötigt. Also setze ich hier kurz den Tester-Hut auf – ich war jahrelang in verschiedenen Projekten in Test- und QS-Rollen unterwegs – und hoffe, dass diese Perspektive für die RE-interessierte Leserschaft praktisch umsetzbaren Mehrwert schafft.
Um zu verstehen, was zum Test einer Story benötigt wird, muss ich ein paar Vorbereitungen treffen und Begriffe und Prinzipien erklären, die allesamt im ISTQB-Teststandard [3] – also dem IREB-Pendant – zu finden sind. Tester:innen können diesen Abschnitt gerne überspringen.
Begriffe & Prinzipien im Test
- Testen ist immer eine Stichprobe. Da vollständiges Testen nicht möglich ist, entsteht also die Herausforderung, Tests so zu entwerfen, dass mit möglichst wenig Testfällen eine möglichst hohe Fehlerfindungswahrscheinlichkeit erreicht wird. Dies geschieht auf Grundlage sowohl der verfügbaren Informationen (Anforderungen, Nutzungsszenarien, Risiken) als auch der eigenen individuellen Erfahrung („detektivischer Tester-Instinkt“).
- Jedes gute Testvorgehen ist risikobasiert. Das heißt: Wo ein höheres Produktrisiko vorliegt (im Sinne von Schadenshöhe und Eintrittswahrscheinlichkeit), sollte entsprechend mehr getestet werden, um begrenzte Testressourcen effektiv einzusetzen.
- Bei hohem(!) Risiko streben wir ein systematisches Testvorgehen an, also idealerweise etwas in der Geschmacksrichtung „alle Zustandsübergänge“, „alle Kombinationen“, „alle Business Rules“. In der Praxis wird ein solches Testziel durch kombinatorische Effekte oft unrealistisch, und Tester arbeiten dann mit schwächeren, aber immer abgewogenen und transparenten Abdeckungskriterien.
- Ein Testfall besteht ganz abstrakt aus mindestens 3 Teilen: (1) dem Startzustand des Testobjekts, der zwecks Testwiederholung idealerweise 1:1 wiederhergestellt werden kann; (2) den Eingaben ins Testobjekt, z.B. über eine grafische Benutzeroberfläche; (3) den erwarteten(!) Ausgaben des Testobjekts, auch Sollwerte genannt. Deshalb sprechen Tester im Zuge der Testdurchführung von einem „Soll-Ist-Vergleich“: Jeder Testfall sagt, wie das zu testende Produkt unter gewissen Bedingungen und Aktionen reagieren soll, und beim Testen wird sichtbar, was die tatsächlich implementierte Reaktion ist.
- Es gibt zahlreiche verschiedene Testarten und Teststufen (z.B. Unittests, Integrationstests, Abnahmetest u.s.w.). Der Abnahme- oder Akzeptanztest zeichnet sich durch eine spannende Besonderheit aus: Im Gegensatz zu allen anderen Testarten hat er nicht(!) das Ziel, Fehler zu finden, sondern soll stattdessen Vertrauen beim Abnehmenden (Product Owner, Auftraggeber, je nach Setup) erzeugen. Abnahme ist Vertrauenssache, und Fehler, die im Abnahmetest und somit viel zu spät gefunden werden, zerstören dieses Vertrauen.
- Und zum Schluss ein aus IREB bekanntes Thema: Auch aus Testsicht ist eine Traceability (Verfügbarkeit, siehe z.B. [4]) zwischen Testfällen und getesteter Anforderung wichtig – um eben den Test- und Projektfortschritt toolgestützt messen und Auswirkungsanalysen für Changes durchführen zu können.
Beim Thema „Testbarkeit” hilft es außerdem, grob zwei Arten zu unterscheiden, die man „fachlich“ und „technisch“ nennen kann: Fachliche Testbarkeit adressiert den Entwurf von Testfällen und fragt, wie es um die Qualität der o.g. Eingangs-Informationen (z.B. Anforderungen oder Stories) steht; technische Testbarkeit hingegen betrachtet, ob Tests auch durchgeführt werden können, ob also ausreichend Kontrolle über Testumgebung, Testdaten und benötigte Schnittstellen besteht. Folglich geht es in diesem Beitrag ausschließlich um die fachliche Testbarkeit von Stories.
Mit diesem Rüstzeug schauen wir uns in zwei Teilen an, mit welchen 3 konkreten Maßnahmen Stories bei Tester:innen für mehr Freude bei der Arbeit sorgen – den Anfang macht in diesem ersten Teil die Maßnahme „Beispiele als Akzeptanzkriterien“.
Maßnahme 1: Beispiele als Akzeptanzkriterien
Der nach meiner Erfahrung wichtigste Hebel für eine bessere Testbarkeit von User Stories steckt in deren Akzeptanzkriterien. Viele Teams lassen hier Chancen ungenutzt liegen, weil sie als „Akzeptanzkriterien” einfach nur Anforderungen in ihre Stories schreiben – und dabei außer Acht lassen, dass Anforderungen und Akzeptanzkriterien zwei verschiedene Dinge sind. Ich bemühe hierzu ein klassisches RE-Buch ([5], mein Exemplar stammt in 2. Auflage übrigens bereits aus dem Jahr 2002, und ich zitiere die Seiten 71 und 294, die vom Synonym „Abnahmekriterien” Gebrauch machen):
„Ein Abnahmekriterium ist eine Anweisung für den Test (…) einer Anforderung.“ – „Abnahmekriterien (…enthalten…) Beispiele, mit denen das System (…) gegenüber den Anforderungen verifiziert werden kann.“
Im Klartext: Akzeptanzkriterien sind keine Anforderungen, sondern vielmehr Tests zu einer Anforderung – aber (wichtig!) mit dem eingangs genannten Ziel, Vertrauen beim Abnehmenden aufzubauen.
GIVEN – WHEN – THEN: kein Zufall
Und wen die Aussage „Akzeptanzkriterien sind Tests“ jetzt völlig irritiert: Kennen Sie die Gherkin-Notation für Akzeptanzkriterien, also das Schema „GIVEN – WHEN – THEN“? Dieser Dreiklang ist semantisch genau das gleiche wie der eingangs beschriebene Aufbau eines Testfalls mit „Startzustand/Eingaben/erwartete Ausgaben“. Und das ist kein Zufall.
Wie aber finden wir solche Akzeptanzkriterien?
Den schönsten Tipp dazu hat Nancy van Schooenderwoert 2011 in einer Konferenz-Keynote gegeben: „Stellen Sie sich vor, das Team ist mit einer Story fertig, und Sie als Product Owner hätten für eine Abnahme der Story nur 10 Minuten Zeit. Was wollen Sie in diesen 10 Minuten sehen, um hinterher über eine Abnahme entscheiden zu können? Schreiben Sie das auf!“
Als Ergebnis erhalten Sie konkrete Beispiele, die Sie davon überzeugen würden, dass Sie Ihrem Team die fragliche Story abnehmen können. (Die „10 Minuten“ sind natürlich nur ein Kniff, um sich auf das Wichtigste aus PO-Sicht zu fokussieren: Was muss unbedingt vorgeführt werden, denn wenn es nicht funktionieren würde, würde ich als PO die Story nicht abnehmen?)
Was hat der Test davon?
Diese Beispiele können – anders als Anforderungen – nicht nur sofort in Testfälle überführt werden, sondern sie adressieren implizit Risiken (siehe risikobasiertes Testen) und werden deshalb in jedem Regressionstest wiederholt, um sicherzustellen, dass „das Wichtigste“ immer noch funktioniert. Und sie lösen in jedem Tester schon beim Lesen zig weitere Testideen aus – als Startpunkt etwa für explorative Testsessions.
„Beispiele als Akzeptanzkriterien“ sind leider noch nicht sehr weit verbreitet, trotz des schönen Buchs „Specification by Example“ von Gojko Adzic [6]. Darin nennt er 4 Vorteile, die der Einsatz von Beispielen mit sich bringt (nicht nur für den Test: etwa besseres Verständnis im Team, oder die Wiederverwendbarkeit dieser Beispiele in der Benutzerdokumentation), und nach mehreren Jahren positiver Praxiserfahrungen mit Beispielen füge ich noch einen 5. Vorteil für Scrum-Teams an: Die Frage, was in einer Demo am Sprint-Ende konkret gezeigt werden soll, hat sich mit solchen konkret prüfbaren Akzeptanzkriterien schon vor Sprint-Beginn erledigt.
Zur Illustration dieser 1. Maßnahme eine Beispiel-Story (angelehnt an [7]), die gut zeigt, was ich mit „Beispielen“ meine: konkrete Prüfungen, am besten mit konkreten Werten, und möglichst ohne detaillierte UI-Klickanleitungen, weil die nur Pflegeaufwand erzeugen. Probieren Sie’s aus!
Wie die weiteren Maßnahmen für testbarere User Stories genau aussehen und was Sie bei ihrer Anwendung und Einführung beachten sollten, erfahren Sie im zweiten Teil des Blogbeitrags.
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
