Asynchroner Remote Test – theoretisch betrachtet

In meinen beiden vorherigen Beiträge habe ich den synchronen Remote Test vorgestellt (Beitrag 1 bzw. Beitrag 2). Hier soll nun ein kurzer theoretischer Überblick über die Methode des asynchronen Remote Tests gegeben werden. Außerdem werden einige Vor- und Nachteile die dieser Methode innewohnen aufgeführt.

Wie es für Remote Tests typisch ist, nehmen die Testpersonen hierbei von ihrem Rechner zu Hause oder am Arbeitsplatz aus teil. Anders als beim synchronen Remote Test, bei welchem immer noch eine direkte Interaktion zwischen Testperson und Testleiter geschieht, ist es bei dieser Variante darüber hinaus möglich, dass die Testperson zu jeder ihr passenden Zeit an dem Test teilnehmen kann, also sowohl eine räumliche als auch eine zeitliche Trennung zwischen dem Testleiter und der Testperson besteht.
Die bei einem Test anfallenden Daten werden automatisch gesammelt und gespeichert, so dass sie dem Testleiter später zur Auswertung vorliegen. Aus diesem Grund wird der asynchrone Remote Test teilweise auch als automatisierter Usability-Test bezeichnet.

In der vorhandenen Literatur werden unterschiedliche Datenerhebungsverfahren zur Methode des asynchronen Remote Tests gezählt. Folgend werden drei Verfahren angeführt, wie sie bei Hartson et al. (1996) beschrieben werden.

Als eine mögliche Ausführung des asynchronen Remote Tests wird die Datenerhebung mittels eines Fragebogens beschrieben, welcher durch eine bestimmte Nutzeraktion, bspw. dem Erreichen einer zuvor definierten Seite ausgelöst wird. Folglich ist die Erhebung hierbei auf subjektive Daten beschränkt und fängt keine Daten ein, die direkt beim Auffinden spezifischer Usability-Probleme behilflich sind.

Eine andere Möglichkeit wird der instrumentierte Remote Test gesehen. Bei dieser Methode wird der getesteten Applikation ein Code eingefügt, welcher ein Protokoll der Nutzeraktionen, z.B. Mausklicks und Tastatureingaben, anfertigt. Diese Variante beeinträchtigt den Nutzer in keiner Weise bei seiner Interaktion mit dem System. Einschränkend wird zu dieser Methode jedoch genannt, dass es meist schwierig ist, aus den Log-Files konkrete Usability-Probleme abzuleiten.

Weiterhin wird die Möglichkeit des semi-instrumentierten Remote Tests angeführt. Hierbei geben die Nutzer Rückmeldung über kritische Vorkommnisse, sogenannte „Critical Incidents“, welche sowohl positiv als auch negativ sein können. Stößt eine Testperson bei der Nutzung auf ein Problem oder einen Aspekt, der ihr gut gefällt, kann sie dies über einen Button melden und einen kurzen Kommentar hinterlassen. Hierfür erhalten Sie vor dem Test eine kurze Einweisung. Negative Critical Incidents werden als Indikatoren für Usability-Probleme angesehen. Die Eingaben der Nutzer werden zusammen mit Kontextinformationen, beispielsweise Mausklicks oder sogar Screenvideos, zur späteren Analyse abgespeichert. Hierbei ist schwierig, das zum Auffinden von Usability-Problemen nötige Maß an Kontextinformationen zu den Critical Incidents abzuspeichern, da die Meldung über einen solchen meist mit etwas Verzögerung geschieht.

Vor- und Nachteile des asynchronen Remote Tests
Einige der Vorteile des asynchronen Remote Tests decken sich mit denen des synchronen Remote Tests. Hier sind zu nennen:

  • Einbezug schwer erreichbarer Zielgruppen
  • Umgehen/abschwächen der Laborsituation
  • Möglichkeit eine große Anzahl an Testpersonen zu testen
  • Nutzer arbeiten mit unterschiedlicher Hardware und verschiedenen Softwareeinstellungen
  • Zielgruppen können einfacher abgebildet werden, da man bei der Auswahl der Testpersonen nicht geografisch eingeschränkt ist.

