Zustandsbasiertes Testen – Automatisierte Tests mit dem „Avenqo StoryTeller“ entwerfen

In diesem Artikel erläutern wir, wie man mit Hilfe der Technik Zustandsbezogenes Testen die Testautomatisierung mobiler Apps strukturiert entwerfen kann – und wie uns dabei der Avenqo StoryTeller unterstützen kann.

In einem früheren Artikel haben wir dir bereits von unserem StoryTeller berichtet. Zur Erinnerung: der StoryTeller ist ein Werkzeug, welches es Fachtestern ermöglicht, Tests für mobile Applikationen zu automatisieren. Dafür sind z.T. keine Programmierkenntnisse notwendig; der verbleibende Aufwand für die Testautomatisierung / Programmierung sinkt um 40 bis zu 70%.

Nun wollen wir anhand eines konkreten Beispiels zeigen, wie man (automatisierte) Tests entwerfen kann.

Die Aufgabe

Schauen wir uns zunächst ein kleines Beispiel an. Angenommen du testest die App eines Onlineshops.
Die Testaufgabe besteht darin, die folgende Login-User-Story zu automatisieren.

User Story „Login“

Als Kunde
möchte ich mich im Shop anmelden,
so dass ich meine bisherigen Bestellungen einsehen oder persönliche App-Einstellungen vornehmen kann.

Akzeptanzkriterium 1
Wenn ich mich erfolgreich anmelde, dann gelange ich auf eine Seite, von der aus ich weitere Aktionen ausführen kann.

Akzeptanzkriterium 2
Wenn ich falsche Anmeldeinformationen eingebe, dann erscheint eine Fehlermeldung.

Werfen wir nun einen Blick auf die App und schauen, wie man das erste vorgegebene Szenario „manuell“ prüfen würde. Dazu unterteilen wir den Testablauf in einzelne Testschritte, die im Folgenden beschrieben werden.

Screens finden

Weil wir mit dem StoryTeller arbeiten, speichern wir uns gleich mal die Screens (Synonym: PageObjects) ab und vergeben sprechende Namen zwecks späterer Wiederverwendung in den automatisierten Tests.

Schritt #1 – Start der App

App: Nach dem Start der App siehst du den abgebildeten Screen.

StoryTeller: Mit dem ScreenSniffer nehmen wir den ersten Screen auf. Dieser bekommt den Namen „Start – nicht angemeldet“.

Anmerkung: Der ScreenSniffer des StoryTellers speichert noch andere Informationen aus der App ab, bspw. die interne Beschreibung des Screens (Page Source), die wir in anderen Situationen nutzen können – dazu in einem späteren Artikel mehr.

Screen #1: „Start – nicht angemeldet“

Schritt #2 – Kontoinformationen abrufen

App: Wir rufen mit einem Klick auf das entsprechende Konto-Symbol der App die Kontoinformationen ab.

StoryTeller: Wie nehmen den zweiten Screen auf. Dieser bekommt den Namen „Konto – nicht angemeldet“.

Screen #2: „Konto – nicht angemeldet“

Schritt #3 – In der App anmelden

App: Ein Klick auf die Schaltfläche „Jetzt anmelden“ navigiert uns zum Anmeldebildschirm.

StoryTeller: Wir nehmen nun den dritten Screen auf, der den Namen „Anmeldung“ bekommt.

Screen #3: „Anmeldung“

Schritt #4 – (Erfolgreich) Einloggen

App: Wir geben nun die richtigen Daten für E-Mail & Passwort ein und klicken auf die Schaltfläche Login. Es öffnet sich ein neuer Screen, der die Kundin persönlich anspricht und von dem aus wir uns weitere personenbezogene Informationen wie bspw. aktuelle Bestellungen etc. anzeigen lassen können.

StoryTeller: Auch den vierten und vorerst letzten Screen nehmen wir mit dem ScreenSniffer auf, und speichern ihn unter dem Namen „Dashboard“ ab.

Screen #4: „Dashboard“

Fassen wir kurz zusammen:

  • Jeder Screen stellt einen Zustand der App dar, der ohne ein äußeres Ereignis sich nie ändert.
  • Zustandsänderungen (der Wechsel von einem zu einem anderen Screen) erfolgen als Resultat äußerer Ereignisse (bspw. die Interaktion des Anwenders mit der App – Eingaben, Klick, Auswahl, etc.).
  • Der StoryTeller hat sich die Screens mittels ScreenSniffer „gemerkt“ und auch die Zustandsübergänge zwischen den Screens (quasi: Navigationsstruktur).

