Qualitätssicherungstests perfektioniert – Ein User-Flow-Tutorial

Da Produkte und Dienstleistungen immer schneller bereitgestellt werden, muss sich die Qualitätssicherung (QA) an die sich entwickelnde Umgebung anpassen und manchmal den gleichen Abdeckungsgrad in kürzerer Zeit erreichen. Wie vermeiden wir den Fehler Quantität über Qualität ? Wie decken wir mehr ab, steigern die Effizienz und sind dennoch effektiv in unserer Arbeit?

Wir alle wissen, dass die Erstellung von Testfällen viel Zeit in Anspruch nimmt. Wir müssen verschiedene Techniken und Testtypen anwenden und Vorbedingungen, Schritte und erwartete Ergebnisse dokumentieren. Zusätzlich müssen wir einen Testplan erstellen.

Qualitätssicherungsspezialisten haben oft keine Zeit mehr, besonders wenn sie versuchen, alle Phasen des QA-Prozesses zu absolvieren. Das größte Problem bereitet die Testplanungs- und Designphase, die sich um die Erstellung von Testfällen und die Testdokumentation dreht. Es kann Stunden, manchmal sogar Tage dauern, bis die ganze Arbeit erledigt ist, und normalerweise entscheiden sie sich dafür, bestimmte Ergebnisse zu überspringen und stattdessen zusammenzufassen, wobei sie wichtige Informationen auslassen, die dazu führen können, dass ein Test vergessen wird. Dadurch geht auch der Nutzen des Wissensaustauschs verloren.

Traditionelle QA-Tests treffen auf Benutzerfluss

Ich bin ein großer Fan von traditionellen Testfällen und Testplänen. Sie helfen nicht nur dabei, unzählige Testfälle zu identifizieren, sondern dokumentieren das Produkt auch sehr gut. Sie können sie im Training verwenden, und jede Person im Team versteht sie. Sie müssen sich nicht übermäßig auf Erfahrung verlassen, damit jemand mit dem Testen beginnt. Testpläne enthalten weitere Informationen wie den Umfang, die Testelemente, die Funktionen, die Sie testen, und diejenigen, die Sie nicht testen. Es gibt auch eine Risikoanalyse, die in den Testplan einfließt. Dies sind nur einige der Vorteile, jedoch ist die Gesamtdauer in vielen Fällen zu lang.

Der Zweck eines Testplans ist eine Möglichkeit der Kommunikation und Vereinbarung zwischen den Projektbeteiligten. Es hilft dabei, die Ziele, erforderlichen Ressourcen und jeden Ansatz oder jede Strategie zum Testen des Produkts zu beschreiben. Der Plan trägt dazu bei, dass an alles gedacht wird, und gibt den Beteiligten die Gewissheit, dass der Qualitätssicherungsprozess strategisch angelegt ist. Es gibt keine konkrete Regel, dass dieser Plan 10 Seiten lang sein muss. Wir können es neu definieren, damit es zu einem schnelllebigen Team passt.

Die Alternative besteht darin, die traditionellen Testfälle und den Testplan so zu rationalisieren, dass der erforderliche Zeitaufwand reduziert wird, aber die gleiche, wenn nicht mehr, Abdeckung und Dokumentation geliefert wird, die für alle Beteiligten sinnvoll ist. Dies beinhaltet eine einzige Quelle der Wahrheit, einen Benutzerfluss mit einer Wendung. Indem Sie einen Benutzerfluss strukturieren und pflegen, haben Sie den Großteil Ihres Testfalldesigns bereits für Sie erledigt. Dies kann auf jedes Produkt oder Team angewendet werden und ist in Bezug auf Details und Struktur vielseitig.

Die Verwendung der Flow-Methode hilft Ihnen dabei, eine schnellere Bearbeitungszeit für Ihre Testdokumentation zu erreichen. Dies gilt nicht nur für die manuelle QA, sondern auch für die Automatisierung. Der Ablauf kann auch zu einigen Abschnitten des Testplans beitragen.

Mit dem "Flow" gehen

Lassen Sie uns ohne weitere Verzögerung direkt in den Aufbau eines Benutzerflusses für eine einfache Messaging-Website eintauchen.

Wir benötigen zunächst ein kostenloses Mind-Mapping-Tool. Ich persönlich benutze XMind. Fühlen Sie sich frei, jedes Tool herunterzuladen, mit dem Sie vertraut sind – wir werden nur grundlegende Funktionen verwenden, wie z. B. das Zeichnen eines Flussdiagramms, das Hinzufügen von „Notizen“ zu einigen Themen, das Einfärben verschiedener Bedingungen und das Verwenden von Beschriftungen.

