Ob sein Programm funktioniert oder nicht, klärt jeder Entwickler durch mehr oder minder raffinierte Tests. Bei der Benutzbarkeit verzichten viele auf diesen Schritt. Dabei ist das Testen der Usability nicht schwer und bei Sicherheitssoftware sogar besonders wichtig.

Usability-Tests untersuchen, wie benutzbar ein Programm sich in der Praxis zeigt. Das läuft in zwei Phasen ab: Nummer eins beginnt bereits vor der Implementierung, die Tests finden heraus, wie die Software aussehen soll. Phase zwei folgt nach dem Programmieren. In ihr prüft der Tester das Entwicklungsresultat, das nur zu oft beträchtlich von den ursprünglichen Plänen abweicht.

Erst testen, dann programmieren

Tests während der Entwurfsphase stützen sich meist auf Papierskizzen [1] oder Prototypen, die mit GUI-Buildern (siehe Artikel in diesem Heft) recht schnell entstehen. Sie liefern eine gute Einschätzung, wie User auf das GUI reagieren, und treiben die weitere Entwicklung voran. Beim Paper Prototyping übernehmen Entwickler die Rolle des Computers. Sie interagieren mit dem Anwender und legen ihm jeweils die passende Interface-Skizze vor. Ohne von GUI-Experten zu stammen, eignen sich die Reaktionen der Anwender bestens für Vorhersagen, welche GUI-Entwürfe in der Praxis scheitern.

Ebenfalls nützlich ist es, sich einen oder mehrere typische Anwender vorzustellen und zu überlegen, wie sie vermutlich mit der Software umgehen. Dabei helfen einige Fragen: Was wollen die Anwender erledigen? Wie gut kommen sie mit den Sicherheitsmechanismen zurecht? Wie reagieren sie auf Sicherheitswarnungen? Die Idee dabei: Statt einfach viele vermeintlich nützliche Features anzuhäufen und sich nachträglich zu überlegen, wofür sie gut sein könnten, nimmt der Entwickler die Perspektive des Benutzers ein und konzentriert sich auf die Funktionen, die sein Anwender tatsächlich braucht und die er auch versteht.

Der imaginäre Benutzer darf aber nicht als Ersatz und Ausrede dienen, um auf echte Anwendertests zu verzichten. Viele Projekte verschwenden erstaunlich viel Zeit auf hypothetische Diskussionen, was denn die Anwender theoretisch tun würden, wenn sie am System säßen, statt einen von ihnen tatsächlich bei der Arbeit zu beobachten.

Nur zu oft widersprechen Interfaces den Erwartungen der Anwender, wie etwas funktionieren sollte. Eine Studie mit unterschiedlich ausgebildeten Benutzern untersuchte deren Erwartungen an öffentliche Schlüssel und das Zertifikatmanagement [2]. Die Resultate weichen stark von der X.509-Modellvorstellung ab. Das mag einer der Gründe sein, warum sich X.509-PKI (Public Key Infrastructure) nicht wirklich durchsetzt.

Schlüsselspeicher

Die Benutzer zu fragen, wie sie denken, dass etwas funktionieren sollte, ist eine überragend hilfreiche Entwurfstechnik. Etwa wenn es ums Speichern der privaten Schlüssel geht. Sollen sie in einem einzelnen großen File auf der Festplatte landen? In mehrere Dateien verstreut? In der Registry (falls das Programm unter Windows läuft)? Auf einem USB-Token? Im Homeverzeichnis? In einem versteckten Unterverzeichnis unter Home?

Immer mehr Fragen drängen sich auf: Was passiert, wenn der User auf eines der Files klickt? Was, wenn er einen bestimmten Schlüssel auf eine andere Maschine verlagern will? Wenn er alle kopieren möchte? Was passiert mit den Schlüsseln, wenn der Anwender diesen Rechner oder diesen Account nicht mehr verwendet? Wie sind die Schlüssel geschützt? Wie kommen sie ins Backup? Sollen sie überhaupt dort landen?

