Testautomatisierung von Mobile Apps

Testautomatisierung für mobile Apps gelingt, wenn sie zwei klare Ziele verfolgt: nicht-technische Tester können Testfälle selbst schreiben, und die Gerätevielfalt wird systematisch abgedeckt. Ein keyword-getriebener Ansatz mit Robot Framework ermöglicht beides. Entscheidend ist außerdem, die Infrastruktur stabil aufzubauen, bevor Quantität zählt.

Das Wichtigste in Kürze

• Eine Testautomatisierung, die mehr Aufwände erzeugt als sie abnimmt und der man nicht vertrauen kann, ist besser komplett einzustellen als weiterzubetreiben.
• Vor dem zweiten Anlauf haben Felix Doppel und sein Team einen Anforderungskatalog mit gewichteten Kriterien erstellt und einen Proof of Concept mit 30 Testfällen gefordert, bevor sie einen Dienstleister beauftragten.
• Keyword-driven Testing mit Robot Framework erlaubt es manuellen Testern bei HUK Coburg, Testfälle selbst zu schreiben und auszuführen, ohne Entwicklungskenntnisse zu haben.
• Gerätevielfalt auf Android lässt sich nicht durch mehr Tester lösen, sondern nur durch eine physische Mobile Device Cloud mit priorisierten Gerätepaketen, die auf realen Nutzerdaten basieren.
• Isolierte Testautomatisierungsteams scheitern, weil fachliches Wissen der manuellen Tester und technisches Wissen der Automatisierer nur gemeinsam funktionierende Testfälle ergeben.

Warum die erste Testautomatisierung gescheitert ist

Eine Testautomatisierung, die mehr Aufwand erzeugt als sie spart, hat ihren Zweck verfehlt. Genau das passierte beim Test der mobilen Telematik-App der HUK-Coburg. Das Team startete kurz nach dem Entwicklungsbeginn 2018 mit der Automatisierung, ohne sich vorher Gedanken über Werkzeug, Ansatz und Ziele zu machen.

Die Folge waren grüne Testläufe, denen niemand traute. Während die Automatisierung komplett durchlief, fand der manuelle Regressionstest 20 bis 25 kritische Fehler. Die Tests prüften also etwas, aber nicht das, worauf es ankam.

Damit fielen beide Versprechen der Automatisierung weg. Sie sollte die manuelle QA entlasten und für Sicherheit sorgen. Stattdessen band sie zusätzliche Kapazitäten und lieferte kein verlässliches Signal. Felix Doppel, Tester bei der HUK-Coburg, ordnet einen Teil davon dem Reifegrad zu: Das Team habe zu früh angefangen, bevor es seine Rollen und Aufgaben gefunden hatte.

Den Stecker ziehen ist manchmal der ehrlichere Schritt

Eine gescheiterte Automatisierung weiterlaufen zu lassen, nur weil schon viel Geld darin steckt, ist ein teurer Reflex. Das Team entschied sich anders und stellte die Automatisierung Mitte 2022 komplett ein. Vier Jahre Arbeit wurden bewusst beendet.

Der Auslöser war eine nüchterne Kosten-Nutzen-Rechnung. In einem agilen Projekt zählt nicht, eine Automatisierung “auf der Fahne” zu haben, sondern dass sie etwas bringt. Da die manuellen Tester stark waren, war das Team ohne die Automatisierung schlicht besser dran.

Leicht war das nicht. Vom Management kam erwartbar die Frage nach dem bereits investierten Geld. Die Diskussionen waren hart, und es tat weh, einzugestehen, dass die Investition zu diesem Zeitpunkt nichts gebracht hatte.

Auf den harten Cut folgte eine bewusste Pause von rund vier bis fünf Monaten ohne jede Automatisierungsaktivität. Diese Zeit nutzte das Team, um das Scheitern aufzuarbeiten, statt sofort den nächsten Versuch zu starten.

Erst Ziele, dann Werkzeug: der zweite Anlauf

Der zweite Anlauf begann nicht mit einem Tool, sondern mit einem Anforderungskatalog. Das widerspricht dem agilen Reflex des schnellen Ausprobierens, war bei dem Umfang und den Kosten einer Automatisierung aber notwendig. Genau diese Vorarbeit hatte beim ersten Versuch gefehlt.

In internen Workshops befragte das Team die verschiedenen Rollen direkt: Was braucht ein Product Manager, was ein Testmanager, was die manuellen Tester, was die Entwicklung? Daraus entstanden teils konkurrierende Ziele, die aufgelöst und neu definiert werden mussten. In einem Workshop ließ das Team mehrere Gruppen sogar auf der grünen Wiese Pseudo-Lösungen entwerfen.

