Der Custom Usability Index (CUI) In Action – Usability Tests in der agilen Softwareentwicklung

Ausgangspunkt – Was bisher geschah…

In zwei früheren Blogbeiträgen habe ich einerseits das Konzept des Custom Usability Index vorgestellt, sowie die Vorbereitungsphase genauer erläutert, in welcher Usability-Kategorien individualisiert und gewichtet werden. Mit diesem Blogbeitrag möchte ich tiefer auf die tatsächliche Anwendung eingehen und erklären, welche Schritte notwendig sind, um am Ende eine valide CUI-Bewertung zu erhalten.

Folgender Stand soll als Startpunkt unseres Anwendungsbeispiels dienen. Wir befinden uns in der Entwicklung einer neuen Web-Applikation für einen Business-Kunden. Der verantwortliche Product Owner hatte zu Projektstart die Usability-Kategorien durch einen UX-Experten erklärt bekommen und seine Zielzustände definiert. Diese hat er im Anschluss entsprechend seiner Anforderungen priorisiert und so den Grundstein zur regelmäßigen Messung der zukünftigen Anwendung mit dem CUI gelegt. Nach einiger Entwicklungszeit ist nun ein erster Release Kandidat auf das QA-System deployt worden und steht zum Test bereit.

Der Custom Usability Index (CUI) in Action – Jetzt geht es Ihrer Software an den Kragen!

Wie geht es jetzt weiter? Für den Test der 13 Usability-Kategorien sind mehrere, verschiedene Testmethoden möglich. Die Auswahl der Testmethodik orientiert sich neben der Eignung für die jeweilige Usability-Kategorie auch an zahlreichen weiteren Faktoren. Die Verfügbarkeit der Endnutzer, das Wissen des Usability-Testers sowie zeitliche und monetäre Ressourcen spielen eine wichtige Rolle. Das Wunschszenario, mit mehreren Usability-Testern inklusive Protokollanten zahlreiche Endnutzer einem ausgiebigen und zeitlich intensiven Test zu unterziehen, ist in der Praxis selten der Fall.

Was verlieren wir durch das Eindämmen der Ressourcen? Hauptsächlich Genauigkeit und Unabhängigkeit in der Messung. Jedoch ist dies nicht das primäre Ziel des CUI. Durch die Tests, egal in welchem Ausmaß, sollen hauptsächlich Probleme und Verbesserungspotentiale aufgezeigt werden. Das heißt, selbst wenn das Ergebnis von Test A zu Test B abweicht sind die Schmerzpunkte klar und ermöglichen so Ansätze für eine besser nutzbare Software zu schaffen. Eine ressourcenschonende Variante des Testens ist die heuristische Evaluation. Die heuristische Evaluation ist eine Inspektionsmethode, bei der eine Gruppe von Usability-Experten eine Anwendung auf die Einhaltung von ausgewählten Richtlinien und Heuristiken (in diesem Fall die dem Nutzungskontext angepassten Usability-Kategorien des CUI) untersucht. Nach Nielsen finden ca. 7 Tester 80% der gesamten Usability-Fehler, Folge-Tests sind weniger ergiebig, da kaum noch weitere Fehler gefunden werden.

Nielsen (1995): Anzahl der heuristischen Evaluationen vs. gefundene Usability Probleme https://www.nngroup.com/articles/how-to-conduct-a-heuristic-evaluation/

In der Praxis von agilen Softwareentwicklungsprojekten ist es jedoch Luxus überhaupt mehrere Usability-Experten für den Test zu bekommen, so dass üblicher Weise 1-2 Experten die Evaluation durchführen. Ein mit der Anwendung vertrauter Usability-Experte sollte je nach Komplexität der Anwendung und dem Dokumentationsumfang in der Lage sein, innerhalb von 1-2 Tagen ein brauchbares Messergebnis zu erzielen. Das heißt Sie können auch schon mit mehreren „kleineren“ Usability-Tests die Qualität Ihrer Software steigern und erste Verbesserungen erzielen.

Ein Beispiel – Die Messung von 13 Kategorien, 31 Kriterien „in a nutshell“.
Starten wir mit der ersten Kategorie Effektivität. Der Product Owner hat für diese Kategorie folgenden Zielzustand definiert: „Der Nutzer hat jederzeit Zugriff auf die zur Aufgabenerledigung notwendigen Funktionalität und erreicht diese in höchstens 2 Schritten. Er wird dabei nur mit den für ihn im Moment notwendigen Informationen belastet (Daten sollen im Vordergrund stehen).“

Zusätzlich wurde Effektivität mit der Fibonacci-Zahl 3 gewichtet.
Die Kategorie Effektivität besteht aus den zwei Kriterien Funktionsumfang und Angemessenheit. Für das Kriterium Funktionsumfang müssen nun die verschiedenen Use-Cases der Webanwendung überprüft und zusätzlich geschaut werden, ob die dazu benötigten Funktionen in höchstens 2 Schritten erreichbar sind.