Über jede dieser Fragen lässt sich trefflich und endlos streiten. Viel einfacher und zielgerichteter ist es, den Usern selbst diese Fragen zu stellen. Viele werden sich nicht auskennen oder es wird ihnen egal sein, aber im Laufe der Zeit ergibt sich ein klares Bild vom typischen Umgang mit Schlüsseln. Dieses Modell passt auf die Erwartungen der Anwender und ist für sie daher verständlich und einfach zu benutzen.

Bewährte Technik

Usability-Tests sind seit vielen Jahren erfolgreich im Einsatz. Beispielsweise in den frühen 80ern bei Apple: Wann immer ein neues Interface-Feature für Apple Lisa (Abbildung 1) zu implementieren war, hat Larry Tesler einen Apple-Angestellten dazu verdonnert, das Feature zu probieren. Wenn es der Angestellte nicht verstand, haben es die Entwickler verändert oder verworfen.

Abbildung 1: Apples Lisa gilt als Meilenstein in der Entwicklung gut benutzbarer GUIs. Die Entwickler haben jedes neue Feature zunächst mit Normalanwendern getestet und es nur implementiert, wenn es diesen Test bestanden hatte.

Im Gespräch mit den Anwendern zeigen diese häufig Probleme auf, an die kein Entwickler im Traum gedacht hätte. Allerdings funktioniert das nur, wenn die Anwender unvorbelastet an die Sache herangehen – sie dürfen das Interface noch nicht gut kennen, sonst fallen ihnen die Usability-Probleme nicht mehr auf. Es gilt also, die Probanden gelegentlich zu wechseln.

Wer die Sicherheits-Usability seiner Software seriös evaluieren will, kommt um echte Tests vor dem Ausliefern der Applikation nicht herum. Programme dagegen vorsichtshalber als Beta-Release zu kennzeichnen, diese auf die Anwender loszulassen und dann auf Beschwerden zu warten, ist kein Ersatz.

Sobald die Applikation fertig ist, empfiehlt es sich, ein paar Nicht-Techniker an den Rechner zu setzen und sie beim Umgang mit ihr zu beobachten. Sinnvollerweise protokolliert der Tester alle Aktionen der Anwender, ohne sie bei der Arbeit zu stören. Das Protokoll kann einfach die Klicks und Eingaben aufzeichnen; wer den technischen Aufwand treiben kann und will, erfasst zusätzlich die Blickrichtung der Probanden (siehe Kasten “Blickerfassung”).

Blickerfassung

