INSIGHTS Bereitstellung eines dauerhaft funktionierenden Shops — automatisierte Oberflächentests bei ABOUT…

Bereitstellung eines dauerhaft funktionierenden Shops — automatisierte Oberflächentests bei ABOUT YOU

Der Entwickler lehnt sich zurück. Die Unittests sind erfolgreich durchgelaufen. Das Release kann online gehen. Nicht ganz. Nach dem ein Software Release auf Staging ausgerollt ist, werden nicht nur die neuen Features, sondern auch die wichtigsten Funktionen des Shops auf ihre Eigenschaften überprüft.

Diese Qualitätssicherung beginnt mit einem Smoketest. Dieser prüft innerhalb weniger Sekunden die wichtigsten Pages der Anwendung, um eine frühe Aussage über die Lauffähigkeit des Releases zu bekommen. Dadurch kann zeitnah entscheiden werden, ob weitere, umfangreichere Tests an dieser Stelle überhaupt sinnvoll sind.

ABOUT YOU deployt alle zwei Wochen ein Sprint-Release mit neuen Features und Bugfixes auf live. Wir unterliegen dabei einem strikten Zeitplan. Es ist daher sinnvoll, wiederkehrende Tests zu automatisierten. Im Webumfeld haben wir zudem die besondere Herausforderung, die Funktionalitäten auf verschiedenen Kombinationen aus Browser, Bildschirmauflösungen, Geräten und Betriebssystem, sicherzustellen. Und zu guter Letzt müssen die Tests dokumentiert werden, damit nachvollziehbar ist, welche Funktion durch das jeweilige Testszenario sichergestellt wird.

Wie genau sieht das jetzt aus?
Bei ABOUT YOU verwenden wir den Selenium Webdriver als Basis für ein selbst entwickeltes Framework, dass auf unsere Anforderungen zugeschnitten ist. Dadurch ist es möglich, dem Projekt die nötige Performance zu geben, um mit der schnellen Entwicklung bei ABOUT YOU Schritt zu halten und gleichzeitig eine hohe Testqualität zu liefern.

Wir haben eine klare Testtyptrennung zwischen Functional- und System-Tests definiert. Functionaltests liefern uns schnelle und aussagekräftige Testergebnisse über einzelne Funktionen der Pages. Sie sind die Basis unserer automatisierten Tests und geben zudem eine Auskunft über unsere aktuelle Testabdeckung.

Systemtests sind dagegen stärker von Businesslogik geprägt und unterliegen in ihrer Gesamtheit einer höheren Komplexität und Ausführungsdauer.

Eine wichtige technische Grundlage in unserem Framework ist dabei die abstract Testbase class, welche für alle Testklassen verwendet wird. Diese gewährleistet ein sauberes Test Setup sowie TearDown. Wir verwenden sowohl in der Testbase als auch in allen Testklassen standardisierte Annotationen von TestNG. Der TearDown Schritt stellt durch einzelne Methoden sicher, dass die Testumgebung auf jeden Fall in den Ursprungszustand zurückgesetzt wird. Dies unterstützt aussagekräftige Testergebnisse deutlich. Jeder der bereits im Bereich Testautomatisierung gearbeitet hat, weiß wie aufwändig die Fehlersuche sein kann, wenn der Testfall nicht oder nur sporadisch reproduzierbar ist.

Best Practise gefällig?
Unser Framework folgt einem für uns entworfenem Page Pattern:
Selektoren -> Methoden -> Page.

Die einzelnen Pageklasse können nach Bedarf weitere Fragments implementieren. Fragments folgen ebenfalls dem Page Pattern, stellen logisch aber keine Page dar und kommen auf mehr als nur einer Page vor. Ein Beispiel dafür ist das QuickviewFragment. Durch dieses Pattern erhalten wir eine eine hohe Flexibilität in der Gestaltung und Erweiterung einzelner Pages, so dass wir den Wartungsaufwand gering halten können.

Page-class: CategoryPage.java

Methods-class: Methods.java

Selector-class: Selectors.java

Fancy Stuff?
Schauen wir uns das Konzept nun konkret in einem Functional- und System-Test an.
Zunächst sehen wir die verwendete TestNG Annotation @Test, die den Testfall als Test für die automatische Ausführung kennzeichnet. Der Methodenname soll bereits so definiert sein, dass dieser eine Einschätzung gibt, was dieser Test prüft.

In diesem Test wird die Artikel Detail Page aufgerufen und der Hash des Bildpfads gespeichert. Anschließend wird das nächste Bild angeklickt. Die beiden Pfade werden als String mit einander verglichen und auf Ungleichheit geprüft.

Functional-Test:

In diesem Systemtest wird die Artikel Detail Page aufgerufen und Größe und Länge ausgewählt. Anschließend speichern wir alle Produktinformationen in einem dafür entworfenen Produkt-Objekt. Anschließend rufen wir die Basket Page auf und überprüfen die Produktdaten auf Gleichheit.

System-Test:

Durch die beiden Tests wird deutlich, dass Testfälle bei uns recht simpel von oben nach unten gelesen werden können, um ein Verständnis dafür zu bekommen, was in diesem Testfall konkret passiert. Wir haben an uns selbst die Anforderung gestellt, unseren Testcode so zu konzipieren, dass dieser gleichzeitig unsere Testfalldokumentation darstellt.

Wir versuchen, damit unsere Prozesse möglichst schlank und unsere Performance möglichst hoch zu halten.

Wo ist nun das MultiCross-Browser Testing?
Anstelle selbst aufgesetzter virtueller Slaves nutzen wir einen Servicedienstleister, welcher uns einen oder mehrere Container mit verschiedenen Kombinationen aus Browserversion und Betriebssystem bereitstellen kann. Statt auf Maintenance können wir uns ganz auf unser Framework und das Testen konzentrieren.

Fast jeder Browser benötigt an einigen Stellen ein spezielles Browser- bzw Warteverhalten. Wir haben dies im Core bzw. in den Methoden der jeweiligen Page implementiert, so dass der geschriebene Testfällecode davon komplett losgelöst ist. Das bedeutet vor allem, dass man sich beim Schreiben von Tests auf’s Wesentliche konzentrieren kann und sich keine weiteren Gedanken über browserspezifisches Verhalten machen muss. Ein Beispiel dafür ist die Methode ay.categoryPage.hoverProduct(pos) in Screenshot 3.

Schauen wir uns den zweiten Test nun auch einmal konkret an!

Basket Test from Projekt Collins on Vimeo.

Funktioniert dies zufriedenstellend?
Durch die beschriebene Technologie ist es uns möglich, unsere Tests mit verhältnismäßig geringem Aufwand auf ein Release durchzuführen. Wir können der Entwicklung dadurch schnelles Feedback geben, damit Fehlerbehebungen schnell angegangen werden können und Fehler behoben werden, bevor sie im Livesystem erscheinen. Durch Eingrenzung der Testfälle auf bestimmte Komponenten oder auf nur die wichtigsten kritischen Business Cases können Nachtests beliebig oft wiederholt werden und kurzfristige Änderungen, die schnell veröffentlicht werden müssen, angemessen getestet werden.

Ausblick: Den Smoketest am Anfang der entsprechenden Qualitätssicherung werden wir in einem follow-up Posting genauer beleuchten.