Dieses Systematik nutzen wir nun, um unsere automatisierten Tests zu entwerfen.

Navigationstruktur
Bild: Navigationstruktur der App inkl. zugewiesener Steps


Steps

Um unseren ausführbaren Test zu definieren, müssen wir noch die so genannten Steps (Synonym: Testschritte) den Zustandsübergängen zuweisen.
Die Steps simulieren die Interaktionen des Anwenders mit der App.
Der StoryTeller verwendet hierzu die formalisierte Sprache Gherkin, die Endnutzer-„kompatibel“ ist.
Das heißt: wir verwenden hier die Sprache unserer Kunden und nicht die der Techniker / Entwickler.

Hinweis: Obwohl das Konzept jedem bekannt ist, der BDD (Behavior Driven Development) kennt, so muss man ausdrücklich sagen, dass dies nicht(!) BDD ist, denn entgegen dem von Dan North entwickelten Ansatz schreiben wir die Test NACH dem die App entwickelt wurde.
Des weiteren nehmen wir konkreten Bezug auf die Lösung, sind also nicht lösungsneutral.
Trotzdem lässt sich der Mechanismus sehr gut für unseren Anwendungsfall verwenden, weswegen wir ihn skrupellos für unsere Zwecke missbrauchen – … Sorry & Danke, Dan.

Somit können wir das erste Abnahmekriterium in ein ausführbares Szenario übersetzen:

Szenario: Wenn ich mich erfolgreich anmelde, dann gelange ich auf eine Seite, von der aus ich weitere Aktionen ausführen kann.

Angenommen die App ist gestartet
Und ich befinde mich auf der Seite "Start – nicht angemeldet"
Wenn ich die Kontoinformationen aufrufe
Dann ist die Seite "xx" sichtbar

Wenn ich mich als „Isolde“ anmelde
Dann ist die Seite "Dashboard" sichtbar

 

Die Texte für die Steps sind nicht immer frei gewählt: Es gibt vordefinierte und App-unabhängige Steps, die schon im StoryTeller-Framework existieren.
Diese kann man in den verschiedensten App-Projekten wiederverwenden. Bei neuen Testautomatisierungsprojekten startet man somit bereits mit einem beachtlichen Stand an ausführbaren Testschritten.

Gibt es noch keine passenden Steps, dann kann man den Step und seine Parameter frei definieren und zu dem neuen Step bereits eine vollständige Beschreibung hinterlegen.

Somit weiß der Testautomatisierer, welche Schritte noch zu implementieren sind und welche Funktionalität dabei erwartet wird. Implementierte Testschritte können danach in anderen Testszenarien wiederverwendet werden.

Hinweis: In unserem konkreten Fall sind die Testschritte z.T. App-spezifisch definiert.
Dies kann den Vorteil der besseren Lesbarkeit mit sich bringen. Andererseits besteht die Möglichkeit, die Szenarien auf der Basis bereits existierender, universeller Testschritte zu formulieren, wie sie out-of-the-box durch das StoryTeller-Framework bereitgestellt werden.
In diesem Fall könnte man die Szenarien auch ohne jegliche Programmierkenntnisse umsetzen!

Wir setzen zum Schluss noch das zweite Abnahmekriterium um und legen ein weiteres Szenario an.

Bild: Der gesamte Testfall inkl. zweitem Szenario

 

Somit haben wir den eingangs beschriebenen Use Case in einen vollständigen Test im StoryTeller umgesetzt.

Diese Tests lassen sich nun beliebig erweitern durch Kombination der definierten bzw. bereits bestehenden Steps (ohne Benutzernamen, aber mit Passwort; vice versa; usw.).
Und das, ohne zusätzlichen Programmieraufwand!

Jetzt kennst du ein wichtiges Prinzip, auf dem Avenqo‘s StoryTeller basiert.

Dieses Prinzip lässt sich auf alle Screens der App anwenden.
Die ermittelte Navigationsstruktur der App kann nun genutzt werden, um die Abbildung der Navigationspfade durch Tests zu planen und zu überprüfen (Testabdeckung).

Grundsätzlich ist das dargestellte Vorgehen auch unter Anwendung klassischer Werkzeuge (Papier & Stift) möglich.
Allerdings profitiere ich als Testautomatisierer enorm von den im Storyteller hinterlegten Screens & Steps.
Denn auf dieser Basis lassen sich nun sehr einfach automatisierte Tests schreiben und ausführen. Wie?
Dazu in einem der nächsten Artikel mehr.

GDPR Cookie Consent mit Real Cookie Banner