Der Zielzustand für dieses Kriterium ist für den aktuellen Release Kandidaten vollständig erfüllt und es wird somit die Maximalbewertung von 5 Punkten erteilt.
Weiter geht es mit dem zweiten Kriterium Angemessenheit. Es fordert, dass der Nutzer nur mit den für ihn im Moment notwendigen Informationen belastet wird und die Daten im Vordergrund stehen.

Durch mehrere kleinere Auffälligkeiten gibt es 2 Punkte Abzug und somit eine Bewertung von 3 Punkten. Zusammengerechnet mit der Bewertung des Kriteriums Funktionsumfang bedeutet dies eine durchschnittliche Bewertung von 4 Punkten für die übergeordnete Kategorie Effektivität.
Die Messung der übrigen 12 Kategorien und 29 Kriterien sollte analog zum obigen Beispiel erfolgen. Da die vollständige Dokumentation eines CUI-Tests jedoch den Rahmen dieses Blogbeitrages sprengen würde, springen wir einen Schritt weiter und schauen uns die Endberechnung einmal genauer an.

Beispiel einer fertiggestellten CUI-Berechnung

Obige Tabelle zeigt eine vollständig ausgefüllte CUI-Berechnungsmatrix nach Testbeendigung. Der finale CUI-Wert setzt sich wie folgt zusammen:

  • Berechnung des Durchschnittswertes einer Kategorie (Summe der Bewertung / Anzahl der Kriterien)
  • Berechnung der relativen Gewichtung (Gewichtungswert der Kategorie / Summe aller Gewichtungswerte)
  • Berechnung des finalen Kategorienwertes (Durchschnittswert der Kategorie * relative Gewichtung)
  • CUI-Wert = Summe der finalen Kategorienwerte
  • CUI-Erreichungsgrad = ((CUI-Wert – 1) / 4)

Rechnen wir dies einmal anhand unseres Beispiels nach:

  • Bewertung der Kategorie Effektivität (Funktionsumfang 5 Punkte + Angemessenheit 3 Punkte) / 2 Kriterien = 4 Punkte
  • Summe der Gewichtungen aller Kategorien = 24
  • Relative Gewichtung der Kategorie Effektivität = 3/24 = 0,125
  • Einzelwert der Kategorie Effektivität = Bewertung von 4 * relative Gewichtung 0,125 = 0,50

Juhu geschafft – Und nun?

Erst einmal herzlichen Glückwünsch, dass Sie sich um das Wohl Ihrer Nutzer gekümmert haben. Doch nun gilt es weitere Schritte einzuleiten:

  • Entwickeln Sie Lösungsvarianten für die aufgezeigten Probleme in Form von Wireframes und Prototypen
  • Zeigen Sie den Einfluss kommender User Stories in Bezug auf die verschiedenen Usability Kategorien auf
  • Hinterfragen Sie die Anforderungen Ihres Product Owners … Sie sind der Experte!
  • Zeigen Sie aktiv Alternativen auf und setzen Sie die vorgesetzten Anforderungen nicht einfach stillschweigend um
  • Führen Sie in regelmäßigen Abständen einen erneuten CUI-Test durch und tracken Sie so den Einfluss der Verbesserungen bzw. neuer Anforderungen auf die Nutzbarkeit Ihrer Software

Durch den Custom Usability Index ist es möglich mit geringem Ressourcenverbrauch hilfreiche Ergebnisse zu erzielen. Das leichtgewichtige Vorgehen bettet sich nahtlos in den agilen Softwareentwicklungsprozess ein und zeigt Schwachstellen Ihrer Software auf. Durch regelmäßige Tests wird ein langfristiges Tracking möglich und Usability tatsächlich greifbar gemacht. Trauen Sie sich, Ihre Nutzer werden es Ihnen danken!

Ein Einblick in Usability Tests in der agilen Softwareentwicklung!

Wie die Digitalisierung den Fachbereichstest ändert – OOP 2017

Umfrage auf der OOP 2017

Ein wesentlicher Erfolgsbaustein eines jeden Dienstleistungsunternehmens ist es, die Zielgruppe Ihrer Services zu kennen. Nicht nur um seine Leistungen bestmöglich zu platzieren, sondern auch um den Kunden eine möglichst optimal auf sie zugeschnittene Lösung zu bieten. Schon seit Langem setzen wir als Saxonia Systems AG (seit 03/2020 ZEISS Digital Innovation) daher nicht nur auf eine möglichst enge und partnerschaftliche Zusammenarbeit mit unseren Kunden, sondern führen auf verschiedenen Konferenzen Umfragen durch. Ziel ist es dabei die Herausforderungen – mit denen Fachbereich und IT täglich zu kämpfen haben – besser kennen zu lernen.

Auf der OOP in München vom 30.01. – 03.02.2017 nutzten wir so wieder die Gelegenheit, um im Testing & Quality Forum eine kleine aber doch recht heterogene Menge an Personen zu befragen. Die Teilnehmer unserer Umfrage waren in unterschiedlichsten Rollen an der Softwareentwicklung in Unternehmen beteiligt – wir befragten Project Owner, Architekten, Testmanager, Entwickler, Projektleiter, Anwendungsmanager, Gruppenleiter, […] und konnten dadurch einige Erkenntnisse gewinnen.