Am Ende standen zwei klare Ziele. Erstens sollte ein nicht-technischer Anwender Testfälle selbst spezifizieren und ausführen können, damit die manuelle QA aktiv mitarbeitet. Zweitens sollte die Gerätevielfalt steigen, um die Qualität abzusichern.

Die Zielmarke beim Automatisierungsgrad lag bewusst niedrig. Statt möglichst viel anzustreben, peilte das Team 60 bis 70 Prozent an, dafür aber stabil und auf rund zehn verschiedenen Geräten.

Warum die Gerätevielfalt bei einer Versicherungs-App zum Risiko wird

Bei der Telematik-App hängt an jedem Funktionsfehler ein Versicherungsprodukt, und das macht die Gerätevielfalt zum echten Risiko. Die App zeichnet über einen Sensor das Fahrverhalten auf und wertet Geschwindigkeit, Beschleunigung sowie Brems- und Lenkverhalten aus. Wer sicher fährt, spart Beitrag.

Funktioniert die Fahrtaufzeichnung nicht, melden sich die Nutzer sofort. Geht die Aufzeichnung etwa drei Wochen lang nicht, eskaliert das über Kunden und Support bis zu den Abteilungsleitern.

iOS lässt sich noch gut abdecken: jährlich ein neues Modell, wenige Displaygrößen, meist das aktuelle Betriebssystem. Auf Android sieht es anders aus. Hier existiert eine dreistellige Zahl an Kombinationen aus Geräten, Typen und Betriebssystemversionen. Diese Menge bekommst du manuell nicht abgetestet, egal wie gut deine Tester sind.

Warum keyword-driven besser passte als behavior-driven

Welcher Automatisierungsansatz passt, entscheidet sich am Team, nicht am Lehrbuch. Der erste Versuch nutzte Cucumber mit Gherkin-Syntax, also einen behavior-driven Ansatz. Der zweite setzt auf Robot Framework und einen keyword-driven Ansatz.

Vorab wusste das Team nicht, dass der keyword-getriebene Weg für seine Leute praktikabler sein würde. Diese Erkenntnis ließ sich nur durch Ausprobieren gewinnen.

Ein verbreiteter Fehler dabei: Behavior-driven Development wird oft begeistert eingeführt und dann werden alle Akzeptanzkriterien in Gherkin gepresst, ohne zu fragen, wer das im Team überhaupt schreiben kann. Nicht jede Aufgabe lässt sich sinnvoll so formulieren.

Robot Framework hatte für dieses Umfeld einen praktischen Vorteil. Android und iOS teilen sich denselben Testfluss, unterschieden wird nur auf unterster Ebene. Über die Business-Keywords bleibt darüber alles gleich, und Testfälle lassen sich in natürlicher Sprache und testdatengetrieben formulieren, ohne dass jemand Methoden programmieren muss.

So lief der Proof of Concept ab

Ein Werkzeug bewährt sich nicht auf dem Papier, sondern an den eigenen Testfällen. Statt sich wie beim ersten Mal an die Technologie anzupassen, drehte das Team die Reihenfolge um und forderte zuerst echte Testfälle.

Die externe Ausschreibung hatte zwei Bedingungen: Der Anforderungskatalog musste eingehalten werden, und es musste einen Proof of Concept mit mindestens drei eingereichten Testfällen geben. Erst nach Sichtung dieser Testfälle gab das Team grünes Licht.

Den Zuschlag erhielt der Dienstleister imbus. Christoph Singer, Berater bei imbus, beschreibt die Ausgangslage als ungewöhnlich weit fortgeschritten, weil Anforderungskatalog und Testfälle bereits einen hohen Reifegrad hatten. Häufig muss dieser Schritt erst beim Kunden nachgeholt werden, statt das nächstbeste Werkzeug aus der Google-Suche zu nehmen.

Zum Jahresende 2022 folgte als Belastungsprobe ein größeres Paket: rund 30 Testfälle innerhalb von etwa zwei Monaten. Damit ließ sich prüfen, ob der Ansatz nicht nur an drei Beispielen, sondern auch in der Masse trägt.

Qualität entsteht im Team, nicht im isolierten Automatisierungsteam

Ein isoliertes Automatisierungsteam, dem man Testfälle nur zuwirft, ist aus Sicht der HUK-Coburg einer der Hauptgründe für das erste Scheitern. Wenn Automatisierer abgekapselt arbeiten und fertige Testfälle nur “über den Zaun” bekommen, fehlt die fachliche Rückkopplung.

Der Hebel liegt im Zusammenspiel der Stärken. Ein Automatisierer ist technisch stark, kennt die Fachlichkeit aber oft nicht tief genug. Ein manueller Tester versteht den Testfall, weil er ihn hundertmal ausgeführt hat, hat aber nicht das technische Werkzeug. Diese beiden Seiten zusammenzubringen, ist der eigentliche Erfolgsfaktor.

Du musst das komplette Team mitnehmen. Wenn du das isolierst, fühlen sich die Testautomatisierer isoliert und sie unterstützen sich nicht gegenseitig. — Felix Doppel

Für die manuellen Tester bedeutete der keyword-driven Ansatz keinen großen Bruch, weil ihre Testfälle ohnehin schon in diese Richtung strukturiert waren. In einem gemeinsamen Workshop entstanden die ersten eigenen Testfälle, und mit den vorhandenen Keywords bildete sich schnell ein Gespür dafür, was bereits da war und was noch fehlte. Fehlt ein Keyword, spielen die Tester den technischen Ball zurück an imbus.

Wichtig war der enge Austausch von Anfang an. Zwischenstände wurden regelmäßig präsentiert und auf Verständlichkeit geprüft, statt am Ende ein fertiges Ergebnis hinzustellen.

Wie weit die Automatisierung heute ist

Aktuell ist rund ein Drittel des Regressionstests automatisiert, teils voll, teils nur teilweise. Der Regressionstest umfasst etwa 150 Testfälle. Die angepeilten 60 bis 70 Prozent hält das Team bis Jahresende für erreichbar.

Bewusst zählt dabei nicht die reine Stückzahl. 80 automatisierte, aber instabile (flaky) Testfälle wären eine schöne Zahl fürs Management und trotzdem wertlos. Stabilität schlägt Quantität.

Voll automatisieren heißt, dass der manuelle Testfall komplett entfallen kann. Vieles lässt sich aber nur teilautomatisieren. Manche Features bleiben außen vor: Die Fahrtaufzeichnung selbst oder das Pairing des Telematik-Sensors lassen sich nicht sinnvoll automatisiert prüfen.

Neben den Testfällen entstand die Infrastruktur drumherum: Schnittstellentests und die Anbindung an eine Mobile Device Cloud. Auch die Wartung ist ein dauerhafter Posten. Die 30 Testfälle vom Jahresende 2022 mussten bereits im Frühjahr 2023 erneut gewartet werden.

Echte Geräte statt Simulator, gesteuert über drei Pakete

Die Automatisierung läuft auf physischen Geräten in einer Mobile Device Cloud, nicht im Simulator. Der Simulator macht vieles einfacher, aber Seiteneffekte und verlässliche Ergebnisse zeigen sich erst auf echten Geräten.

Die Geräteauswahl ist in drei Pakete priorisiert:

Die Auswahl folgt echten Nutzungsdaten, nicht dem Zufall. Das Team monitort im Hintergrund, auf welchen Geräten die Nutzer unterwegs sind, und schaut sich das monatlich an. Daran orientiert sich, welche Geräte in welchem Paket landen.

Sicherheitsvorgaben einer Versicherung greifen auch hier ein. Testgeräte werden automatisch aktualisiert, deshalb existieren etwa für Android 7 keine physischen Testgeräte mehr. Unterstützt werden die App ab Android 7 und ab iOS 14, und ältere Stände lassen sich gezielt über die Cloud abdecken.

Ein praktischer Vorteil der Mobile Device Cloud ist das Reporting. Zu jedem fehlgeschlagenen Testfall gibt es eine Videoaufzeichnung, mit der sich nachvollziehen lässt, an welcher Stelle es schiefging. Bei der rein technischen Lösung zuvor blieb stattdessen ein Stack Trace, der wieder bei den Entwicklern landete.

Langsam einführen, statt früh wieder Vertrauen zu verspielen

Die automatisierten Tests sind noch nicht vollständig in den Regressionstest integriert. Sie laufen in Jenkins eingebunden, derzeit nächtlich, aber noch nicht automatisch bei jedem neuen Build. Das ist eine bewusste Entscheidung.

Würde das Team die rund 50 bis 60 automatisierten Testfälle sofort scharf schalten, müsste es sie aus dem manuellen Test herausnehmen. Diesen Schritt geht es erst, wenn die Infrastruktur rundherum komplett passt, also die Anbindung an Jenkins und Jira steht.

Der Grund ist die Erfahrung aus dem ersten Versuch. Sind die Testfälle nicht stabil genug, dreht die Stimmung im Team schnell wieder. Deshalb soll die Automatisierung erst dann in den scharfen Einsatz, wenn das Drumherum verlässlich ist.

Auch die Ausführungsfrequenz braucht Augenmaß. Bei jeder Änderung mitlaufen zu lassen, treibt die Wartung in die Höhe. Sinnvolle Zeitpunkte und Releases mit passendem Schwerpunkt sind wichtiger als ständiges Durchlaufen.

Wirkung zeigt die Automatisierung schon jetzt. Die regelmäßigen Läufe haben bereits zwei bis drei kritische Fehler gefunden, die sonst erst im Regressionstest aufgefallen wären. Fehler früher zu finden, ist auch hier wieder eine Frage des Geldes.