Kreativ & exploratives Testen

Richtig: Geld einwerfen, dann abbrechen: Kommt der volle Betrag zurück?

Die anderen drei sind der normale Ablauf, an den jeder denkt. Der Abbruch ist ein Seitenpfad: Der Nutzer ändert seine Meinung. Merksatz: Jeder Vorgang braucht einen Test für „mittendrin aufhören“.

Richtig: In der Kabine die Taste des Stockwerks drücken, in dem man gerade steht

„Von hier nach hier“ ist der Nullfall einer Bewegung. Soll sich die Tür öffnen? Nichts passieren? Fährt der Aufzug los und kommt zurück? Nullfälle (leere Liste, Betrag 0, Strecke 0) gehören in jede Testideenliste.

Richtig: Ob die Seite einen hilfreichen Hinweis oder Vorschläge zeigt statt einer leeren Seite

Eine leere Ergebnisseite ohne Erklärung lässt Nutzer ratlos zurück, sie denken oft, die Seite sei kaputt. Gute Shops schlagen ähnliche Begriffe vor oder korrigieren Tippfehler. Exploratives Testen prüft nicht nur „funktioniert es“, sondern auch „versteht der Nutzer es“.

Richtig: Eine leere Datei mit 0 Byte

Alle denken an „zu groß“, kaum jemand an „zu klein“. Eine 0-Byte-Datei kann Vorschauen, Virenscanner oder Weiterverarbeitung zum Absturz bringen. Wieder der Nullfall.

Richtig: Werte testen, die zu klein, zu groß und genau richtig sind

Eine einfache Merkhilfe, die die Grenzwertanalyse auf beliebige Dinge überträgt: Textlänge, Dateigröße, Wartezeit, Anzahl Einträge. Heuristiken wie diese sind Denkanstöße fürs Erkunden, keine starren Regeln.

Richtig: Ein Termin, der vor Mitternacht beginnt und danach endet

Zeit ist die Kategorie, die am häufigsten fehlt: Mitternacht, Monatsende, Zeitumstellung, Zeitzonen, Ablauffristen, langsame Verbindungen. Die anderen Antworten gehören zu Platform, Data und Structure.

Richtig: Einen Kunden löschen, zu dem es noch offene Bestellungen gibt

Interessant wird Löschen dort, wo Daten miteinander verknüpft sind. Was passiert mit den Bestellungen? Werden sie mitgelöscht, verwaisen sie, oder wird das Löschen verhindert? Oft ist das fachlich gar nicht geklärt.

Richtig: Netzverlust genau nach dem Absenden, bevor die Bestätigung ankommt

Der Nutzer weiß nicht, ob die Zahlung durch ist. Versucht er es erneut, droht eine Doppelzahlung. Die App muss beim nächsten Start den echten Status abfragen und anzeigen. Unterbrechungen im entscheidenden Moment sind auf Mobilgeräten der Normalfall, nicht die Ausnahme.

Richtig: Nach der Bestätigung zurückgehen und die Zahlungsseite erneut absenden

Der Browser bietet an, das Formular erneut zu senden. Ohne Schutz entsteht eine zweite Bestellung. Gegenmittel: nach dem Absenden auf eine neue Seite weiterleiten und doppelte Absendungen serverseitig erkennen.

Richtig: Im ersten Tab den Warenkorb leeren, im zweiten Tab mit dem alten Warenkorb bestellen

Der zweite Tab zeigt einen veralteten Stand. Bestellt er trotzdem die alten Artikel, verlässt sich der Server auf Daten aus dem Browser statt auf seinen eigenen Stand. Viele Nutzer arbeiten mit mehreren Tabs, Tests fast nie.

Richtig: Nachnamen müssen mindestens 3 Buchstaben haben

„Li“ und „Ng“ sind verbreitete Nachnamen. Solche Regeln entstehen aus Annahmen, die für den eigenen Bekanntenkreis stimmen. Beim explorativen Testen lohnt es sich, gezielt nach versteckten Annahmen zu suchen.

Richtig: An welchem Tag er in Jahren ohne Schalttag erscheint, oder ob er dann ausfällt

28. Februar, 1. März oder gar nicht? Alle drei Varianten gibt es in echter Software. Wichtig ist, dass es eine bewusste Entscheidung gibt und sich das System daran hält. Wer am 29. Februar Geburtstag hat, merkt den Fehler garantiert.

Richtig: Erkunde den Checkout mit verschiedenen Gutscheinen, um Rechenfehler beim Rabatt zu finden

Eine gute Charter ist eng genug für eine Sitzung und nennt Bereich, Mittel und Ziel. „Teste den Checkout“ ist zu vage, „alle Fehler“ unmöglich. Die Charter lenkt den Blick, ohne jeden Schritt vorzuschreiben.

Richtig: In Bereichen, die geändert wurden und in denen es früher schon oft Fehler gab

Fehler häufen sich: Wo es schon viele gab, kommen meist weitere hinzu. Änderungen sind die zweite große Fehlerquelle. Beides zusammen ergibt die besten Kandidaten. Gleichmäßiges Verteilen klingt fair, verschenkt aber Zeit.

Richtig: Es braucht in UTF-8 vier Bytes, manche Datenbank-Einstellungen erlauben nur drei

Ein „ü“ belegt in UTF-8 zwei Bytes, ein Emoji vier. Die ältere MySQL-Einstellung „utf8“ kann nur bis drei Bytes, erst „utf8mb4“ kann alles. Auch Längenprüfungen zählen Emojis je nach Methode als ein oder zwei Zeichen.

Richtig: Sie bekommt den Gruß am Abend vor ihrem Geburtstag

0 Uhr in Frankfurt ist 18 Uhr am Vortag in New York (6 Stunden Unterschied). Der Gruß kommt also zu früh. In Tokio wäre es 8 Uhr am Geburtstag selbst, also passend. Zeitpunkte, die „für den Nutzer“ gelten, müssen in seiner Zeitzone berechnet werden.

Richtig: Je nachdem, wo gerundet wird, entstehen unterschiedliche Endbeträge

Beide Wege sind zulässig, aber Warenkorb, Rechnung und Buchhaltung müssen denselben verwenden. Sonst passen die Beträge um Cents nicht zusammen. Der Unterschied wächst eher mit der Zahl der Positionen. Entscheidend ist eine festgelegte Regel.

Richtig: Mit früheren Versionen, ähnlichen Berichten und der Erwartung der Nutzer vergleichen

Das „Orakelproblem“: Woher weiß man, was richtig ist? Ohne Spezifikation helfen Vergleiche mit Bekanntem: Widerspricht das Ergebnis der Vorgängerversion, einem anderen Bericht oder dem gesunden Menschenverstand, ist das ein begründeter Verdacht, den man melden sollte.

Richtig: Die Seite mit 200 % Browser-Zoom bedienen

Viele Menschen vergrößern die Darstellung. Dabei überlappen Texte, Buttons verschwinden oder man muss seitlich scrollen. Der Test dauert eine Minute und zeigt oft mehrere Probleme. Die Richtlinien für Barrierefreiheit (WCAG) verlangen genau diese Vergrößerbarkeit.

Richtig: Das Formular ausfüllen, 30 Minuten warten und dann absenden

Tester sind schnell, echte Nutzer nicht. Läuft die Sitzung ab, sind im schlimmsten Fall alle Eingaben weg. Gute Anwendungen warnen vorher, speichern Zwischenstände oder übernehmen die Daten nach erneuter Anmeldung.