Usability-Forscher wollen die Blickrichtung ihrer Probanden erfassen und auswerten. Das erlaubt ihnen Rückschlüsse, worauf sich die Testperson konzentriert und wohin sie ihre Aufmerksamkeit lenkt. Ein passendes Gerät hat der Lehrstuhl für Ergonomie der TU München unter dem Namen Dikablis entwickelt (digitales kabelloses Blickerfassungssystem). Es ermittelt die Blickbewegung von Versuchspersonen in Echtzeit, zum Beispiel für Untersuchungen von Kfz-Fahrerassistenz- und -informationssystemen oder zur Evaluierung von Software-GUIs. Es eignet sich sogar zur psychologischen Grundlagenforschung. Technik und Funktion Dikablis besteht aus den drei Komponenten kopfbasierte Erfassungseinheit (Abbildung 2), Empfänger und Recorder. Als Erfassungseinheit dient eine handelsübliche Schwimmbrille, auf der die Entwickler alle nötigen Komponenten montierten: Augenkamera, Blickfeldkamera und Funksender. Im Versuch zeigen die Probanden ein natürliches Blickverhalten, da kein Kabel ihre Bewegungsfreiheit einschränkt. Die Blickfeldkamera sitzt auf dem vorderen Teil der Schwimmbrille, zwischen den Augen auf Stirnhöhe. Sie liefert mit ihrem Weitwinkelobjektiv ein hochauflösendes Bild des Blickfelds der Versuchsperson. Die Augenkamera erfasst dagegen die Augen der Versuchsperson. Um das Blickfeld nicht einzuschränken, ist die Augenkamera seitlich an der Brille montiert und auf einen wärmereflektierenden Spiegel gerichtet, der sich vor dem rechten Auge befindet (Abbildungen 3a und 3b). Die Kamera arbeitet im Nah-Infrarotbereich und erfasst hinter dem Infrarotfilter das vom Spiegel reflektierte infrarote Bild des Auges. Der Spiegel lässt Licht im sichtbaren Bereich durch und wirkt daher für das menschliche Auge transparent. Der Infrarotfilter entfernt den sichtbaren Anteil, übrig bleibt die IR-Reflexion des Auges. Drei Infrarot-LEDs an der Brille beleuchten das Auge und erhöhen damit die Lichtstärke des reflektierten Bildes. Abbildung 3a: Schematischer Aufbau der Augenkamera: Der Infrarotspiegel vor dem rechten Auge schränkt die Sicht kaum ein, reflektiert die IR-Strahlen aber zur Kamera. Diese erkennt, in welche Richtung die Person blickt. Guter Empfang Jede der zwei Kameras verfügt über einen Sender, der die Videosignale zur Empfangseinheit überträgt. Der Empfänger arbeitet nach dem True-Diversity-Prinzip, für jede Kamera stehen jeweils zwei separate Empfängereinheiten mit eigener Antenne zur Verfügung. Die Einheit leitet das stärkere Signal zum Recorder weiter, um mögliche Signalausfälle (Drop-outs) zu minimieren. Als Rekorder dient ein auf Echtzeitblickerfassung zugeschnittener Computer mit Dual-Core-Prozessorsystem und optimiertem Speicherbus. Mit ihm gelingt es, die in Echtzeit digitalisierten Eingangssignale schnell weiterzuverarbeiten und zu speichern. Auf dem Rekorder läuft auch die Dikablis-Blickerfassungssoftware. Sie erzeugt ein so genanntes Blending, also eine Überlagerung von Blickfeld- und Augen-Videobild. Zu Versuchsbeginn kalibrieren die Tester das System, um die errechnete an die tatsächliche Blickrichtung anzupassen. Danach können sie die aktuelle Blickrichtung in Form eines Fadenkreuzes im Blickfeld-Videobild live am Monitor verfolgen. Zur späteren Auswertung speichert Dikablis beide Videoströme zusammen mit den Blending-Informationen. Damit ist es nachträglich möglich, die Kalibrierung zu verbessern. Die Versuchsperson trägt die Erfassungseinheit wie eine Brille. Bevor sie einen Blickfilm aufzeichnen, justieren die Tester mit wenigen Mausklicks die Pupillenerkennung. Anschließend kalibrieren sie die Blickerfassung. Dabei blickt die Versuchsperson auf einen bestimmten Punkt, der Tester passt die von der Software erkannte Blickrichtung an. Mit Hilfe eines weiteren Punkts in derselben Entfernung ist die Blickebene einzustellen. Wegen der nichtlinearen Bewegung des Auges lässt sich die Blickerfassung jeweils nur für eine bestimmte Ebene in festem Abstand zur Versuchsperson kalibrieren. Wechseln im Test die Abstände, kalibrieren die Tester nachträglich in der Aufzeichnung jede nötige Ebene. Abbildung 3b: So haben die Forscher das Modell aus Abbildung 3a technisch realisiert. Die Augenkamera montierten sie seitlich an der Taucherbrille. Sie erfasst über einen IR-Spiegel indirekt die Blickrichtung des Trägers. Relevante Messwerte Was der Proband beobachtet, ist für Dikablis unwichtig. Beim Test der Usability von Software ist es ein Monitor mit den GUIs. Hier sind die Blickbewegung, Blickverteilung oder Fixationsdauer wichtig. Anwender verfolgen beim Benutzen von Software eine bestimmte Strategie, abhängig von der Aufgabenstellung. Beim Surfen im Internet möchten sie Inhalte und Informationen leicht und schnell finden, beim Arbeiten mit GUIs die Bedienelemente gut finden und gezielt treffen. Um die Suchstrategie zu untersuchen, ist primär die Blickreihenfolge der Anwender relevant. Dabei zeigt sich zum Beispiel, dass der erste Blick beim Surfen meist auf das zuerst geladene Element fällt. Mit dieser Erkenntnis ist es möglich, durch geschickte Optimierung der Ladezeiten gezielt bestimmte Inhalte – etwa Sicherheitswarnungen – im Aufmerksamkeitsbereich des Users zu platzieren. Die Analyse der Blickspur eignet sich zur Verbesserung von Layout und Informationsgestaltung: Geschickt platzierte Inhalte erhöhen die Bedienfreundlichkeit und steuern die Informationsaufnahme. Eine Blickverteilungsanalyse quantifiziert, welchem Inhalt oder welchem Bedienelement die Versuchspersonen Beachtung schenkten. Das Verfahren analysiert die Häufigkeit und Blickdauer pro Element und gibt Aufschluss über das Leseverhalten. Die Anwender lesen beim Surfen beispielsweise nur 17 bis 26 Prozent der Haupttexte vollständig. Je länger eine Seite, umso stärker prägt sich diese Tendenz aus. Die Länge der komplett gelesenen Volltexte beträgt durchschnittlich 1,3 bis 1,6 und maximal 2,5 Bildschirmlängen. Neben der Blickverteilung spielt die Fixationsdauer eine wichtige Rolle. Je schwieriger die Informationsaufnahme, desto länger fixiert der Proband eine Stelle. So lässt sich der Wiedererkennungswert von Schaltflächen ermitteln. Je kürzer die Fixationsdauer einer Schaltfläche, umso schneller hat die Versuchsperson sie aufgespürt. (Christian Lange und Martin Wohlfarter, Lehrstuhl für Ergonomie, TU München)

