Eine Testaufgabe beschreibt ein Ziel im Arbeitskontext und nennt weder Funktionsnamen noch Klickwege. Die Quelle dafür ist das dokumentierte Nutzungsszenario aus der Anforderungserhebung. Der Beitrag zeigt an Formulierungsbeispielen, wie aus dem Szenario eine Aufgabe wird, die den Lösungsweg offenlässt.
Ausgangslage: die Aufgabe verrät die Lösung
„Klicken Sie auf ‚Neuer Auftrag' und füllen Sie das Formular aus." Mit dieser Aufgabe prüft der Test, ob Teilnehmende einen Button finden, dessen Namen sie gerade gehört haben, und ob sie ein Formular ausfüllen können. Ob sie im Arbeitsalltag auf die Idee kämen, an dieser Stelle einen neuen Auftrag anzulegen, bleibt offen. Der Test misst dann die Verständlichkeit der Aufgabe und nicht die Gebrauchstauglichkeit des Produkts.
Aufgaben dieser Art entstehen, wenn der Testplan aus der Oberfläche heraus geschrieben wird. Die Alternative ist, ihn aus dem Nutzungskontext heraus zu schreiben, und die dokumentierte Form des Nutzungskontexts ist das Nutzungsszenario.
Was ein Nutzungsszenario enthält
Ein Nutzungsszenario beschreibt nach ISO 9241-210 eine Situation aus dem Nutzungskontext: die Person in ihrer Rolle, den Auslöser, das Ziel, die Informationen, die ihr vorliegen, die Bedingungen wie Zeitdruck oder Unterbrechungen, und das Ergebnis, das am Ende vorliegt. Szenarien entstehen in der Anforderungserhebung aus Beobachtung und Interviews. Wer sie hat, hat das Material für Testaufgaben. Wer sie nicht hat, holt sie mit Fachleuten aus dem Betrieb nach, bevor der Testplan entsteht.
Vom Szenario zur Aufgabe in vier Schritten
Erstens: Auslöser und Situation übernehmen. Die Aufgabe beginnt mit dem, was im Szenario passiert, damit die Teilnehmenden wissen, in welcher Lage sie sind.
Zweitens: Das Ziel als Endzustand formulieren. Die Aufgabe sagt, was am Ende erreicht sein soll, und nicht, was dafür zu tun ist.
Drittens: Die nötigen Angaben als Testdaten mitliefern. Kundennummer, Anlagenbezeichnung, Datei: alles, was die Person im Betrieb hätte, liegt bereit.
Viertens: Alles streichen, was die Oberfläche nennt. Menüpunkte, Buttons, Modulnamen, Reihenfolge der Schritte.
Formulierungsbeispiele
Leitstand, Bearbeitung einer Meldung. Vorher: „Öffnen Sie die Alarmliste, wählen Sie den Alarm für Umspannwerk Nord und quittieren Sie ihn." Nachher: „Sie haben die Schicht vor einer Stunde übernommen. Aus dem Umspannwerk Nord ist eine Meldung eingegangen. Stellen Sie fest, was dort passiert ist, und sorgen Sie dafür, dass die Meldung als bearbeitet gilt. Die Unterlagen zur Anlage liegen neben Ihnen."
Die zweite Fassung lässt offen, ob die Person über die Alarmliste, das Schema oder die Anlagenübersicht einsteigt. Der Weg, den sie wählt, ist selbst ein Befund. Der Endzustand ist prüfbar: Die Meldung ist als bearbeitet markiert, und die Person kann sagen, was passiert ist.
Kundenportal, Einreichen eines Dokuments. Vorher: „Nutzen Sie die Funktion Dokument-Upload im Bereich Meine Schäden, um den Kostenvoranschlag hochzuladen." Nachher: „Ihre Versicherung hat Sie gebeten, den Kostenvoranschlag der Werkstatt einzureichen. Die Datei liegt auf dem Desktop dieses Rechners. Reichen Sie sie so ein, dass die Versicherung sie erhält."
Die zweite Fassung enthält den Auslöser (die Bitte der Versicherung), die Testdaten (die Datei) und den Endzustand (die Versicherung erhält sie). Ob die Person den Vorgang für abgeschlossen hält, obwohl die Datei abgewiesen wurde, zeigt sich nur, wenn die Aufgabe den Endzustand nennt und nicht den Klick.
Erfolgskriterium je Aufgabe
Jede Aufgabe erhält vor der ersten Sitzung eine Erfolgsdefinition: den Endzustand, die Angaben, die korrekt und vollständig sein müssen, und die Abgrenzung von Erfolg, Erfolg mit Umweg, Teilerfolg und Abbruch. Der Beitrag `erfolgsdefinition-task-erfolg` beschreibt die Stufen. Ohne diese Definition prüft die offen formulierte Aufgabe zwar den richtigen Gegenstand, aber die Einstufung bleibt Auslegungssache.
Grenzen
Fehlen die Szenarien, ist das ein Hinweis darauf, dass die Anforderungserhebung Lücken hat. Aufgaben, die dann mit Fachleuten aus dem Betrieb aufgebaut werden, sind eine Zwischenlösung; sie sollten als solche im Testplan vermerkt werden.
Testdaten müssen zur Situation passen. Eine Aufgabe mit erfundenen Anlagenbezeichnungen, die es im Betrieb nicht gibt, verändert das Verhalten erfahrener Nutzender.
Aufgaben, die aufeinander aufbauen, erzeugen Reihenfolgeeffekte. Wer eine Aufgabe abgebrochen hat, startet die nächste aus einem anderen Zustand. Der Testplan legt fest, wie die Moderation den Ausgangszustand wiederherstellt.
Eine offen formulierte Aufgabe verlängert die Sitzung, weil Teilnehmende suchen dürfen. Das ist beabsichtigt und wird in der Sitzungsplanung berücksichtigt.
Was danach vorliegt
Ein Aufgabenset, in dem jede Aufgabe auf ein dokumentiertes Nutzungsszenario zurückgeht, Auslöser und Endzustand nennt, Testdaten mitbringt und keinen Begriff aus der Oberfläche enthält. Dazu je Aufgabe eine Erfolgsdefinition. Der Wortlaut ist eingefroren und mit Versionsstand versehen, damit die nächste Erhebung dieselben Aufgaben wiederholen kann.