Anforderungen & Analyse

Richtig: Sie ist nicht messbar, es fehlt ein konkreter Zielwert

„Schnell“ bedeutet für jeden etwas anderes. Ohne Zahl kann kein Test bestehen oder scheitern. Erst „unter 2 Sekunden“ macht daraus etwas Prüfbares.

Richtig: 95 % der Suchanfragen werden bei 500 gleichzeitigen Nutzern in unter 2 Sekunden beantwortet

Eine gute Performance-Anforderung nennt Zielwert, Anteil (Perzentil) und Lastbedingung. „Unter 2 Sekunden“ allein lässt offen, ob das für einen Nutzer im leeren System oder unter Volllast gilt, und ob ein einziger Ausreißer schon ein Fehler ist.

Richtig: Gelten die 10 MB pro Datei oder für alle Dateien zusammen?

Beide Lesarten sind plausibel und führen zu völlig anderen Testfällen (5 × 10 MB = 50 MB erlaubt oder nicht). Mehrdeutigkeiten früh zu finden ist einer der günstigsten Wege, Fehler zu vermeiden. Zusatzfrage für Grenzwerte: Sind 10 MB = 10.000.000 oder 10.485.760 Bytes?

Richtig: Wie lange ist der Link gültig, und was passiert bei einer unbekannten E-Mail-Adresse?

Gültigkeitsdauer und unbekannte Adressen betreffen Sicherheit und Fehlerfälle. Daraus folgen gleich mehrere Tests: abgelaufener Link, Link zweimal benutzt, unbekannte Adresse (ohne zu verraten, ob es das Konto gibt). Textdetails sind wichtig, aber nicht kritisch.

Richtig: Given ein leerer Warenkorb, When ich einen Artikel für 20 € hinzufüge, Then beträgt die Summe 20 €

Given beschreibt den Ausgangszustand, When die eine auslösende Aktion, Then das beobachtbare Ergebnis. In den falschen Varianten sind die Rollen vertauscht: Aktionen stehen im Given oder Then, Ergebnisse im When.

Richtig: Then beschreibt die Implementierung statt des sichtbaren Verhaltens

Akzeptanzkriterien sollen beschreiben, was der Nutzer oder das System von außen erlebt, z. B. „Then erscheint die Meldung, dass das Konto gesperrt ist, und auch das richtige Passwort wird abgelehnt“. Ändert sich das Datenbankschema, bliebe das Kriterium sonst falsch, obwohl das Verhalten stimmt.

Richtig: Das Formular soll benutzerfreundlich sein

„Benutzerfreundlich“ ist ein Ziel, kein Kriterium. Prüfbar wird es erst über konkrete Merkmale, wie sie in den anderen drei Antworten stehen, oder über messbare Werte (z. B. 8 von 10 Testpersonen schaffen das Formular ohne Hilfe in unter 2 Minuten).

Richtig: Small – die Story ist viel zu groß für einen Sprint

INVEST steht für Independent, Negotiable, Valuable, Estimable, Small, Testable. Hier stecken mindestens vier Stories in einer. Das ist kaum schätzbar und nicht in einem Sprint testbar. Aufteilen, z. B. „Als Händler möchte ich eine Retoure erfassen …“.

Richtig: Den Widerspruch melden und vor dem Testen klären lassen

Beide Anforderungen können nicht gleichzeitig erfüllt sein. Welche Lösung richtig ist (z. B. Daten sperren statt löschen), entscheidet nicht der Tester, sondern Fachbereich und gegebenenfalls Datenschutz. Ein gefundener Widerspruch vor der Entwicklung ist einer der wertvollsten Beiträge der QA.

Richtig: Ein Datum in der Zukunft wird abgelehnt

Implizite Anforderungen sind die, die jeder für selbstverständlich hält und deshalb niemand aufschreibt. Weitere Kandidaten: 31.02. ablehnen, 29.02. nur in Schaltjahren, unrealistisch alte Daten. Am besten fragt man nach und lässt sie ergänzen.

Richtig: Schritte zur Reproduktion sowie erwartetes und tatsächliches Ergebnis

Ohne Schritte, Testdaten und Ergebnis (z. B. „Meldung ‚Unbekannter Fehler‘ statt Weiterleitung zum Dashboard“) kann niemand den Fehler nachstellen. Dazu gehören Umgebung (Browser, Version, Testsystem) und der verwendete Benutzer.

Richtig: Niedrige Schwere, hohe Priorität

Die Schwere beschreibt die technische Auswirkung: Hier funktioniert alles, es ist nur ein Text. Die Priorität beschreibt, wie dringend es behoben werden muss: wegen der Messe sehr. Die beiden Werte sind unabhängig voneinander und werden oft verwechselt.

Richtig: Hohe Schwere, niedrige Priorität

Ein Absturz ist technisch schwerwiegend. Weil kaum jemand betroffen ist und ein Workaround existiert, kann die Behebung aber warten. Das Gegenstück zur vorherigen Aufgabe.

Richtig: Warenkorb: Menge 0 führt zu negativem Gesamtpreis

Ein guter Titel nennt Bereich, Auslöser und Auswirkung. Man findet ihn später in der Suche wieder und erkennt Duplikate. Ausrufezeichen und allgemeine Wörter wie „kaputt“ helfen niemandem.

Richtig: Genaue Zeitpunkte, betroffene Bestellnummern, Logauszüge und die beobachtete Häufigkeit

Bei sporadischen Fehlern ersetzen Daten die fehlende Reproduzierbarkeit: Mit Zeitpunkt und Bestellnummer findet man die passenden Logs, mit der Häufigkeit lässt sich ein Fix überprüfen. Häufige Ursachen solcher Muster sind Nebenläufigkeit, Timeouts oder Lastspitzen.

Richtig: Über die Verknüpfung von Anforderungen und Testfällen (Traceability-Matrix)

Sind Testfälle mit den Anforderungen verknüpft, zeigt ein Blick, welche Tests betroffen sind, und umgekehrt, welche Anforderungen noch gar keinen Test haben. Die Titelsuche übersieht Tests, in denen Rabatte nur am Rande vorkommen.

Richtig: Alle Funktionen testen, die die Hilfsklasse nutzen, mit Schwerpunkt auf Grenzfällen wie dem Jahreswechsel

Je zentraler eine Komponente, desto größer der Wirkungsbereich einer Änderung. Rechnungen mit falschem Datum können rechtliche Folgen haben. Grenzfälle wie Silvester, Schaltjahre und Zeitzonen sind bei Datumslogik die typischen Fehlerquellen.

Richtig: muss

„Muss“ ist verpflichtend, „sollte“ eine dringende Empfehlung, von der man begründet abweichen darf, „kann“ ist optional. Verwechselt man das, wird entweder zu viel gebaut oder es fehlt Pflichtumfang. Im Englischen sind die Begriffe (MUST, SHOULD, MAY) sogar genormt (RFC 2119).

Richtig: Einen bereits eingelösten Gutschein ein zweites Mal einlösen

Mehrfacheinlösung kostet direkt Geld und wird oft übersehen, gerade wenn zwei Bestellungen parallel abgeschickt werden. Weitere Kandidaten: abgelaufener Gutschein, Mindestbestellwert nicht erreicht, zwei Gutscheine kombinieren.

Richtig: Akzeptanzkriterien gelten für eine einzelne Story, die Definition of Done für jede Story

Akzeptanzkriterien beschreiben das fachliche Verhalten genau dieser Story. Die Definition of Done ist der allgemeine Qualitätsstandard des Teams (Review, Tests, Dokumentation). Das genannte Beispiel gehört also in die Definition of Done.