Die Auswertung folgt später. Für welchen Teil der Aufgabe brauchen die Anwender am längsten? Wann gucken sie ins Handbuch oder fragen sogar nach Hilfe? Haben sie die Aufgabe auf sichere Weise geschafft? Haben sie dabei ihre eigenen Erwartungen an Sicherheit erfüllt oder nur die des Entwicklers? Ist es möglich, problematische Stellen mit Hilfe sicherer Defaults zu beheben? Mit wie vielen Fehlermeldungen sehen sie sich konfrontiert?

Abbildung 2: Das Blickerfassungssystem Dikablis arbeitet kabellos und wird wie eine Brille getragen. Damit ist Usability-Forschung an praktisch jedem Arbeitsplatz möglich, ohne den Probanden übermäßig zu stören.

Überraschungsmoment

Tests mit der fertigen Implementierung führen oft zu höchst überraschenden Resultaten, die keiner der Entwickler je erwartet hätte (siehe Kasten “Beispiel E-Mail”). So waren die Entwickler des Anonymisierers Tor [3] verblüfft, als User ihre privaten Schlüssel an andere Tor-Benutzer sendeten, obwohl sie es hätten besser wissen sollen. Die Lösung war ganz einfach: Seit der Dateiname mit »secret_« beginnt, ist allen Anwendern klar, dass sie dieses File besser nicht herumschicken.

PGP löst das Problem auf ähnliche Weise, es erlaubt dem User nur öffentliche Schlüssel aus einem Keyring zu exportieren. Das gilt auch, wenn der Anwender ausdrücklich den privaten Ring als Quelle angibt. Windows geht bei seinem Schlüsselhandling nach PKCS#12 genau umgekehrt vor und blendet jeden Unterschied zwischen privatem und öffentlichem Teil aus. Es legt beide Schlüssel in eine gemeinsame so genannte digitale Identität, also ein PKCS#12/PFX-File. Kein User ahnt, dass die Datei seinen geheimen Key enthält. Ein Paper [4] vergleicht die Situation mit Rattengift in einer Fruchtsaftflasche, die gut zugänglich im Küchenschrank steht.

