Eine Mobile-Teststrategie ist die Reihenfolge, in der Sie entscheiden, was getestet wird, und nicht die Liste der Geräte, auf denen Sie es testen. Die meisten Teams erstellen zuerst die Liste: eine Tabelle mit iPhones, Samsung-Geräten und Betriebssystemversionen. Diese Tabelle ist ein Ergebnis. Die Strategie besteht aus den vier Entscheidungen, die sie hervorbringen, und eine falsche Reihenfolge ist der Grund, warum Teams am Ende eine breite Geräteabdeckung für die falschen Risiken haben.
Was ist eine Teststrategie für mobile Apps?
Sie ist die Entscheidungsstruktur, die festlegt, was getestet wird, in welcher Reihenfolge und wer die Freigabe erteilt, bevor überhaupt jemand ein Gerätelabor öffnet. Das ist etwas anderes als eine Checkliste zum Testen mobiler Apps, die beantwortet, „was prüfen wir in diesem Build“. Eine Strategie beantwortet zuerst eine schwierigere Frage: Welche Fehler würden uns tatsächlich Geld kosten, und wer fängt jeden davon ab, bevor er ausgeliefert wird?
Die meisten veröffentlichten Leitfäden zu diesem Thema beginnen mit „Wählen Sie Ihre Geräte aus“ und behandeln die Matrix als die Strategie selbst. Das ist verkehrt herum. Eine zuerst erstellte Gerätematrix spiegelt meist die Marktanteile in den App-Stores wider statt des tatsächlichen Risikos Ihrer App. Am Ende sind Sie bei den Geräten gründlich und genau bei dem Fehler dünn aufgestellt, der Sie den Launch gekostet hätte.
Entscheidung 1: Welche Fehler Sie tatsächlich Geld kosten würden
Ordnen Sie vor allem anderen die Fehlerklassen, die für genau diese App relevant sind:
- Absturz beim Start oder bei der ersten Nutzung. Verhindert die Aktivierung, bevor sich ein Nutzer eine Meinung über das Produkt bilden kann.
- Fehlgeschlagene Zahlung. Direkter Umsatzverlust, dazu die Support- und Erstattungskosten, die darauf folgen.
- Datenverlust oder Datenbeschädigung. Zerstört sofort das Vertrauen, vor allem bei allem, was nutzergenerierte Inhalte oder den Kontostatus verarbeitet.
- Ablehnung im Store. Apple und Google lehnen Apps aus Gründen ab, die nichts mit Bugs zu tun haben (Metadaten, Formulierung von Berechtigungen, Privacy Manifests), und eine Ablehnung zum falschen Zeitpunkt kann Sie einen Launch-Termin komplett kosten.
Ordnen Sie diese Klassen für Ihre App, und behandeln Sie sie nicht als gleich wahrscheinlich oder gleich teuer. Für eine Abo-App zählt eine fehlgeschlagene Zahlung am meisten. Für eine Social-App der Datenverlust. Bei einem ersten Release vor einem Publikum, das Sie noch nicht kennt, zählt die Ablehnung im Store am meisten, weil es noch kein Wohlwollen gibt, das eine Verzögerung auffangen könnte. Diese Rangfolge ist der erste Abschnitt des eigentlichen Strategiedokuments, und genau diesen überspringen die meisten Teams, weil er sich wie ein Business-Gespräch anfühlt und nicht wie ein QA-Gespräch. Er ist beides.
Entscheidung 2: Welche Ebene jede Fehlerklasse am günstigsten abfängt
Sobald Sie wissen, was teuer ist, legen Sie fest, wo jede Fehlerklasse abgefangen wird, bevor sie einen Nutzer erreicht. Derselbe Bug kostet unterschiedlich viel, je nachdem, wo er gefunden wird:
Absturz beim Start
Automatisierter Smoke-Test bei jedem Build
Läuft in Minuten und verhindert, dass der Build überhaupt auf ein Gerät gelangt
Fehlgeschlagene Zahlung
Manuelles exploratives Testen mit echten Zahlungswegen
Sandbox-Umgebungen bilden reale Kartenablehnungen und Wiederholungsversuche nicht ab
Datenverlust
Integrationstests gegen das echte Backend
Unit-Tests mocken die Datenbank; der Bug steckt in der Übergabe
Ablehnung im Store
Manuelle Richtlinienprüfung vor der Einreichung
Keine automatisierte Ebene liest die aktuellen Richtlinien von Apple oder Google für Sie
Das ist eine Platzierungsentscheidung, keine Automatisierungsentscheidung. Sie zeigt Ihnen, ob ein Risiko früher hingehört (schnell, automatisiert, günstig) oder später (langsamer, manuell, aber die einzige Ebene, die es tatsächlich sieht). Wie sich diese Ebenen über den Zeitplan eines Releases verteilen, lesen Sie in unserem Beitrag über die Phasen des Softwaretestens. Der Aufbau der Automatisierung selbst ist eine eigene Entscheidung mit eigenen Vor- und Nachteilen und verdient ein eigenes Gespräch, sobald diese Platzierung steht.
Entscheidung 3: Wer bei einem Grenzfall-Build entscheidet
Jedes Release hat mindestens einen Build, bei dem nicht eindeutig ist, ob er ausgeliefert werden soll oder nicht. Ein kleiner Absturz auf einer alten Betriebssystemversion. Ein Zahlungs-Sonderfall, der nur bei einem bestimmten Kartentyp auftritt. Jemand muss für diese Entscheidung verantwortlich sein, bevor sie ansteht, und nicht erst in der Hektik am Release-Tag.
Benennen Sie die Rolle, nicht eine Person: in der Regel die technische Leitung für das technische Risiko, den PM für das geschäftliche Risiko und einen vereinbarten Eskalationsweg für den Fall, dass beide uneins sind. Halten Sie es schriftlich fest. Die Teams, die sich die Finger verbrennen, sind nicht die mit schlechtem Urteilsvermögen, sondern die, bei denen die Grenzfall-Entscheidung von dem getroffen wird, der gerade im Raum ist, unter Zeitdruck und ohne vorherige Einigung darüber, was „akzeptables Risiko“ für diese App bedeutet. Hier zählt auch die Rolle eines QA-Partners: Die Entscheidung fällt schneller, wenn QA als ein Team mit Engineering und Produkt arbeitet statt als Dienstleister, der eine Bug-Liste übergibt und wartet.
Entscheidung 4: Jetzt können Sie die Gerätematrix aufbauen
Sind die ersten drei Entscheidungen getroffen, wird die Gerätematrix zu einer einfachen Übung: Welche Geräte und Betriebssystemversionen bilden die Risiken, die Sie in Entscheidung 1 geordnet haben, tatsächlich ab, getestet auf der Ebene, die Sie in Entscheidung 2 zugewiesen haben? Ein Risiko fehlgeschlagener Zahlungen bedeutet, auf den Betriebssystemversionen und Geräten zu testen, auf denen sich Ihr tatsächliches Zahlungs-SDK anders verhält, und nicht auf den zehn Smartphones mit dem größten Marktanteil. Ein Risiko der Ablehnung im Store bedeutet, gegen die Betriebssystemversionen zu testen, für die Apple und Google aktuell ihre Richtlinien durchsetzen, und das ändert sich jedes Jahr.
Hier bleibt die Matrix auch bewusst klein. Eine aus dem Risiko abgeleitete Matrix umfasst weniger Geräte als eine, die auf Marktanteilen beruht, und genau darum geht es. Jedes Gerät, das ohne ein Risiko dahinter hinzukommt, ist Abdeckung, für die Sie bezahlen, ohne sie zu nutzen.
Das Gerüst für das Teststrategie-Dokument
Ein Teststrategie-Dokument für mobile Anwendungen muss nicht lang sein. Acht Abschnitte mit je einer Zeile Orientierung reichen, damit ein PM es noch am selben Nachmittag ausfüllen kann:
- Geordnete Fehlerklassen – die Reihenfolge nach Kosten aus Entscheidung 1, spezifisch für diese App.
- Zuordnung der Ebenen – welche Klasse auf welcher Ebene abgefangen wird, aus Entscheidung 2.
- Verantwortlich für Grenzfall-Builds – die Rolle und der Eskalationsweg, aus Entscheidung 3.
- Geräte- und Betriebssystem-Matrix – das Ergebnis von Entscheidung 4, rückgebunden an die geordneten Risiken.
- Kriterien für die Release-Freigabe – was erfüllt sein muss, damit ein Build ausgeliefert wird, in verständlicher Sprache.
- Regressionsumfang pro Release – was jedes Mal erneut geprüft wird und was nur bei größeren Änderungen.
- Bekannte Ausschlüsse – was diese Strategie bewusst nicht abdeckt, und warum.
- Überprüfungsrhythmus – wann dieses Dokument erneut geprüft wird (ein neuer Zahlungsanbieter, ein neues Betriebssystem-Release, ein gescheiterter Launch).
Wann Sie diese Reihenfolge anpassen sollten
Diese Abfolge von vier Entscheidungen setzt eine App mit echten Nutzern voraus, bei der echtes Geld auf dem Spiel steht. Für ein internes Tool oder einen Wegwerf-Prototyp ist sie überdimensioniert; dort lautet die ehrliche Antwort „den Happy Path testen und ausliefern“. Sie setzt außerdem voraus, dass jemand bereit ist, das Kostengespräch aus Entscheidung 1 zu führen, wofür Produkt und Engineering im selben Raum sitzen müssen. Kann dieses Gespräch nicht stattfinden, fällt die Strategie wieder auf eine Geräteliste zurück, denn eine Geräteliste ist das, was übrig bleibt, wenn niemand ordnen will, was wirklich zählt.
Wie QAwerk das gemeinsam mit Ihnen aufbaut
QAwerk hat über 300 QA-Projekte abgeschlossen, und ein wiederkehrendes Muster dabei ist, dass Teams, die direkt zur Gerätematrix springen, ihr Testbudget für das falsche Risiko ausgeben. BeFamily kam mit einer brandneuen App zu QAwerk: Das Team schrieb die Testpläne, erstellte über 500 Testszenarien und testete neue Builds auf 9 Geräten. Seit dem Launch hatte BeFamily keine Abstürze oder größeren Probleme in der Produktion, und die Zahl der aktiven Nutzer hat sich innerhalb einer Woche verdreifacht.
Das ist der Unterschied zwischen einem QA-Dienstleister, der eine Checkliste abarbeitet, und einem Team, das die Entscheidungen 1 und 3 mit Ihnen durchgeht, bevor auch nur ein Testfall geschrieben wird. Wenn Sie das Testen mobiler Anwendungen zum ersten Mal aufsetzen oder einen Prozess übernehmen, der nicht abfängt, worauf es ankommt, sollte das Gespräch genau dort beginnen und nicht bei den Smartphones.
Was ist eine Teststrategie für mobile Apps?
Sie ist die Entscheidungsreihenfolge hinter einem Testvorhaben: welche Fehler nach Kosten am wichtigsten sind, welche Testebene jeden davon am günstigsten abfängt, wer bei einem Grenzfall-Build die Freigabe erteilt und erst dann, welche Geräte und Betriebssystemversionen getestet werden. Sie ist weder die Geräteliste selbst noch die Checkliste dessen, was bei jeder Funktion zu prüfen ist.
Was sollte ein Teststrategie-Dokument für mobile Apps enthalten?
Acht Abschnitte decken es ab: geordnete Fehlerklassen, die Zuordnung der Ebenen je Fehlerklasse, die Verantwortlichen für Grenzfall-Builds samt Eskalationsweg, die Geräte- und Betriebssystem-Matrix, Kriterien für die Release-Freigabe, der Regressionsumfang pro Release, bekannte Ausschlüsse und ein Überprüfungsrhythmus.
Wie plant man eine Mobile-Teststrategie?
Beginnen Sie mit den Kosten, nicht mit den Geräten. Ordnen Sie, welche Fehler (Absturz beim Start, fehlgeschlagene Zahlung, Datenverlust, Ablehnung im Store) für Ihre konkrete App am teuersten wären. Ordnen Sie dann jeden der günstigsten Ebene zu, die ihn abfängt, legen Sie fest, wer bei einem Grenzfall über die Auslieferung entscheidet, und bauen Sie erst dann die Gerätematrix um diese geordneten Risiken herum auf.
Ist eine Gerätematrix dasselbe wie eine Teststrategie?
Nein. Eine Gerätematrix ist ein Ergebnis einer Strategie, und zwar das letzte. Teams, die die Matrix zuerst erstellen, landen bei einer breiten Abdeckung von Geräten, die ihr tatsächliches Risiko nicht widerspiegeln, weil die Matrix auf Marktanteilen statt auf den geordneten Fehlerkosten beruht.
Wer sollte für eine Mobile-Teststrategie verantwortlich sein, QA oder das Produktteam?
Keiner allein. Die Rangfolge der Fehlerkosten ist eine Produkt- und Geschäftsentscheidung; die Zuordnung der Ebenen ist eine Entscheidung von QA und Engineering. Die Strategie funktioniert, wenn ein Dokument beides enthält, mit einer benannten verantwortlichen Rolle für die Momente, in denen beide Seiten uneins sind.
Sehen Sie selbst, wie wir BeFamily dabei geholfen haben, eine App auf den Markt zu bringen, die vom ersten Tag an ein durchschlagender Erfolg war!