Unser erster Schritt ist, das Produkt zu verstehen. Normalerweise referenzieren Sie Mock-up-Bilder oder Wireframes. Wenn keines davon verfügbar ist, wird ein kurzes Nachholgespräch mit einem Entwickler genau die Bildschirme liefern, die zu erwarten sind. Fühlen Sie sich frei, uns zu folgen und zu üben, während wir fortfahren. Der Flow ist nicht nur auf eine Benutzeroberfläche beschränkt und kann auch verwendet werden, um API-zu-API-Aufrufe, Datenbankdiagramme, Abhängigkeitsstrukturen und mehr abzubilden. Es gelten die gleichen Prinzipien.

Bedingungen, Zustände, Aktionen

Wir schränken unseren Fluss ein, indem wir nur drei Akteure verwenden. Sie haben eine Bedingung , die wie ein Benutzer mit einer bestimmten Rolle, ein geleerter Cache oder ein Benutzer ist, der sich zum ersten Mal anmeldet. Zweitens haben wir eine State/Page , die eine eigentliche GUI-Komponente ist, wie eine Homepage oder ein Anmeldefenster. Als nächstes kommt die Aktion , bei der es sich um eine physische Benutzerinteraktion handelt, die bewirkt, dass sich der Status ändert. Lassen Sie uns dies in Aktion sehen.

Analyse der Anforderungen

Dies ist unsere Homepage, die der Staat ist. Wir haben zwei mögliche Aktionen: Registrieren und Anmelden.

Dann haben wir das Anmeldefenster, einen anderen Zustand. Die Aktionen hier sind Zurück und Anmelden. Beachten Sie, dass wir die Eingabefelder nicht als Aktionen klassifizieren. Sie können dies gerne tun. Nach meiner Erfahrung habe ich festgestellt, dass es bei der Arbeit an komplexen Systemen, die ein paar Zehntel tief sind, etwas schwierig zu warten ist, aber für einfache Anwendungen kann es eine gute Lösung sein.

Schließlich kommen wir zum Dashboard, auf dem der Benutzer landet, wenn er sich erfolgreich angemeldet hat. Hier haben wir drei Aktionen – wir können eine Nachricht erstellen, bearbeiten oder löschen.

Wir haben jetzt genügend Informationen, um mit dem Benutzerfluss zu beginnen. Lassen Sie uns zusammenfassen, was wir haben. Wir notieren die Zustände des Produkts. Soweit wir sehen können, gibt es vier Seiten:

1. Startseite
2. Anmeldefenster
3. Fenster registrieren
4. Armaturenbrett

Wir schreiben unsere Aktionen auf jeder Seite/jedem Zustand auf, mit dem „interagiert“ werden kann:

1. Startseite
   1. Anmeldung
   2. Registrieren
2. Anmeldefenster
   1. Anmelden
   2. Stornieren
3. Fenster registrieren
   1. TBD (je nach Produkt)
4. Armaturenbrett
   1. Schaffen
   2. Bearbeiten
   3. Löschen

Wir beginnen mit dem Produktnamen , der geändert werden kann, um ihn an Ihre Umgebung anzupassen, aber dies passt zu den meisten Teams und ihren Produkten und bietet auch einen guten Ausgangspunkt. Unten sehen wir ein Fragezeichen neben Registrieren .

Häufig werden Sie in Agile auf eine Komponente stoßen, die noch nicht im Umfang enthalten oder für eine zukünftige Version geplant ist. Beachten Sie seine Existenz, aber lassen Sie es als unbekannt, bis wir weitere Informationen erhalten.

Zeichnen des Flussdiagramms

Wir zeichnen das Obige in XMind so, dass es so aussieht:

Sie werden feststellen, dass ich einfach farblich kodiere, was ein Zustand und was eine Aktion ist. Ich habe auch eine Zeile von der Cancel-Aktion zur Startseite hinzugefügt, um diesen Fluss genau darzustellen. Wir sehen auch zwei Bedingungen, wenn ein Benutzer „Anmelden“ auswählt. Obwohl beide zum Dashboard gehen, wollen wir dennoch beide möglichen Bedingungen testen.

Das Schöne an XMind ist, dass wir, wenn wir an einer großen, komplexen Anwendung arbeiten, verschiedene Ebenen des Diagramms erstellen können. Wenn Sie also den Fluss in mehrere Flüsse aufteilen, diese aber verknüpft halten möchten, ist dies mit der Verknüpfung sehr einfach die Themen auf separaten Blättern. Sie können einen Hyperlink einfügen und aus dem Popup-Fenster des Assistenten einen „Zustand“ auswählen, zu dem die Aktion führt. Das bedeutet, wenn Sie in XMind „Anmelden“ auswählen und es einen Hyperlink zu „Dashboard“ enthält, springt Ihr Mauszeiger zu „Dashboard“, auch wenn es sich auf einem anderen Blatt befindet. Ziemlich cool.