Kartenspiele

Auch bei Hardware überrascht die Erwartung der testenden User oft die Entwickler. Zum Beispiel bei den privaten Keys, die auf einer Smartcard liegen oder auf einem USB-Crypto-Token. Theoretisch sind USB-Token in fast jeder Hinsicht den Smartcards überlegen: Sie sind kompakter, weniger empfindlich, einfacher zu schützen (weil kein Standard die Größe vorschreibt), flexibler (weil sie zusätzliche Schaltungen enthalten können), brauchen kein spezielles Lesegerät und so fort. Smartcards haben einen einzigen Vorteil: Sie erinnern die Anwender nicht wie USB-Tokens eher an herkömmliche Metallschlüssel, die sie an Verwandte und Freunde verleihen und beim Nachbarn hinterlegen.

Für Smartcards gilt dieser lockere Umgang nicht. Niemand gibt sie aus der Hand, wenn sie mit einem großen Foto-Aufdruck des Besitzers personalisiert sind, dazu noch dessen Namen und Geburtstag nennen, eine eingescannte Unterschriftenprobe sowie Hologramme oder andere auffällige Merkmale. Manchmal genügt eben ein Stück angewandter Psychologie, um Sicherheit zu erhöhen.

Testspirale

User-Interface-Design ist üblicherweise ein interaktiver Vorgang. Die drei Schritte Design, Implementierung und Test genügen daher in der Praxis kaum, um alle potenziellen Probleme abzuschütteln. Das gilt besonders für den komplexen und schwer vorhersehbaren Bereich der Sicherheits-GUIs. Statt eines einfachen Testdurchlaufs empfehlen sich mehrere Runden mit Usertests, die mit einem recht generischen Design beginnen und diesen auch als Low-Fi bekannten Prototyp anhand der Erfahrungen und der Benutzerkommentare verfeinern.

Kleine Stichprobe genügt

Diese Tests müssen weder komplex noch teuer sein. Usability-Experte Jakob Nielsen zeigt, dass bereits eine Gruppe von fünf Anwendern sehr verlässliche Usability-Ergebnisse liefert [5]. Je mehr User teilnehmen, umso mehr überschneidet sich deren Herangehensweise, die Tester erfahren von jedem zusätzlichen Anwender immer weniger Neues. Wer 20 Kandidaten zur Verfügung hat, sollte sie lieber in vier Gruppen einteilen, denen er unterschiedliche Entwicklungsstände der Software vorlegt.

Ähnliches gilt für heterogen zusammengesetzte Gruppen, die sowohl aus Laien als auch aus Experten bestehen. Hier ist es besser, sie in zwei homogene Einheiten aufzuspalten, da sie sonst widersprüchliche Ergebnisse liefern.

In der Praxis bewährt es sich, die User während des interaktiven Designprozesses ihre Gedanken laut aussprechen zu lassen. Das klärt, warum sie sich für ihre jeweiligen Aktionen entschieden haben. Es fallen potenzielle Solpersteine und verwirrende Programmteile auf – vorausgesetzt die Tester werten die Kommentare auch wirklich aus.

Gut möglich etwa, dass ein Anwender eine Dialogbox übersieht oder eine Meldung falsch versteht und daher später in eine Sackgasse rennt. Dann wird er wilde Theorien aufstellen, woran er und die Software gescheitert seien. Die Tester müssen erkennen, dass die Wurzeln des Problems an anderer Stelle liegen.

