Hybrides App-Testing kombiniert automatisierte und manuelle Tests, um Lücken zu schließen, die keiner der beiden Ansätze allein abdeckt. Automatisierung prüft systematisch viele Geräte und Inhalte, manuelles und exploratives Testen erkennt visuelle Fehler, Usability-Probleme und gerätespezifische Sonderfälle. Ein Automatisierungsanteil von rund 70 bis 80 Prozent ersetzt dabei nicht den manuellen Teil, sondern ergänzt ihn.
Das Wichtigste in Kürze
- Wer Testautomatisierung ohne manuellen Anteil betreibt, verliert genau die Fehler, die nur dem menschlichen Auge auffallen: visuelle Überlappungen, Usability-Probleme und gerätespezifische Randphänomene.
- Ein Geräte-Setup von 15 bis 20 Geräten in der Automatisierung deckt nicht alle relevanten OS-Varianten ab, weil Hersteller wie Samsung eigene Schichten über Android legen und so tausende Sonderfälle entstehen.
- Rund 90 Prozent der fehlgeschlagenen automatisierten Testfälle sind tatsächliche Bugs in der Software, nicht Fehler in der Automatisierung selbst.
- Automatisierung bricht schneller als geplant, weil ein iOS-Update das verwendete Tool außer Betrieb setzen kann. Der manuelle Test fängt genau diese Lücke ab.
- Testautomatisierung verottet, wenn Teams unter Deadline-Druck die Pflege zurückstellen: Fehlt nach einem Sprint ein Drittel der Tests und niemand repariert sie, verliert die Suite ihren Wert.
Warum sich Apps nicht vollständig automatisiert testen lassen
Vollständige Testautomatisierung scheitert bei mobilen Apps an der Gerätevielfalt. Beim ZDF müssen Apps auf einer großen Bandbreite an Geräten laufen, darunter auch alte Modelle, damit die Inhalte für alle zugänglich bleiben. Genau diese Bandbreite macht reine Automatisierung teuer und fehleranfällig.
Anika Strake beschreibt das Kernproblem so: Unterschiedliche Betriebssysteme, verschiedene Android-Versionen und herstellerspezifische Oberflächen wie bei Samsung erzeugen tausende Sonderfälle. Wer all das automatisiert abdecken will, baut sich einen Wartungsaufwand auf, der schnell außer Verhältnis steht.
Die Konsequenz ist eine Abwägung statt eines Maximalprinzips. Du musst entscheiden, was automatisiert wird, auf wie vielen Geräten und welche Lücke übrig bleibt. Dieser Rest lässt sich nicht wegautomatisieren, er lässt sich nur anders schließen.
Wie eine Ausschreibung für reine Automatisierung zu einem hybriden Ansatz wurde
Der ursprüngliche Auftrag lautete: alles automatisieren. In der Ausschreibung des ZDF stand, dass ausschließlich automatisiertes Testing angeboten werden sollte. Qualitätssicherung war zuvor stiefmütterlich behandelt worden, und Automatisierung galt als das logische nächste Level.
Appmatics gewann die Ausschreibung und wählte trotzdem einen anderen Weg. Der Grund war praktischer Natur: Die gelieferte Software eignete sich schlecht für Automatisierung. Tags und IDs, die das automatisierte Ansteuern von Elementen erleichtern, waren teils nicht gesetzt. Bei einer App, die laufend weiterentwickelt wird, treibt das den Wartungsaufwand zusätzlich hoch.
Die Kick-off-Phase zog sich dadurch in die Länge. Der Kunde wollte aber regelmäßige Tests und regelmäßige Ergebnisse. Also begann das Team manuell und ließ die Automatisierung später dazukommen. Aus dieser Notlösung wurde das tragende Prinzip.
Manuelles und automatisiertes Testing ergänzen sich, sie konkurrieren nicht
Die Stärke liegt in der Kombination beider Ansätze. Automatisierung kommt in viele kleine Ecken einer App, manuelles Testing fängt das ab, was Maschinen schlecht beurteilen können.
Automatisierte Tests klicken zum Beispiel jede Sendungsseite der Mediathek durch und prüfen, ob Inhalte vorhanden sind und Links funktionieren. Manuell wäre das extrem langwierig. Umgekehrt erkennt ein Mensch Usability-Probleme, überlappende Elemente oder verdeckte Buttons sehr viel schneller, und findet beim explorativen Testen Fehler, die kein Skript vorgesehen hätte.
Das Grundsetup umfasst 15 bis 20 Geräte in der Testautomatisierung. Für manuelle Tests kommen weitere Geräte dazu. Tritt ein Fehler nur bei einer bestimmten OS-Version auf, ist die Eingrenzung manuell oft schneller, als sämtliche automatisierten Tests zu durchforsten.
Wie du entscheidest, ob ein Testfall automatisiert wird
Ausschlaggebend sind Kritikalität und Häufigkeit. Key Features und Happy Paths gehören in die Automatisierung, weil sie auf keinen Fall kaputtgehen dürfen.
Ein zweites Signal liefert das manuelle Testen selbst. Wenn ein Test sich müßig und repetitiv anfühlt, ist das ein erster Indikator für Automatisierung. Genau deshalb lohnt es sich, manuell zu starten: Du bekommst ein Gefühl für die App und für die Stellen, an denen regelmäßig Probleme auftauchen.
Häufige Fehler in einem bestimmten Bereich sind das dritte Kriterium. Tauchen ähnliche Probleme immer wieder auf, auch außerhalb der absoluten Hauptfeatures, wandert dieser Fall in die Automatisierung.
Benedikt Broich beschreibt den typischen Ablauf konkret: In der ersten Woche fällt ein kritischer Fehler explorativ auf. In der zweiten Woche wird er manuell nachgetestet, ein Testfall existiert bereits. Ist dieser Test aufwendig oder tritt der Fehler erneut auf, zieht das Team die Automatisierung als doppelten Boden ein.
Automatisierung bricht, und das System muss damit umgehen können
Mobile Automatisierung läuft nicht stabil von allein. An ihr hängen viele Tools und Anbieter, die zusammenspielen müssen. Ein iOS-Update kann reichen, damit das Automatisierungstool mit der neuen Version nicht mehr funktioniert.
Solche Ausfälle fängt der manuelle Teil ab. Lässt sich eine iOS-Version gerade nicht automatisiert testen, wird sie eben manuell mitgenommen. Der hybride Aufbau ist damit kein Luxus, sondern eine Versicherung gegen die Sprödigkeit der Werkzeuge.
Der Setup-Aufwand ist hoch, der laufende Wartungsaufwand bleibt überschaubar. Anfallende Fehler auf der Automatisierungsseite lassen sich meist innerhalb eines Tages fixen. Von den fehlgeschlagenen Testfällen sind etwa 90 Prozent echte Bugs in der Software und rund 10 Prozent Probleme der Automatisierung selbst.
Gefundene Ergebnisse werden manuell verifiziert, nicht blind gemeldet
Automatisierte Ergebnisse landen im eigenen Tool und durchlaufen eine menschliche Prüfung. Ein Testanalyst schaut über die Ergebnisse und nimmt eine erste Einschätzung vor: Steckt der Fehler in der Automatisierung oder in der App?
Anschließend wird der Fehler manuell nachgestellt und eingegrenzt. Tritt er nur unter iOS oder nur unter Android auf? Hängt er an bestimmten OS-Versionen? Ist es ein visueller Fehler, der mit der Bildschirmgröße oder mit Tablets zusammenhängt?
Diese Verifikation ist gerade bei einer Mediathek wichtig. Skaliert der Vollbildmodus nicht richtig oder wird Inhalt falsch angezeigt, sind das Fehlerklassen, die Automatisierung allein schwer findet.
Gewonnene Kapazität fließt zurück ins manuelle Testen, nicht in Einsparung
Der Automatisierungsanteil liegt bei rund 70 bis 80 Prozent der Fälle. Trotzdem fahren die manuellen Tests nicht herunter.
Was an Kapazität frei wird, weil die Automatisierung aufgeschlossen hat, geht zurück ins manuelle Testen: granularere Testfälle, mehr exploratives Testen, mehr Geräte. Der Anteil der Automatisierung steigt also dadurch, dass neue Fälle dazukommen, nicht dadurch, dass manuelle Tests gestrichen werden.
Das unterscheidet diesen Ansatz vom üblichen Ressourcen-Hin-und-Her. Nur ganz am Anfang werden manuelle Tests durch automatisierte ersetzt. Ab einem gewissen Punkt bleibt das manuelle Testing als feste Unterstützung erhalten.
Wie du mit Testdaten umgehst, die sich ständig ändern
Bei dynamischen Inhalten wie einer Mediathek hilft Generalisierung statt fester Testdaten. Die Sendungen wechseln laufend, Inhalte laufen ab, neue Folgen kommen hinzu.
Die Automatisierung löst das über einen Data Provider. Das Skript scannt die App, ermittelt die vorhandenen Sendungen und führt auf jeder denselben Test aus, bis keine neue Sendung mehr auftaucht. So lässt sich ein einziger Test über alle Sendungen ausrollen.
Diese Generalisierung hat eine bewusste Grenze. Ob ein Titel sprachlich korrekt ist oder einen Rechtschreibfehler enthält, prüft die Automatisierung nicht, weil der Aufwand die Kosten sprengt. Solche inhaltlichen Bewertungen übernimmt das manuelle Testen, das ohnehin Teil des Setups ist.
Warum Automatisierung am Deadline-Druck zerbricht
Der häufigste Fehler ist, Testautomatisierung dem Entwicklungsteam nebenbei aufzubürden. Die Erwartung lautet dann: Die Entwickler schreiben ihre automatisierten Tests, und alles passt sich von selbst. In der Realität passiert das Gegenteil.
Kommt die nächste Deadline, wird das Testing hinten angestellt. Plötzlich fehlt ein Drittel der Tests, im nächsten Sprint ist keine Zeit, sie zu reparieren. Weil Automatisierung wartungsintensiv ist, gerade bei paralleler Weiterentwicklung mehrerer Teams und zusammengeführten Release-Kandidaten, gehen Tests zwangsläufig kaputt.
Die Gegenmaßnahme ist, ein festes Kontingent zu blocken, ob eine ganze Stelle, eine halbe oder ein Anteil des Sprints. Nur so bleibt die Qualitätssicherung flexibel und funktional zugleich.
Am Ende ist niemandem geholfen, wenn das Feature zur Deadline fertig ist, aber kaputt.
Benedikt Broich
Fehler verteilen sich über alle Ebenen
Keine einzelne Testebene findet die meisten Fehler. Die größten Probleme verteilen sich über manuelle, automatisierte und explorative Tests.
Ein kaputter Player, bei dem der Vollbildmodus nicht mehr funktioniert, fällt eher manuell auf. Nicht geladene Inhalte findet die Automatisierung an genau den Stellen, an denen sie passieren. Abgefahrene Fehler auf seltenen Randgeräten zeigen sich oft nur, wenn man explorativ einem Problem nachgeht.
Genau diese Verteilung ist die Bestätigung für den hybriden Ansatz. Erst die Kombination der drei Ebenen sorgt dafür, dass so viele Fehler überhaupt gefunden werden.