Was unserem Flow fehlt, sind Labels. Wir geben dem Produkt ein Etikett von 0, da dies die Wurzel des Flusses ist. Dann fügen wir für jeden Zustand (blau) ein S#-Label hinzu, für jede Aktion (grün) fügen wir ein A#-Label hinzu und schließlich fügen wir für jede Bedingung (Cyan) ein C#-Label hinzu. Jedes Label muss einzigartig sein. Wir enden mit dem Folgenden:

Um nachzuverfolgen, welche Nummer Sie zuletzt verwendet haben – denn wenn das Produkt wächst, kann es schwierig sein, die höchste Nummer zu finden –, speichere ich dies im Root-Thema des Flows, wie unten:

Wir kommen nun zum Teil der Erstellung von Testfällen. Wir werden uns auf die erwarteten Ergebnisse konzentrieren, die wahrscheinlich die wichtigsten Informationen in einem Testfall und Teil der Akzeptanzkriterien des Features sind. Ich werde jedem Abschnitt oder Test einen Titel hinzufügen und dann die erwarteten Ergebnisse darunter auflisten. Ich werde dies nur für eine Teilmenge tun, um diesen Artikel kurz zu halten:

Dann das Anmeldefenster:

Dann die Anmeldeaktion:

Es nimmt wirklich Gestalt an. Beachten Sie die hinzugefügten Begrenzungs- und Sicherheitstests. Sie können dies nach Belieben benennen, je nachdem, was für Sie am einfachsten zu taggen ist. Manchmal tagge ich den Titel mit einem Testtyp, z. B. Sicherheit – JS-Injektion – E-Mail-Feld, und liste dann die erwarteten Ergebnisse unten auf.

In den meisten Teams finden wir es mühsam, sich ändernde Anforderungen zu pflegen. Nicht mehr. Nehmen wir an, wir haben gerade erfahren, dass allen Erstbenutzern das Ts- und Cs-Fenster angezeigt werden muss und sie akzeptieren müssen, bevor sie zu ihrem Dashboard weitergehen – kein Problem. Wir können den Status und die Aktionen relativ einfach hinzufügen, wie unten:

Wir sehen jetzt die Auswirkungen des Hinzufügens eines neuen Zustands. Beachten Sie, dass die Nummerierung zunächst seltsam erscheinen mag, aber soweit wir uns erinnern, dienen die Nummern nur dazu, jeden Akteur eindeutig zu identifizieren – ähnlich wie ein Primärschlüssel in einer Datenbank. Vergessen Sie nicht, Ihre „Zuletzt verwendet“-Notizen zu aktualisieren, um den Überblick über die von Ihnen verwendeten Nummern zu behalten.

Erstellen der Testfälle aus dem Flow

Nach all diesen Fortschritten kommen wir nun zum einfacheren Teil: der Erstellung von Testfällen. Lassen Sie mich einige wichtige Punkte hervorheben. Wir haben Etiketten für jeden Schauspieler, wir haben Titel für jeden Test und wir haben erwartete Ergebnisse für jeden Test, wobei die Bedingungen als Teil unseres Ablaufs eingebettet sind. Das klingt wie das Rezept für einen Testfall, finden Sie nicht?

Alles, was wir jetzt tun, ist, den Inhalt unseres Flows in ein beliebiges Testfall-Management-Tool, eine Confluence-Site oder ein beliebiges Excel-Dokument zu kopieren und einzufügen. Ich benutze immer noch das gute alte vertrauenswürdige Excel. Ich halte alle meine Testfälle in einer Datei namens „Baseline“ fest – sehr originell. Sobald ich mit dem Kopieren und Einfügen fertig bin, habe ich am Ende Folgendes:

Fügen Sie nach Bedarf Spalten für Testtypen, Teststatus und Testkonfigurationen hinzu. Die Bedingungen können besser vor der Aktion „Anmelden“ platziert werden, aber es gibt keinen richtigen oder falschen Weg, es hängt von Ihren persönlichen Vorlieben ab und davon, wie Sie sich organisieren.

Es gibt ein paar Dinge hervorzuheben. Einer davon ist, dass ich Zellen zusammengeführt habe, die dieselben Informationen teilen – kein wiederholtes Kopieren und Einfügen erforderlich, es verschwendet Zeit und ist schwieriger zu warten. Ein weiterer Punkt sind die Schritte. Sie werden feststellen, dass zwei der Tests Schritte haben, die die Status- und Aktionsnummern enthalten. Dies kann verwendet werden, wenn Sie den Flow als Teil des SDLC in Ihrem Team haben. Alle Beteiligten tragen dann zum Fluss bei, indem sie Informationen, Modelle, Risiken usw. bereitstellen. Das bedeutet, dass jeder im Team durch Angabe der Flusszahlen weiß, was zu tun ist, und wenn es ein neues Teammitglied gibt, ist es genauso einfach als „Folge der Spur, verweise auf die Notizen.“

