Der Freigabetermin steht, das Team sitzt in der letzten Planungsrunde, und jemand fragt, ob ein Usability-Test jetzt noch etwas verändern kann. Wenige Wochen vor dem Marktstart lässt sich an einem Produkt weniger ändern als zu Projektbeginn. In unseren Projekten vor Marktstarts war es trotzdem regelmäßig mehr, als das Team in dieser Runde annahm: Bedienfolgen, Benennungen, Fehlermeldungen und Onboarding sind bis kurz vor der Freigabe beeinflussbar; Architektur und Hardware sind es nicht mehr. Diese Checkliste ordnet, was ein Test vor dem Termin noch verändern kann und welche Fragen er deshalb beantworten soll.
Einordnung
Bevor Sie ausrollen, wissen Sie, ob es funktioniert. Dieser Satz gilt, wenn der Test vor dem Marktstart eine Entscheidung erreicht, die noch offen ist. Ein Test, dessen Befunde nach der Freigabe eintreffen, dokumentiert Probleme, die dann in der ersten Serie stehen. Wir haben solche Berichte geschrieben, und sie wurden gelesen, als niemand mehr etwas ändern konnte. Gehen Sie deshalb die Punkte unten mit dem Team durch, bevor Sie den Testplan schreiben. Sie klären, welche Entscheidungen zum Testzeitpunkt noch offen sind, welche nicht, und was der Test dafür leisten muss. Zu jedem Punkt steht, woran Sie im Review erkennen, ob die Angabe erhoben oder geschätzt ist.
Die Checkliste
Der Freigabetermin und der Weg dorthin sind bekannt. Der Test muss vor dem letzten Zeitpunkt abgeschlossen sein, an dem eine Änderung noch in die Freigabe kommt. Dieser Zeitpunkt liegt in vielen Vorhaben Wochen vor dem Marktstart. Holen Sie ihn mit Datum aus dem Release-Plan; ein Termin aus dem Gedächtnis der Projektleitung ist eine Schätzung.
Die noch veränderbaren Elemente sind aufgelistet. Bedienfolgen, Benennungen, Fehlermeldungen und Onboarding lassen sich in der Regel bis kurz vor der Freigabe anpassen. Lassen Sie die Liste von der Entwicklungsleitung bestätigen. Sie ist der Rahmen für die Testfragen, und ohne die Bestätigung ist sie eine Annahme des Produktteams.
Die nicht mehr veränderbaren Elemente sind benannt. Architektur und Hardware stehen fest. Befunde dazu gehören in das Backlog der nächsten Generation und in den Bericht, in die Testfragen gehören sie nicht. Erhoben ist die Liste, wenn sie aus demselben Gespräch mit der Entwicklungsleitung stammt wie die vorige.
Die Entscheidung, die der Test verändern kann, ist aufgeschrieben. Ein Satz in der Form „Wenn Nutzende die Aufgabe X mit dem Prototyp nicht abschließen, ändern wir Y vor der Freigabe" macht den Test anschlussfähig. Schreiben Sie den Satz gemeinsam mit der Person, die Y freigibt, und notieren Sie ihren Namen; ohne diesen Namen ist der Satz eine Absicht.
Der Prototypenstand ist als Testgegenstand geeignet. Unfertige Prototypen lassen sich testen, wenn die Aufgaben, die geprüft werden sollen, durchgängig bedienbar sind. Klicken Sie jede Testaufgabe vor dem Test selbst durch; was fehlt, wird im Test simuliert oder ausgeklammert und im Bericht ausgewiesen. Geprüft ist der Stand nach diesem Durchgang, geschätzt nach der Aussage der Entwicklung.
Die Testaufgaben stammen aus Nutzungsszenarien. Eine Aufgabe beschreibt, was eine Person im Nutzungskontext erreichen will, keine Funktion des Systems. Aus Funktionen abgeleitete Aufgaben prüfen, ob Knöpfe funktionieren, und übersehen, ob die Aufgabe gelingt. Im Review erkennen Sie die Herkunft daran, ob neben jeder Aufgabe das Szenario mit Person, Ziel und Situation steht.
Die Teilnehmenden entsprechen dem Nutzungskontext. Wer das Produkt später benutzt, entscheidet, ob es funktioniert. Teilnehmende aus dem Panel oder aus dem Feld müssen dieselben Aufgaben und Bedingungen kennen. Erhoben ist die Passung, wenn der Screener, der Fragebogen zur Vorauswahl, nach der Aufgabe in der letzten Zeit fragt; ein Panelprofil mit Alter und Beruf reicht dafür nicht.
Die Umgebungsbedingungen sind berücksichtigt. Was im Labor bestanden hat, kann im Feld abgebrochen werden: Licht, Lärm, Handschuhe, Zeitdruck und Unterbrechungen gehören in den Testplan, wenn sie zum Nutzungskontext gehören. Prüfen Sie im Review, ob die Bedingungen aus einer Kontextbeschreibung stammen oder ob das Team sie aus der Vorstellung heraus aufgeschrieben hat.
Der Weg vom Befund in die Korrektur ist geklärt. Es steht fest, wer auf Basis der Schweregrade entscheidet, bis wann, und in welches Backlog Befunde gehen, die vor dem Termin nicht mehr behoben werden. Erhoben ist der Weg, wenn die genannten Personen ihn kennen und der Termin für die Entscheidungsrunde im Kalender steht.
Die Rework-Kosten sind mit eigenen Zahlen geschätzt. Was eine Änderung nach dem Marktstart in Ihrer Organisation kostet, ist der Maßstab für den Aufwand des Tests davor. Fremde Kennzahlen ersetzen diese Rechnung nicht. Nehmen Sie die letzte Änderung nach einem Marktstart und lassen Sie sich vom Controlling die Kosten nennen; alles andere ist eine Schätzung und wird so geführt.
Ohne diese Angaben prüft der Test die falschen Fragen
Wer die veränderbaren Elemente nicht kennt, bekommt Befunde zur Hardware, die niemand mehr ändern kann. Wer die Entscheidung nicht aufgeschrieben hat, bekommt einen Bericht ohne Adressaten. Wer die Umgebung weglässt, erfährt nach dem Marktstart, dass das Onboarding im Feld nicht funktioniert. In einem unserer Projekte lag der Bericht mit den Befunden zum Onboarding am Tag der Freigabe vor; seitdem klären wir den Freigabetermin als ersten Punkt, bevor wir eine Testaufgabe schreiben.
Die Strecke beschreibt in den folgenden Beiträgen, wie die Entscheidung vor den Testplan kommt, wie Testaufgaben aus Nutzungsszenarien entstehen und was ein Test mit unfertigen Prototypen leisten kann. Der nächste Beitrag: `restbudget-beendet-die-gestaltung`.