UX- und UI-Testing stellen zwei verschiedene Fragen
| UI-Testing | Speichert der Button den Datensatz. Aktualisiert sich die Liste. Objektiv überprüfbar. Automatisierbar. Sollte bei jeder Änderung laufen. |
| UX-Forschung | Konnten die Nutzer den Button finden. Haben sie das Ergebnis verstanden. Braucht Menschen. Lässt sich nicht automatisieren und sollte nicht vorgetäuscht werden. |
Ein Produkt kann jeden UI-Test bestehen und in der Bedienung trotzdem eine Qual sein. Es kann in einer Usability-Session begeistern und in der Produktion Daten verlieren. Keine der beiden Tätigkeiten ersetzt die andere.
Was Automatisierung ehrlicherweise leisten kann
Funktionale Korrektheit jedes Ablaufs. Die gesamte erste Spalte.
Mechanische Prüfungen zur Barrierefreiheit. Fehlende Labels, Kontraste, Fokusreihenfolge. Echter Nutzen, aber eben nicht die gesamte Barrierefreiheit.
Konsistenzprüfungen. Ob dieselbe Aktion an drei Stellen gleich reagiert – ein UX-Problem in testbarer Form.
Was sie nicht kann
Ob der Ablauf sinnvoll war. Ob die Fehlermeldung geholfen hat. Ob jemand aufgegeben hat. Dafür braucht es Menschen, und die nützliche Sichtweise ist: Automatisierung verschafft die Zeit dafür zurück, indem sie den manuellen Regressionsdurchlauf überflüssig macht.
Die Schnittmenge, die sich zu automatisieren lohnt
Es gibt einen schmalen Bereich, in dem sich beide tatsächlich treffen – und das ist die am wenigsten genutzte Automatisierung, die den meisten Teams zur Verfügung steht.
Konsistenz ist eine UX-Eigenschaft in testbarer Form. Erzeugt dieselbe Aktion an allen drei Stellen, an denen sie vorkommt, dieselbe Bestätigung. Sieht ein Fehler überall wie ein Fehler aus, oder scheitert ein Screen stillschweigend. Steht die primäre Aktion in jedem Modal an derselben Position. Nichts davon erfordert ein Urteil darüber, ob das Design gut ist, und alles davon nehmen Nutzer als Schlamperei wahr.
Für die Menschen, die den jeweiligen Screen gebaut haben, ist all das zudem unsichtbar, weil jeder Screen für sich genommen konsistent ist. Sie über Screens hinweg zu prüfen, ist billig und deckt eine Art von Beschwerde auf, nach der weder funktionale Tests noch Usability-Forschung suchen.
Die Falle
Teams streichen die UX-Forschung, weil die UI-Testabdeckung hoch ist. Die Begründung klingt plausibel und ist ein Kategorienfehler: Abdeckung sagt aus, dass das Produkt tut, wofür es gebaut wurde, und sagt nichts darüber, ob es das Richtige war, es zu bauen.
Die gesündere Aufteilung sieht so aus: Automatisierung übernimmt die repetitiven Prüfungen, und die dadurch frei werdenden Stunden fließen in die Forschung, die nur Menschen leisten können.
Nichts davon braucht ein Terminal. Legen Sie im TestSprite-Dashboard ein Projekt an, beschreiben Sie die Prüfung in normaler Sprache und richten Sie sie auf Ihre App. Entwickler in Ihrem Team können dasselbe über die Kommandozeile steuern, wenn ihnen das lieber ist – zu finden im CLI-Repository.
Der Auslöser zählt mehr als der Mechanismus. Koppeln Sie die Prüfung an Ihr Deployment-Ereignis, wird jede Änderung geprüft, ohne dass jemand sich dafür entscheiden muss; die GitHub App erledigt das vom Dashboard aus, und ein Schritt mit GitHub Actions erledigt es direkt in Ihrem Workflow.
Was TestSprite automatisiert – und was es Ihnen überlässt
Es automatisiert die gesamte funktionale Spalte: Funktioniert der Ablauf, wird der Zustand korrekt zwischen den Schritten weitergereicht, stimmt das, was dem Nutzer angezeigt wird, mit dem überein, was tatsächlich passiert ist. Die Testfälle werden aus Ihrem Produkt generiert, in normaler Sprache verfeinert und laufen bei jeder Änderung.
Es deckt außerdem die Konsistenzprüfungen ab, die in der Schnittmenge liegen, etwa ob dieselbe Aktion überall, wo sie vorkommt, gleich reagiert – eine UX-Beschwerde in testbarer Form.
Was es Ihnen bewusst überlässt, ist die Forschung. Der Wert des entfallenen manuellen Regressionsdurchlaufs liegt in den Stunden, die er zurückgibt, und das Argument dieser Seite lautet: Diese Stunden sollten in Gespräche mit Nutzern fließen, nicht zurück ins Backlog.
Kann KI Usability-Testing übernehmen?
Sie kann Pfade durch eine Oberfläche simulieren, was für die Abdeckung nützlich ist. Sie kann Ihnen nicht sagen, ob ein echter Mensch verwirrt wäre, denn das ist eine Tatsache über Menschen.
Ist Barrierefreiheit UX oder UI?
Beides. Die mechanischen Teile lassen sich gut automatisieren, die erlebbaren Teile brauchen Menschen, idealerweise Menschen, die assistive Technologien nutzen.
Wie oft sollten wir UX-Forschung betreiben?
Wenn sich etwas substanziell ändert oder wenn die Kennzahlen zeigen, dass Nutzer abspringen. Nicht in einem festen Rhythmus um seiner selbst willen.
Wer verantwortet was?
UI-Testing liegt meist bei der Entwicklung. UX-Forschung liegt bei Design oder Produkt. Probleme entstehen, wenn man annimmt, ein Team decke beides ab.
Verringert gutes UX den Bedarf an UI-Testing?
Nein. Ein gut gestalteter Ablauf kann durch eine Codeänderung trotzdem kaputtgehen, und genau das findet UI-Testing.
Das eine fragt, ob es funktioniert, das andere, ob es die Nutzung wert ist.
UX- und UI-Testing beantworten unterschiedliche Fragen. Automatisieren Sie die funktionale Hälfte, einschließlich der mechanischen Barrierefreiheit, und stecken Sie die frei gewordene Zeit in die Forschung, für die es Menschen braucht. Eine hohe Abdeckung ist kein Grund, nicht mehr mit Nutzern zu sprechen.