Verwenden von Zeichen und Skripten beim Testen von Kalendern



    Hallo! Mein Name ist Evgeny Emelyanov, ich bin der Leiter des Mail.Ru-Kalenderprojekts . Heute werde ich Ihnen erzählen, wie wir die mobilen Anwendungen des Kalenders mithilfe von Zeichen und Skripten getestet haben. Solche Tests werden häufig in der Usability-Forschung und bei der Untersuchung der Benutzerinteraktion mit der Benutzeroberfläche verwendet. Wir haben uns entschlossen, ähnliche Techniken für das klassische manuelle Testen mobiler Anwendungen anzuwenden. Anfangs war das Team skeptisch, aber die Ergebnisse waren sehr positiv, daher möchten wir unsere Erfahrungen mit Ihnen teilen.

    Hinweis: In Marketing und benutzerzentriertem Design sind Charaktere fiktive Charaktere. Sie repräsentieren verschiedene Benutzergruppen, unterteilt nach Geografie, Demografie, Verhalten und Gewohnheiten. Vermarkter verwenden Zeichen, um verschiedene Marktsegmente zu beschreiben.

    Zeichen können nützlich sein, um die Ziele, Wünsche und Einschränkungen der Verbraucher einer Marke oder eines Produkts zu bestimmen. Sie können dabei helfen, Entscheidungen über verschiedene Neuentwicklungen, Änderungen der aktuellen Funktionalität und des Designs zu treffen. Benutzerzeichen sind eine Darstellung der Ziele und des Verhaltens hypothetischer Benutzergruppen eines Produkts. In den meisten Fällen werden Zeichen aus Daten erstellt, die aus Umfragen und Benutzerinterviews stammen. Die Daten enthalten eine Beschreibung der Verhaltensmuster, Ziele, Fähigkeiten, Fähigkeiten und der externen Umgebung. Um ein realistischeres Aussehen zu erzielen, werden fiktive kleine persönliche Merkmale hinzugefügt. Normalerweise wird für jedes Produkt mehr als ein Charakter erstellt, es sollte jedoch immer einen Hauptcharakter geben, der für die Hauptzielgruppe repräsentativ ist.

    Das Problem ist überfällig

    Bevor wir mit der Verwendung der Zeichen begannen, war der Testprozess weitgehend wie folgt strukturiert:
    1. Der Entwickler erstellt einen Build.
    2. Es werden Rauchprüfungen durchgeführt.
    3. Die in diesem Build ausgeführten Aufgaben werden überprüft.
    4. Der gesamte von den Änderungen betroffene Funktionsblock wird getestet.
    5. Wenn der Build eine Beta-Version werden kann, werden alle Benutzerfälle vollständig getestet.

    Überprüfen Sie die Bedingungen. In unserem Fall ist "Benutzerfall" ein kleines Szenario für die Verwendung der Anwendung. Beispiel: Hinzufügen eines Ereignisses mit bestimmten Parametern. Probleme traten in zwei Richtungen auf. Erstens waren die Yuzkes größtenteils „synthetisch“. Aus offensichtlichen Gründen brachten Tester Daten mit, die von der Realität getrennt waren, und versuchten häufiger, die Anwendung gezielt zu "brechen". Es muss getan werden, aber etwas zu brechen ist ein separater Benutzerfall. Zweitens traten komplexe Fehler an der Kreuzung von Benutzerfällen oder bei einer bestimmten Implementierung mehrerer Benutzerfälle auf. Daher wurden solche Fehler häufiger von Benutzern und nicht von Testern gefunden. Das hat uns sehr traurig gemacht.

    Fiktive Freunde

    Das Kalenderprojekt ist klein, gemütlich und fast familiengeführt. Wir versuchen, unter Umgehung des technischen Supports direkt mit den Benutzern zu kommunizieren. Daher kennen wir unsere Benutzer und ihre Hauptaufgaben gut und sind uns der meisten Probleme bewusst. Es war nicht schwer, Porträts der Hauptgruppen zu machen.

    Normaler Benutzer : Fügt Kalender mit Ereignissen (Feiertage, Sport, Filme) und Geburtstagen hinzu und verwendet verschiedene Erinnerungen daran. Fügt gelegentlich persönliche Ereignisse oder neue Geburtstage hinzu.



    Mobil : Verwendet den Kalender nur auf einem Smartphone - iOS oder Android. Sehr selten greift auf das Webinterface zu. Die Veranstaltungen sind hauptsächlich persönlich, sowohl einzeln als auch regelmäßig.



    Aktiv: verwendet eine Weboberfläche und einer der mobilen Clients - iOS oder Android - wechselt häufig zwischen zwei Clients. Erstellt und bearbeitet viele Ereignisse und Aufgaben, lädt häufig Teilnehmer ein oder ist selbst Teilnehmer an Ereignissen.



    Technocrat : Verwendet ein Webinterface und Clients auf beiden mobilen Plattformen. Erstellt viele Ereignisse und Aufgaben. Es verwendet nicht standardmäßige Ansätze für Tools und erstellt eigene Schemata für die Arbeit mit Ereignissen und Aufgaben.



    Betrunkener Meister : eine besondere Art, die in der Natur selten anzutreffen ist und Chaos und Zerstörung anrichten kann. Er verwirrt ständig die Tasten, treibt einen Bewusstseinsstrom in die Formen, drückt zehnmal auf Senden, sendet Spam und versucht auf jede erdenkliche Weise zu brechen, was er erreicht.



    Diese fünf Benutzergruppen überschneiden sich mit Benutzerfällen, aber die Szenarien sind sehr unterschiedlich (die Anzahl der Benutzerfälle und die Reihenfolge, in der sie ausgeführt werden). Beispielsweise ist eine schnelle und stabile Synchronisierung von Daten zwischen Clients für Active und Technocrat von entscheidender Bedeutung und für Mobile nicht besonders wichtig, da nur ein mobiler Client verwendet wird. Basierend auf diesen Überlegungen haben wir Verwendungsszenarien für jedes Zeichen basierend auf vorhandenen Benutzerfällen zusammengestellt.

    Als nächstes haben wir verschiedene Interaktionsszenarien zwischen den Zeichen für die Gruppenarbeit im Kalender zusammengestellt. Ein wichtiger Punkt - alle Szenarien, einschließlich der Gruppenszenarien, wurden an den Vertretern der Gruppen innerhalb des Unternehmens durchgeführt. Daher haben wir sowohl die Richtigkeit der Auswahl unserer Charaktere als auch die Nähe der Szenarien zum wirklichen Leben überprüft. Wir haben bei Kollegen „Korridortests“ durchgeführt, aber aus Gründen der Reinheit des Experiments haben wir auch versucht, Benutzer von Drittanbietern mithilfe von E-Mail und Instant Messenger zu befragen. „Korridortests“ erwiesen sich als effektiver, da bei der Kommunikation mit treuen Benutzern der Korrektureffekt „Hilfe um jeden Preis“ auftrat. Und die Benutzer schwiegen über einige Punkte und passten sich nach ihrem Verständnis dem erwarteten Ergebnis an.

    Der Prozess hat begonnen

    Jetzt sieht der Anwendungstestprozess folgendermaßen aus:
    1. Der Entwickler erstellt einen Build.
    2. Es werden Rauchprüfungen durchgeführt.
    3. Die spezifischen Aufgaben in diesem Build werden überprüft.
    4. Zeichenskripte mit betroffenen Funktionsblöcken werden getestet.
    5. Wenn der Build zu einer Beta werden kann, werden alle Szenarien aller Charaktere in der Reihenfolge ihrer Priorität getestet.

    Zum Beispiel gebe ich eines unserer Testskripte für den Charakter "Aktiv". Das Skript soll innerhalb einer Stunde fertig sein:
    • Ich schaue auf den mobilen Client, um Benachrichtigungen über Ereignisse zu Beginn des Arbeitstages zu erhalten (für einige schaue ich auf die detaillierte Beschreibung).
    • Ich übertrage 1-2 Ereignisse auf eine andere Zeit;
    • Ich füge Teilnehmer zu einer der Veranstaltungen im Webclient hinzu.
    • Ich erstelle 1-2 Ereignisse für den aktuellen Tag und 2-3 Ereignisse für die aktuelle Woche.
    • Ich erstelle im mobilen Client 2-3 Aufgaben für jedes Datum;
    • Ich habe den Status "erledigt" für beliebige Aufgaben aus der aktuellen Liste im Webclient festgelegt.
    • Im Offline-Modus des mobilen Clients zeige ich Ereignisse an, erstelle einige neue Aufgaben, verschiebe eines der Ereignisse, gehe online und überprüfe die Synchronisation (dies wird als Nachahmung von Fahrten im Aufzug bezeichnet).
    • Ich markiere mehrere im Webclient erledigte Aufgaben, übertrage 1-2 Aufgaben an einen anderen Tag, erstelle 2-3 Ereignisse für ein beliebiges Datum und mische ein Ereignis aus dem Kalender "Tag im Verlauf" in ein soziales Netzwerk.

    Um die Details nicht zu langweilen, wird das Skript leicht reduziert und vereinfacht. In Bezug auf die Reihenfolge des Testens verschiedener Charaktere und ihrer Szenarien haben wir dann Prioritäten, da Statistiken zu verschiedenen Benutzergruppen vorliegen - die größte Gruppe wird zuerst getestet. Dies geschieht zunächst, um die beliebtesten Funktionen zu stabilisieren und häufiger Alpha- und Beta-Versionen zu veröffentlichen.

    Löffel Nuancen

    Natürlich sind Charaktere keine Pille für alle Krankheiten. Es gibt Probleme im Zusammenhang mit der Verwendung der Technik und Probleme, die die Charaktere nicht lösen.

    Die wichtigste ist die episodische Redundanz und das Auferlegen von Benutzerfällen für verschiedene Charaktere und in verschiedenen Szenarien. Wir haben damit zu kämpfen und teilen die Benutzerfälle nach den Ausführungsparametern auf. Zum Beispiel erstellen wir Ereignisse separat für die Charaktere und jeder hat seine eigenen Parameter, die so nah wie möglich an der Realität sind und alle möglichen Bedingungen für die Erstellung des Ereignisses abdecken.

    Ein weiteres Problem besteht darin, dass einige Benutzerfälle nicht in Skripten enthalten sein können, da sie im wirklichen Leben entweder sehr selten sind oder einen synthetischen Charakter haben. Wir lassen diese Benutzerfälle getrennt von den Skripten und gehen sie mit vollständigen Tests aller Funktionen durch.

    Gewinn

    Basierend auf den Ergebnissen der Arbeit mit Charakteren und Skripten wurden 3 Updates unserer mobilen Clients veröffentlicht. Es ist unmöglich, auf die Verbesserung der Statistiken zum Auffinden anstößiger Fehler durch die Benutzer selbst zu verweisen, da die veröffentlichten Versionen sehr unterschiedlich sind und es nicht ganz richtig ist, sie miteinander zu vergleichen. Es gibt aber auch andere ebenso wichtige positive Effekte.

    Erstens macht es Testern viel mehr Spaß, mit Charakteren zu arbeiten. Der Testprozess ist vielfältiger geworden, das Verständnis für das Produkt und die Benutzer selbst ist gewachsen. Anstatt nach abstrakten Fehlern zu suchen, die unter realen Bedingungen schwer zu reproduzieren sind, werden Probleme, die für den Endbenutzer kritisch sind, zuerst erkannt.

    Zweitens nehmen Tester nicht nur an Funktions-, sondern auch an Usability-Tests teil. Und jetzt wurde die Anzahl der Meinungen bei der Diskussion von Schnittstellen von aktiven Benutzern des Produkts mit ihren Argumenten und Visionen aufgefüllt.

    Drittens hat sich die Eintrittsschwelle für neue Tester verringert. Kürzlich haben wir ein Experiment durchgeführt und die Position eines Testers übernommen, einer Person ohne Testerfahrung. Abgesehen vom „Kurs für junge Kämpfer“ zu allgemeinen Themen begannen etwa drei Tage später wirksame Tests.

    Wir dürfen nicht vergessen, dass Entwickler auch ihre Anwendungen testen müssen und es Skripte für sie gibt. Nischenprodukte wie unser Kalender sind mit dem Problem der Verwendung durch direkte Teilnehmer konfrontiert. Szenarien und Charaktere fragen hervorragend: "Warum sollte ich das überhaupt verwenden, ich habe kein solches Bedürfnis." In unserem Fall beginnen Entwickler im Laufe der Zeit, das Produkt im Leben zu verwenden, und entfernen sich allmählich von den Szenarien.

    Und die letzten Zeichen werden von uns nicht nur bei Funktionstests verwendet. Dank der geleisteten Arbeit haben wir ein wichtiges und nützliches Werkzeug strukturiert und in Erinnerung gerufen, das wir möglicherweise im Marketing einsetzen können.

    Yuri Vetrov (@jvetrau), Leiter der Mail.Ru Group Interface Design Group:
    Zeichen sind ein leistungsstarkes Werkzeug für Designer und Designer, mit dem Sie sich auf die Szenarien konzentrieren können, die für die tatsächliche Verwendung des Produkts am gefragtesten sind. Es war großartig zu sehen, dass er Anwendung fand, um die Qualität der Implementierung zu testen, und nicht nur in Bezug auf die Benutzerfreundlichkeit.

    Im Idealfall beheben Fehler alles auf einmal. Aber im Leben gibt es immer eine Reihe von Aufgaben, die einen vollständigen und unwiderruflichen Bugfix zurückschieben - neue Funktionen, dringende Hotfixes usw. Daher brauchen wir eine gute Möglichkeit, sowohl bei der Behebung von Fehlern als auch bei der Suche nach Fehlern Prioritäten zu setzen. Schlüsselszenarien für die Verwendung der wichtigsten Benutzerkategorien verwenden - fertig. Dies bedeutet, dass in erster Linie Probleme gefunden und behoben werden, die Benutzer am häufigsten verhindern.

    Zuvor wurden die Zeichen für die Expertenbewertung der Benutzerfreundlichkeit und Benutzertests herangezogen. Ihre Verwendung zur Überprüfung der Qualität der Implementierung ist ein interessanter und ziemlich neuer Ansatz. Ich habe lange Zeit viel über moderne Methoden der Arbeit an Schnittstellen gelesen und noch nie davon gehört. Dies ist also eine großartige Ergänzung für das Sparschwein des Produktteams.

    Jetzt auch beliebt: