18 Erweiterungen (Apps) auf dem Atlassian Marketplace, acht Confluence-Versionen, diverse Datenbank-Systeme und 30 Din-A4-Seiten mit Akzeptanztests - es gibt viel zu tun. Warum lohnt es sich unter anderem deshalb, UI-Test einzusetzen? Wie haben wir automatisierte UI-Tests in unsere Infrastruktur eingebunden? Wo stehen die Hürden und wie nimmt man sie am besten? In diesem Blog-Post gebe ich Antworten auf diese Fragen.
Das Problem
Als App-Hersteller für Confluence mit 18 aktiven Apps auf dem Atlassian Marketplace standen wir bei jedem Release vor einer großen Herausforderung. Wir mussten von Hand prüfen, ob wir noch mit allen unterstützten Confluence-Verisonen kompatibel sind. Aktuell (Stand Januar 2018) gibt es acht Confluence-Versionen mit offiziellem Atlassian-Support.
Wir müssen also sicherstellen, dass unsere Apps mit all diesen Versionen reibungslos funktionieren. Während der Entwicklung beschränken wir uns meist auf die aktuellste Version, aber bei einem Release werden alle Versionen überprüft. Neben den Confluence-Versionen machen auch verschiedene Datenbanksysteme teilweise Probleme und müssen daher auch separat getestet werden.
Will man den Qualitätsanspruch höchstmöglich halten, ist es notwendig, alle Akzeptanztests auszuführen. In einer App können das leicht bis zu 30 Din-A4-Seiten sein! Den Aufwand, um diese Tests manuell umzusetzen, kann man sich leicht vorstellen - vor allem wenn man sie pro Confluence-Version und Datenbanksystem durchführen muss!
Die Folgen
Nun gab es zwei Möglichkeiten: Entweder man ist eine Woche mit Testen beschäftigt und Kunden warten länger auf ein Update oder man testet doch nicht alle Kombinationen und geht das Risiko von Fehlern ein. Die zweite Option haben wir häufiger gewählt - glücklicherweise meist ohne größere Probleme. Dennoch veröffentlicht man natürlich mit Unbehagen, wenn man weiß, dass nicht bestmöglich getestet wurde.
Dieses ungute Gefühl überträgt sich auch auf die Entwicklung selbst, denn mit jedem neuen Feature wächst die Komplexität und damit das Potenzial für Fehler. Die Folge ist eine Verlangsamung der Entwicklung und im Zweifel werden notwendige Umbauten in der App nicht durchgeführt aus Angst, neue Fehler in alten Code einzubauen.
Die Vision
Akzeptanztests laufen automatisiert - und zwar so, als ob ein Nutzer vor dem Bildschirm sitzt und klickt. Für jede Kombination von Confluence-Version und Datenbanksystem soll es eine saubere Testumgebung geben. Die Tests sollen sowohl lokal als auch in einer Continuous-Integration-Umgebung (Bamboo oder Jenkins) ausführbar sein.
Mit der Lösung zur Vision soll ein direkter Mehrwert nicht nur für Entwickler, sondern auch für alle Tester (z.B. POs oder Designer) geschaffen werden. Im besten Fall lassen sich Bug-Meldungen möglichst nahe am Kundensystem in einer sauberen, isolierten Umgebung testen.
Drei Aufgaben gilt es also zu lösen: konfigurierbare Testumgebung und automatisierte Akzeptanztests, die zusammen in einer CI-Umgebung funktionieren.
Die Lösung ...
Für das Problem der verschiedenen Confluence-Versionen und Datenbanksysteme haben wir eine Lösung mit Docker implementiert. Dort lassen sich Confluence, Datenbank und Nutzerverzeichnis beliebig kombinieren. Durch eine Verwaltung in Git und einfache Skripte ist es nun auch Nicht-Entwicklern möglich, ein Confluence-System lokal zu starten, um beispielsweise Bugs nachzustellen oder fachliche Tests durchzuführen.
Auf die Docker-Lösung aufbauend, wurde mit Protractor ein Framework eingesetzt, um UI-Tests (End-to-End-Testing) automatisiert auszuführen. Die Tests öffnen einen Browser und klicken sich wie ein echter Nutzer über die Oberfläche. Dabei werden z.B. für den Nutzer nicht sichtbare Elemente auch von Protractor nicht erkannt. Die Tests selbst sind im Stile des JavaScript-Test-Frameworks Jasmine geschrieben, das vielen JavaScript-Entwicklern bereits bekannt ist. Die Tests selbst können wir "unsichtbar" ausführen oder aber den Browser bei der Arbeit beobachten. Auf jeden Fall wird für jeden Testfall ein Screenshot erstellt, der eine nachträgliche Analyse der Tests ermöglicht.
Wir setzen seit längerem Bamboo als Build-Server und für Continuous Integration ein. Der Einbau von Docker und Protractor hat etwas Geschick erfordert, lief dann aber irgendwann (lesen Sie hierzu mehr in einem folgenden Artikel). Für jede App gibt es nun einen Build-Plan, der die UI-Tests zumindest ein Mal für jede unterstütze Confluence-Version und jedes Datenbanksystem ausführt. Die Tests können neben den stabilen Versionen auch gegen die Release-Kandidaten und Beta-Versionen von Confluence gestartet werden, um Kompatibilitätsprobleme möglichst noch vor einer Veröffentlichung zu erkennen. Mit der Einführung von Configuration as Code in Bamboo hat sich der Aufwand für die Pflege neuer Confluence-Versionen noch einmal verringert.
... aller Probleme?
Trotz der beschriebenen Verbesserungen im Zusammenhang mit dem Einsatz von UI-Tests sind nicht alle Probleme gelöst bzw. sind neue Herausforderungen entstanden. Teilweise verhält sich Protractor eben nicht hundertprozentig wie ein echter Nutzer. Viele Aktion werden unrealistisch schnell ausgeführt, sodass asynchrone Aufrufe in Confluence teilweise nicht rechtzeitig fertig sind und Tests deshalb fehlschlagen. Weiterhin ist der Einstieg in die Entwicklung von UI-Tests - gerade in einer komplexen "Web-Umgebung" wie Confluence - nicht ganz trivial.
Um diesen Problemen zu begegnen, haben wir die "Confluence Protracor Base" entwickelt. Sie kapselt allgemeine Confluence-Features wie das Einloggen, das Einfügen von Inhalten und das Erstellen/Löschen von Benutzern, Bereichen und Seiten. Außerdem gibt es Funktionen, um auf asynchrone Elemente und Aufrufe zu warten. Seit Juli 2017 ist sie auch als Open-Source-Tool auf Github zu finden (confluence-protractor-base).
So weit, so gut: Aber auch mit der beschriebenen Automatisierung können wir nicht komplett auf manuelles Testen verzichten. Man kann nur das testen, was man schon kennt; unbekannte Bugs findet man so nicht. Darum durchlaufen alle unsere Apps weiterhin manuelle Tests und werden vor einem Release mindestens zwei Tage lang auf unserem internen Produktivsystem getestet (Dogfooding).
Wie geht es weiter?
Derzeit arbeiten wir daran, unsere UI-Test-Suite auf allen Ebenen weiter zu stabiliseren und zu automatisieren - sei es die Konfiguration der Docker-Container und des Bamboo-Systems oder die Zuverlässigkeit der UI-Tests an sich. Auch die Ausführung auf geklonten Produktivinstanzen steht auf der Agenda. Zusätzlich geht es darum, die Laufzeit der Tests zu verkürzen, denn die Ausführung dauert je nach Anzahl der Tests über eine Stunde, was häufigeren Tests entgegensteht.
Weiterhin soll die Confluence Protractor Base noch nutzerfreundlicher werden, um die Einstiegshürde weiter zu senken. Wir freuen uns auch auf externes Feedback und haben daher ein kleines Tutorial für den Einsatz der Confluence Protractor Base vorbereitet.
Weiterführende Infos
Software-Tests: Notwendigkeit und Arten des Testens
Code-Coverage-Metriken mit Bamboo und Clover
Integrationstests: Strategien und Herausforderungen
Unit-Tests in der Software-Entwicklung
Mehr über die Creative-Commons-Lizenz erfahren
