Usability- und UX-Reviews als Teil der Qualitätssicherung
Wenn Sie denken, gutes Design ist teuer, dann sollten Sie sich die Kosten von schlechtem Design ansehen.
Dr. Ralf Speth, CEO, Jaguar Land Rover
In den letzten zehn Jahren hat sich die Nutzererfahrung (User Experience, UX) zum echten Unterscheidungsmerkmal zwischen guten und großartigen Anwendungen entwickelt.
Die technische Seite der Softwareentwicklung ist zu einem großen Teil ein gelöstes Problem. Die wirklichen Möglichkeiten für überdurchschnittlichen Erfolg bei Softwareprodukten liegen mittlerweile in der UX. Die nächste revolutionäre App wird über eine sofort verständliche Nutzeroberfläche verfügen. Das hat zu einem forschungsbasierten, UX-fokussierten Ansatz bei der Produktentwicklung geführt.
Die Ergebnisse dieses Fokus sprechen für sich.
Zum Beispiel bringt laut einem Forrester Research Report jeder in UX investierte Dollar eine Rendite von 100 Dollar. Zudem zeigt eine Studie über einen Zeitraum von 10 Jahren, dass die finanzielle Performance von designgetriebenen Unternehmen die des S&P um 219% übertrifft.
Es gibt auch die legendäre Geschichte, wie allein das Ändern des Textes auf einem Button einem E-Commerce-Unternehmen innerhalb eines Jahres 300 Millionen Dollar zusätzlichen Umsatz brachte!
Doch trotz des ganzen Hypes und Tamtams gibt es zu jeder Anwendung mit großartiger Nutzererfahrung mehrere, bei denen sie fehlt oder gar gravierend fehlt. Die schrecklichen Cases sind leicht zu erkennen: Sie machen Lust, ein Loch in den Laptop-Bildschirm zu schlagen oder das Handy aus dem Fenster zu werfen. Darwin kümmert sich um diese Anwendungen.
Die wirkliche Herausforderung sind Apps mit mittelmäßiger UX. Das sind die berüchtigten „Splitter im Kopf“-Erfahrungen, bei denen Sie einfach nicht herausfinden können, warum Sie sie nicht mögen!
Ich höre Sie schon sagen, „Das wissen wir alles; ich lese schließlich The QA Lead – was hat das also mit mir zu tun?“ Ich komme gleich dazu.
Die Bedeutung von UX
In meinen frühen Tagen als Leiter von Entwicklerteams arbeiteten wir an einem großen Softwareprojekt für einen unserer Kunden. Das Ganze war Teil einer umfassenderen Digitalisierungsstrategie, die für diesen Kunden umgesetzt wurde. Das Team war typisch zusammengesetzt, hauptsächlich aus Softwareentwicklern und QA-Ingenieuren, die mit Scrum in zweiwöchigen Sprints arbeiteten.
Es gab ein kleines UX-Team, das jedoch größtenteils projektübergreifend eingesetzt wurde. In der Regel stießen die UX-Leute zu Beginn eines Projekts zu den täglichen Stand-ups dazu, aber sobald das visuelle Design vom Kunden abgenommen war, übergaben sie alle Templates des Visual Designs sowie die Abläufe – und machten mit anderen Projekten weiter.
Bei der ersten Sprint-Demo war der Kunde vor allem darüber besorgt, dass das visuelle Design und die Benutzeroberfläche nicht exakt den Designvorlagen entsprachen. Zudem gab es eine Lücke zwischen der vorgeschlagenen Funktionalität und dem, was tatsächlich umgesetzt war.
Beachten Sie, die Lücke war nicht riesig, aber egal wie sehr wir versuchten, den Kunden zu beschwichtigen, dass die UX-Aspekte in einem der folgenden Sprints aufpoliert würden, zeigte seine Körpersprache, dass ihm das nicht gefiel.
Glücklicherweise meldete sich unsere Team-QA-Leiterin zu Wort, sagte, dass dies eine Ausnahme gewesen sei und sich nicht wiederholen würde. Und dann tat sie etwas Beeindruckendes. Lassen Sie mich das hier skizzieren:
- Sie nahm sich vor, ihr UX-Wissen durch intensives Lesen aufzufrischen.
- Dann führte sie selbst eine grundlegende heuristische UX-Überprüfung der gelieferten Funktionalität durch, sprach mit den UX-Kollegen und holte sich bei Bedarf deren Unterstützung.
- Sie legte neue Aufgaben in JIRA an, um aus UX-Sicht die Diskrepanz zwischen Versprochenem und Geliefertem zu beheben.
- Sie organisierte einen Termin mit unserem UX-Leiter und holte dessen Zustimmung ein, dass ein neuer Prozess eingeführt wird: Die visuellen Aspekte der Anwendung werden ab sofort in jedem Sprint und nicht erst am Ende verbessert.
- Schließlich brachte sie auch unserem QA-Team UX-Grundlagen näher, damit offensichtliche Probleme frühzeitig erkannt und gemeinsam beseitigt werden können.
Das Sahnehäubchen? Bei der nächsten Sprint-Demo strahlte der Product Owner/Kunde – und nach ein paar Monaten wurde unsere QA-Leiterin zur QA-Managerin befördert! 😉
Romantische versus klassische Perspektiven auf die Realität
Diese ganze Episode brachte mich dazu, über die riesige Kluft zwischen der Sichtweise von uns im Engineering auf eine Anwendung und der Sichtweise von Kunden und Nutzern nachzudenken. Robert Pirsig spricht in seinem wegweisenden Buch Zen und die Kunst, ein Motorrad zu warten von zwei Betrachtungsweisen der Realität: der klassischen und der romantischen Sichtweise.
Laut Pirsig betrachten und beurteilen diejenigen, deren dominierende Perspektive romantisch ist, Dinge danach, wie sie erscheinen. Sie interessieren sich in erster Linie dafür, wie etwas ist, und kümmern sich nicht darum, wie es funktioniert – um die zugrunde liegende Ordnung. Dies ist die künstlerische Hälfte der Kunst-/Wissenschaftsspaltung.
Wir Ingenieure & Wissenschaftler hingegen vertreten die klassische Sichtweise, bei der die Schönheit in den Mechanismen liegt, die der äußeren Form zugrunde liegen. Ingenieure können Schönheit in Python-Code oder unter der Motorhaube eines Autos sehen, was für Vertreter der romantischen Seite hässlich aussieht.
Wie alles andere ist dies natürlich keine binäre Klassifizierung, sondern ein Kontinuum, wobei die meisten von uns vorwiegend eine Perspektive bevorzugen.
Es gibt einige interessante Implikationen dieser Art, die Welt zu klassifizieren:
1. Die dominierende Perspektive der meisten Menschen ist standardmäßig entweder klassisch oder romantisch, nicht beides.
2. Menschen – denken Sie an Kunden, intern oder extern – mit romantischer Perspektive sind denjenigen mit klassischer Perspektive zahlenmäßig weit überlegen. Wenn Sie jemals technischen Support für Familie oder Freunde geleistet haben, wissen Sie, wovon ich rede!
3. Sehr wenige können zwischen den Modi wechseln, und selbst für diese ist es eine Tätigkeit, die Anstrengung erfordert.
4. Realität = klassisch + romantisch. Sie schließen sich nicht gegenseitig aus. Beide sind essenzielle Aspekte des Ganzen. Schönheit ist funktional. Funktion kann schön sein.
Nehmen Sie beispielsweise Blumen. Sie haben so wunderschöne Muster, die scheinbar keine Funktion haben. Doch die Schönheit, die wir in Blumen sehen, hat eine zugrunde liegende Struktur, die in der Mathematik verwurzelt ist: Die Fibonacci-Folge bestimmt die Struktur und Muster, die wir in Blumen sehen. Struktur und ätherische Schönheit gehen in der Natur Hand in Hand.
Und es geht nicht nur um Schönheit. Die Anordnung der Samen in einer Sonnenblume folgt der Fibonacci-Folge und dem Goldenen Schnitt, um möglichst viele Samen in der Blume unterzubringen. Die gleichen Prinzipien gelten für Technik und Benutzererfahrung.
Damit kommen wir endlich zum Kern dieses Artikels: Qualitätssicherungsingenieure sind ideal positioniert, um von beiden scheinbar konkurrierenden Perspektiven zu profitieren.
Die Rolle der Software-QA bei UX / Usability
Als Testprofi haben Sie deutlich mehr Erfahrung mit Benutzeroberflächen als der durchschnittliche Entwickler oder Nutzer.
Sie haben so viele Anwendungen streng und wiederholt (bis zur Ermüdung!) getestet, dass Sie im Hinblick auf UX vielleicht schon das Niveau von höherer Ordnung bzw. 4D-Denken erreicht haben, wie der sprichwörtliche Schachgroßmeister, der in Positionen denkt, im Gegensatz zu mir, der Mühe hat, zu entscheiden, welche Figur als Nächstes gezogen werden soll! ;-)
Deshalb gibt es trotz des massiven Trends zur Automatisierung – was ohne Zweifel eine großartige Entwicklung ist – einiges, was für manuelles Testen spricht. Schließlich werden Anwendungen von Menschen genutzt, also ist es sinnvoll, auch eine menschliche Perspektive ins Testen einzubringen.
So führen Sie als Testingenieur eine UX-/Usability-Überprüfung durch
Wenn Qualitätssicherung UX berücksichtigen soll, muss sie schon parallel zur Designphase beginnen, also zu Beginn des Lebenszyklus. Hier sind die Schritte, mit denen Sie die UX-Überprüfung in Ihren Testprozess einbinden und zum QA-Universalgenie werden können!
Usability-Heuristiken für User Interface Design
Machen Sie sich mit den 10 allgemeinen Prinzipien des Interaktionsdesigns von Jakob Nielsen vertraut. Dieses Set von Leitlinien ist ein verlässlicher Bezugspunkt für jede Usability-Überprüfung. Berücksichtigen Sie diese Prinzipien sowohl in Diskussionen mit dem UX-Team als auch in Ihrem Testplan. Sie können auch eine Vielzahl grundlegender Kurse zu Usability und UX-Design absolvieren.
Lernen Sie die Prinzipien der Barrierefreiheit
Vielleicht haben Sie in der Vergangenheit bereits Barrierefreiheitstests als Teil Ihres Testplans durchgeführt, aber das Verständnis der Grundprinzipien der Barrierefreiheit – wahrnehmbar, bedienbar, verständlich, robust – verschafft Ihnen die Möglichkeit, Dinge zu erkennen, die anderen entgehen könnten.
Das UX-Team ist Ihr neuer Treffpunkt
Seien Sie kein Fremder: Lernen Sie das UX-Team im Projekt kennen. Arbeiten Sie mit ihnen zusammen. Teilen Sie Ihren Testplan mit ihnen und holen Sie sich Feedback dazu, was Sie aus UX-Sicht einbauen können.
Der Nutzen dieser Zusammenarbeit ist wechselseitig, denn Ihr Testplan liefert dem Designteam Einblicke in die Umsetzbarkeit von Designfeatures, die sie vorschlagen möchten. Als QA-Leiter sollte Ihr Verhältnis zum UX-Team genauso eng sein wie das zu den Entwicklern.
Analytics in Ihren Testplan einbeziehen
Die Nutzungsanalysen des Produkts, das Sie testen, sind eine wahre Fundgrube für Tester. Analytics kann helfen, Risikobereiche und Nutzerverhalten zu identifizieren. Diese Erkenntnisse wiederum helfen Ihnen, Korrekturen so früh wie möglich im Produktlebenszyklus zu erkennen und zu priorisieren.
Shift Left, so weit es geht
Das Produkt, das Sie testen, ist wie ein Baby. Sie müssen sicherstellen, dass es von Anfang an die nötige Unterstützung bekommt – quasi ab der Entstehung des Produkts. Gehen Sie ganz an den Anfang zurück.
Vor der Entwicklung
Testen Sie bereits in der Designphase, sobald ein Prototyp verfügbar ist. Nutzen Sie Ihre Erfahrungen mit Anwendungen und Ihr Wissen über Usability- und Barrierefreiheitsrichtlinien, um zu prüfen, ob noch Änderungen nötig sind, BEVOR das Produkt in die Entwicklungsphase geht.
Ist QA noch nicht Teil der Designphase, sorgen Sie – wenn möglich – dafür, dass dies geschieht.
Gezieltes manuelles Testen
Durchlaufen Sie beim manuellen Testen die gesamte Nutzungserfahrung des Produkts von Anfang bis Ende. Stellen Sie die richtigen Fragen, denken Sie wie ein Nutzer und wie ein QA-Engineer.
Betrachten Sie das Produkt zunächst mit Abstand und nehmen Sie eine breitere Perspektive ein. Haben Sie Freude an der Nutzung?
Sehen Sie sich das Produkt dann genauer an. Ist es einfach zu bedienen? Sind die Abläufe selbsterklärend und intuitiv? Sind sie mühsam oder langsam? Gibt es Überschneidungen oder doppelte Aktionen, die für den Nutzer lästig sein könnten? Ist das Design benutzbar auf verschiedenen Bildschirmgrößen?
Abschließend
Die Zukunft der Arbeit gehört denen, die über mehrere komplementäre Fähigkeiten verfügen, die fast unmöglich von Maschinen übernommen werden können (lesen Sie aber gerne meinen Artikel über KI in der Testautomatisierung, um einen Eindruck zu bekommen, was sie können).
Ein QA-Polyhistor mit UX-Kenntnissen zu werden, kann eine großartige Möglichkeit sein, Ihre natürlichen Kompetenzen und Erfahrungen einzubringen und zusätzlichen Mehrwert zu schaffen, ohne zu viel Aufwand oder sich zu weit vom eigenen Fachgebiet zu entfernen.
Ist das etwas, das Sie begeistert? Oder denken Sie, dass UX nur am Rande relevant ist? Lassen Sie es mich unten in den Kommentaren wissen.
Wenn Sie mehr erfahren möchten, hier ein Podcast zum Lesen/Hören: WIE OPEN-SOURCE-SOFTWARE DIE INTEGRATION IN DER AUTOMATION ENGINEERING VEREINFACHT (MIT JAMES WALKER UND SANJAY KUMAR)