Ein zusätzlicher Vorteil des asynchronen Remote Tests ist, dass eine so große Anzahl an Testpersonen getestet werden kann, dass die (qualitativen) Aussagen der einzelnen Testpersonen durch diese Stichprobengröße quantifiziert werden können.
Ebenfalls von Vorteil ist, dass viele der Tools zur Durchführung eines asynchronen Remote Test es ermöglichen, auf einfache Weise Klick-, Befragungs- und Kommentardaten integriert und entweder auf der Ebene einzelner Testpersonen oder über alle Testpersonen hinweg, auszuwerten.
Als weiterer Vorteil ist zu nennen, dass die Testleiter nur noch in der Vor- und Nachbereitung des Tests involviert sind, die Phase der Datenerhebung aber ohne aktive Teilnahme abläuft.

Als Nachteil des asynchronen Remote Tests ist zu nennen, dass er den Kunden (Anbietern / Entwicklern der Website) nicht erlaubt die Testpersonen bei der Nutzung zu beobachten. Diese Beobachtung ist meist jedoch sehr eindrucksvoll und führt bei den Kunden zu „Aha-Erlebnissen“ bei der Bedeutung von Usability-Problemen. Hier ist auch zu nennen, dass bei dieser Methode die Mimik der Testpersonen nicht in die Auswertung einbezogen werden kann. Allerdings erwähnen einige Autoren, dass die Analyse von Gesichtsausdrücken keine oder nur wenige Hinweise auf die Existenz eines Usability-Problems geben.
Ein Kritikpunkt der auch schon beim synchronen Remote Test auftritt, ist, dass bei der Datenerhebung Probleme durch Firewalls entstehen können.
Weiterhin wird von einigen Autoren kritisch gesehen, dass die Testpersonen zur Durchführung des Tests teilweise ein Plugin installieren müssen, wogegen sich viele Nutzer aber aufgrund von Sicherheitsbedenken sträuben bzw. es ablehnen.

Bekannte Tools zum Durchführen von asynchronen Remote Tests sind „WebEffective“ des amerikanischen Anbieters Keynote und das durch SirValUse bekannte LeoTrace. Beide Tools lassen sich dem semi-instrumentellen Ansatz zuschreiben und verfügen über breite Möglichkeiten der Datensammlung. In einem folgenden Artikel wird die Durchführung eines asynchronen Remote Tests mit Hilfe des Tools WebEffective beschrieben.

Hab Ihr denn schon Erfahrung mit der Methode asynchroner Remote Test bzw. habe ich eurer Meinung nach etwas bei der kurzen Beschreibung vergessen?
Ich freue mich auf eure Kommentare.

Kurzer Literaturhinweis, wenn jemand es nochmal selbst nachlesen möchte.
Hartson, H. R.; Castillo, J. C.; Kelso, J.; Neale, W. C. (1996): Remote evaluation: the network as an extension of the usability laboratory. In: Proceedings of the SIGCHI Conference on Human Factors in Computing Systems: Common Ground, ACM Press, New York, S. 228-235.

2 Gedanken zu „Asynchroner Remote Test – theoretisch betrachtet

  1. Thorsten Wilhelm

    Klasse Beitrag … Es ist immer wieder schön zu lesen, dass die einzelnen Methoden jede Menge Vor- aber eben auch Nachteile hat. Es gibt nicht *die* Methode, die alles kann, alle Fragen beantwortet und umfassende Daten bereitstellt. Das macht es nicht immer einfach, ist doch bereits die Auswahl der richtigen Methode eine Aufgabe, die viel Wissen erfordert. Umgekehrt kann man durch einen geschickte Kombination von Methoden eine ganzheitlichen Analyse einer Web-Applikation erreichen. Hier sind wir als Usability-Consultants gefragt; es reicht nicht mehr nur Angebot zu einzelnen Methoden & Verfahren bereitzustellen; wir müssen uns bereits bei der Erstellung von Briefings „einschalten“ und dabei unterstützen die richtige Methodenauswahl „anzufragen“. Das geht nur dann, wenn Unternehmen Usability-Consultants einstellen oder aufbauen. Hoffe sehr, dass das in den kommenden Monaten zunimmt; leider kenne ich nur wenige Sites / Online-Shops, die über einen Usability-Abteilung verfügen …

    Antworten

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.