Das Verbalisieren beeinflusst aber auch die Handlungen der Anwender. Weil sie ihre Aktionen erklären und begründen, denken sie ausgiebiger darüber nach und ändern folglich ihr Verhalten. In Tests zeigt sich, dass sprechende User eine GUI-Aufgabe viel besser erledigen als ihre schweigenden Kollegen. Als Gegenmaßnahme könnten Tester ihre Probanden zunächst schweigend die Aufgabe erledigen lassen und nur an kritischen Punkten einhaken. Fragen wie “Was erwarten Sie, dass als Nächstes passiert?” oder “Haben Sie diese Reaktion so erwartet?” decken sofort fehlerhafte Annahmen im Interface-Design auf.

Trickreich

Statt eigene Aktionen zu erklären, setzt eine Variante des Verfahrens auf zwei User, die ihre Handlungen gegenseitig kommentieren. Dabei agieren sie ungezwungener und verfälschen das Ergebnis weniger als beim Einzeltest.

Beim Interface-Test entlarven geschickt gestellte Aufmerksamkeitsfallen, ob ein Proband ausreichend aufpasst. Das sind kleine Anomalien oder Fehler im GUI, über die ein Kandidat eigentlich stolpern müsste, wenn er seine Aufgabe wirklich versteht. Sollte er sich nur durchschummeln, dann wird er von diesen Fallen nichts bemerken und mit seinen Versuchen fortfahren.

In Standardapplikationen ist das Durchschummeln meist in Ordnung, solange das Ergebnis stimmt. Beispielsweise beim Entfernen des Rote-Augen-Effekts zählt nur, dass hinterher das Foto natürlich wirkt. Bei Sicherheitsaufgaben ist die Versuch-und-Irrtum-Methode höchst gefährlich. Selbst wenn das Ergebnis wie erwartet aussieht, kann durch einen Fehler in der Zwischenzeit längst ein Angreifer sein Unwesen treiben. Geschickt platzierte Kopiererfallen entlarven solch gefährliches Durchschummeln.

Nicht nachlassen

Selbst nach der Auslieferung ist das Testen nicht beendet. Weitere Testschritte finden quasi in der Retrospektive statt. Die meisten Verfechter dieser Methode empfehlen drei Monate bis ein Jahr nach einer Release als besten Zeitpunkt für eine Review. In dem Zeitraum seit der Veröffentlichung hatten Anwender Gelegenheit, sich mit der Software vertraut zu machen und Problemfelder zu erkennen. Auch das Programm hatte ausreichend Gelegenheit, sich in freier Wildbahn zu bewähren und dabei Schwächen im Design zu offenbaren.

Wichtig sind nachträgliche Tests vor allem für Situationen, mit denen die Entwickler nicht rechneten und auf die auch kein Anwendertest stößt. Als die Autoren von RFC 1738 [6] URLs der Form » Benutzer@Host« in ihre Spezifikation aufnahmen, habe sie sicherlich nicht mit Gaunern gerechnet, die solche URLs konstruieren: »http://www.bankofamerica.com@1234567/«. Die Adresse führt zu einem Rechner mit der IP-Adresse 1234567, sieht aber viel mehr aus wie der DNS-Name einer Bank.

Tests in feindlicher Umgebung (also in der realen Welt) liefern wertvolle Hinweise für sicheres Interface-Design. Obwohl Angreifer kaum bei den Tests kooperieren werden, hilft das jahrelang angesammelte Wissen über typische Angriffstechniken. Neue Applikationen sollten alte Fehler nicht wiederholen. Bücher wie [7] und [8] diskutieren etliche Fehlfunktionen detailliert, um sie künftig in Software zu vermeiden, die sicherheitsrelevante Informationen verarbeitet oder anzeigt.

Man muss es nur tun

Zu viele Entwickler verzichten vielleicht auf Usability-Tests, weil der Begriff kompliziert und nach Aufwand klingt. Dabei sind es sehr einfache und praktikable Methoden, die viel zur Aufklärung beitragen. Gerade bei sicherheitsrelevanten GUIs ist der Schritt unverzichtbar: Eine Security-Funktion, die niemand korrekt verwendet, ist nutzlos. (fjl)