Dies hilft auch der Automatisierung. Sie können jedem Schritt oder jeder Aktion eine eindeutige Referenz geben. Indem Sie ein Automatisierungspaket erstellen, das wie Ihr Flow strukturiert ist, werden Sie feststellen, dass das Automatisierungsframework, das Sie erstellen können, das Potenzial hat, äußerst robust, modular und mit der gesamten App kompatibel zu sein. Es wird Paging-Objekte in größerem Umfang verwenden, was die Wartungszeit verkürzt und es Ihnen ermöglicht, Testfunktionen gegen neue auszutauschen.

Der Flow kann die einzige Quelle der Wahrheit für die gesamte Produktdokumentation sein, einschließlich technischer Spezifikationen, funktionaler Spezifikationen, Testfälle, Statusübergänge, Datenflüsse usw.

Der optimierte Testplanansatz

Was ist also mit Testplänen?, müssen Sie denken. Das ist einfach. Ein Testplan enthält Abschnitte wie:

1. Einführung & Geltungsbereich
2. Testgegenstände
3. Zu testende Funktionen
4. Funktionen nicht zu testen
5. Annahmen
6. Aufnahmekriterien
7. Abbruchkriterium
8. PSP
9. Risiken
10. Umgebungsanforderungen

Die Einführung und der Umfang sind die JIRA-Story oder eine beliebige Aufgabe oder Story in einem anderen Tool. Die Testelemente sind einfach die aktuell in Ihrer Umgebung bereitgestellten Softwareversionen oder Commit-Nummern, die Sie mit dem JIRA-Ticket oder Ihrem Testlauf entweder auf Confluence oder dem Testmanagement-Tool verknüpfen können.

Zu testende Features und nicht zu testende Features sind eigentlich Ihre Testfälle. Die ausgewählten Testfälle, die für diese JIRA-Story ausgeführt werden sollen, sind „zu testende Funktionen“, und alles, was nicht aufgeführt ist, ist „nicht zu testende Funktionen“. Listen Sie ganz einfach die Zustände und Aktionen auf, die Sie auf dem Story-Ticket testen werden.

Annahmen, Risiken und sogar Umgebungsanforderungen können in einem Dokument zusammengestellt oder zu den Kommentaren in JIRA hinzugefügt werden, manchmal sogar in Confluence platziert und mit der Story verknüpft werden.

Ein PSP ist eine Schätzung, die Sie der Story je nach Projekt in Form von Story Points oder Stunden zuweisen. Einstiegs- und Ausstiegskriterien werden bereits Teil der Geschichte sein.

Wenn Sie „traditionellen“ Testplänen nahe kommen möchten, können Sie den Entwickler oder andere Interessengruppen bitten, die Geschichte mit Ja oder Nein zu kommentieren, um zu sehen, ob sie mit dem QA-Plan einverstanden sind oder nicht. Dies dient technisch als Ihre digitale Signatur. All dies kann ganz einfach in Ihren QA-Prozess integriert werden und hilft Ihnen, Ihre QA-Dokumentation zu rationalisieren.

Was haben wir gelernt?

Der Benutzerfluss mit dem oben genannten Ansatz und Testplänen, die auf die Verwendung heute verfügbarer Tools optimiert sind, wird uns dabei helfen, sich wiederholende Arbeiten zu reduzieren und die QA dabei zu unterstützen, eine schnellere Bearbeitungszeit ohne Qualitätseinbußen zu erreichen.

Dieser Ansatz hat mir dabei geholfen, organisiert zu bleiben, alle Grundlagen abzudecken und eine Dokumentation zu erstellen, die das gesamte Team versteht. In Agile wird sich das wirklich als nützlich erweisen, und das Beste daran ist, dass wir immer noch an einem der agilen Ansätze festhalten: „Dokumentation vereinfachen“.

Ich hoffe wirklich, dass die Informationen hilfreich waren. Es liegt ganz bei Ihnen als Leser. Dies ist kein konkreter Satz von Regeln, die befolgt werden müssen, dies sind nur Richtlinien, die Ihnen Ideen geben sollen, wie Sie wachsen und Ihre Effizienz verbessern können. Keine Technik passt zu jedem Projekt, Team oder Produkt, aber sie kann den Weg für eine andere innovative Idee ebnen.