Als Einstieg in unsere Befragung wollten wir von den Teilnehmern wissen, wie viele IT-Teil-Systeme in der Firma in der sie arbeiten zum Einsatz kommen. Wie sich herausstellte, sind die meisten Systemlandschaften durchaus sehr komplex. Mehr als 50% der Befragten gaben dabei 30 oder mehr Teil-Systeme an. Der nächst größere Anteil (22,6%) gab an, immerhin mehr als 15 Teil-Systeme im Einsatz zu haben.

Wie viele IT-Teil-Systeme werden in Ihrer Firma genutzt? - Diagramm
Abbildung 1: Wie viele IT-Teil-Systeme werden in Ihrer Firma genutzt?

Die nächste Frage behandelte den Integrationsgrad der Systeme, das heißt zwischen wie vielen der vorhandenen Systeme ein Datenaustausch stattfindet, bzw. wie viele der vorhandenen Systeme sich gegenseitig Daten liefern. Hier hielten sich die Meinungen ungefähr die Waage. Das heißt der Integrationsgrad der Systeme wurde nahezu durchgehend mit mittel (die Hälfte der vorhandenen Systeme tauscht Daten aus bzw. liefert Daten) bis hoch ([fast] alle Systeme kommunizieren miteinander, bzw. liefern Daten) bewertet.

Wie schätzen Sie den Integrationsgrad der Systeme ein? - Diagramm
Abbildung 2: Wie schätzen Sie den Integrationsgrad der Systeme ein?

Als erschwerender Faktor bei Softwareentwicklungsprojekten kommt meist hinzu, dass unterschiedliche Akteure an der Entwicklung der Systemlandschaft beteiligt sind. Wir stellten dazu die Frage: „Wer entwickelt bei Ihnen?“, wobei eine Mehrfachauswahl der Antworten (eigene Entwicklungsabteilung, externer Dienstleister vor Ort, externer Dienstleister anderswo) möglich war. Lediglich ein Viertel der Befragten gaben an, das nur die firmeneigene Entwicklungsabteilung für den Ausbau der Systeme verantwortlich ist. Die restlichen 74% werden durch externe Dienstleister entweder vor Ort oder anderswo (32% sogar beides) unterstützt. Die entsprechende Entwicklung erfolgt dabei zum Großteil agil (80%), dicht gefolgt von klassischen Vorgehensmodellen (48%). Aber auch eine „chaosgetriebene“ Entwicklung kommt in 16% der Fälle durchaus noch vor.

Wie wird bei Ihnen bzw. für Sie entwickelt? - Diagramm
Abbildung 3: Wie wird bei Ihnen bzw. für Sie entwickelt?

Gerade die letzte Form der Entwicklung neigt dabei natürlich zu einer gewissen Fehleranfälligkeit, weswegen unsere letzte Frage sich vor allem auf die Qualität der Software, bzw. das Testen, bezog. Wir wollten also von den Interviewten wissen, ob bei Ihnen überhaupt Tests durchgeführt werden, und wenn ja, wer diese durchführt. Auch hier war eine Mehrfachauswahl der Antworten möglich.

Welch großen Stellenwert Tests bei der Softwareentwicklung einnehmen, zeigte sich an dieser Stelle noch einmal deutlich. Bei allen Befragten wurden Tests (welche Art des Testens war dabei nicht Bestandteil der Umfrage) realisiert. Fast alle (96%) setzten dabei auf Entwicklertests, weitere 71% auf Tests durch den Fachbereich. 67,7 % der Teilnehmer gaben sogar an die Tests durch ein dediziertes Testteam bzw. eine Testorganisation durchführen zu lassen. Immerhin noch 38% führten außerdem die Anwender als testende Instanz auf. Wobei man hier sicher mit einem Schmunzeln sagen kann, dass der Anwender im Endeffekt ja ohnehin immer den letzten Praxistest der Software durchführt.

Wer führt bei Ihnen Tests durch? - Diagramm
Abbildung 4: Wer führt bei Ihnen Tests durch?

Zusammenfassend kann man also sagen, dass sich bei unserem „Markttest“ folgendes Mehrheitsbild darstellte: Der Großteil der Befragten hat es mit komplexen Systemlandschaften zu tun, die durch eine hohe Komplexität durch sehr viele IT-Teil-Systeme und einen mittleren bis hohen Integrationsgrad charakterisiert sind. Des Weiteren sind in den meisten Fällen externe Dienstleister einbezogen, die sich an klassischen oder agilen Vorgehen orientieren. Die agilen Vorgehensmodelle sind dabei die Basis für ein Großteil der Entwicklungsprojekte. Außerdem spielen Tests eine sehr große Rolle. Die Durchführenden sind dabei sehr unterschiedlich, grundsätzlich ist man sich aber darüber einig, das Softwaretests bei der Entwicklung nicht weg zu denken ist.

Wir sind uns dabei durchaus bewusst, dass dies keine repräsentative Studie darstellt und die Besucher des Testing & Quality Forums mit Sicherheit von Haus aus ein gewisses Interesse an Softwarequalität mitbringen. Trotzdem sind die Ergebnisse für uns doch recht aussagekräftig und interessant.