Google Play Closed Testing: Was wir beim Bau von Kleos Music gelernt haben

Vor einem Monat begannen wir, Kleos Music mit einer ziemlich einfachen Idee zu entwickeln: Ein lokaler Musikplayer sollte sich nicht wie eine zweitklassige Version einer Streaming-App anfühlen.

Wir wollten, dass die Musik, die bereits auf deinem Smartphone liegt, vollständig wirkt. Songtexte, Cover, Metadaten, Widgets, Benachrichtigungen und Suche, ohne Abonnements, unnötige Funktionen oder eine Internetverbindung, nur um die eigene Musik abzuspielen.

Dann kam der weniger glamouröse Teil: das Closed Testing bei Google Play.

Bevor eine Android-App in die Produktion gehen kann, verlangt Google Play einen geschlossenen Test mit mindestens 12 Testern, die für den erforderlichen Zeitraum angemeldet bleiben. Auf dem Papier klingt das einfach. In der Praxis ist es nur der Anfang, 12 Personen zu finden.

Für Kleos Music fanden wir die meisten Tester über Tester-for-Tester-Communities, kurz T4T, in denen Entwickler gegenseitig ihre Apps testen, sowie über r/AndroidClosedTesting auf Reddit. Das war eine praktische Möglichkeit, die ersten Menschen außerhalb unserer eigenen Geräte mit der App arbeiten zu lassen.

Aber zwischen 12 Testern und einem echten Test liegt ein großer Unterschied.

Ein Tester kann sich anmelden und die App nie wieder öffnen. Ein anderer nutzt sie einmal und verschwindet. Jemand findet vielleicht einen Fehler und meldet ihn nie. Deshalb ist es riskant, sich genau auf die Mindestzahl an Testern zu verlassen. Menschen hören auf teilzunehmen, vergessen den Test oder werden einfach inaktiv. Ein gewisser Puffer über dem Minimum gibt dem Test mehr Spielraum.

Noch wichtiger ist, dass echtes Testing die Art verändert, wie man sein eigenes Produkt betrachtet.

Wenn du eine Anwendung selbst entwickelst, weißt du bereits, wie sie funktioniert. Du weißt, wo die Einstellungen sind. Du weißt, welcher Button welchen Bildschirm öffnet. Du weißt, dass es eine bestimmte Geste gibt, weil du sie selbst programmiert hast.

Ein Tester weiß das nicht.

Genau dieser Unterschied brachte Dinge zum Vorschein, die wir wahrscheinlich übersehen hätten.

Verschiedene Android-Versionen verhielten sich unterschiedlich. Bildschirme hatten unterschiedliche Seitenverhältnisse und Pixeldichten. Widgets mussten angepasst werden. Medienbenachrichtigungen hatten Kompatibilitätsprobleme. Das Matching von Metadaten verhielt sich bei ungewöhnlichen Musikbibliotheken anders. Selbst etwas so Einfaches wie die Erklärung, wie man einen Musikordner manuell scannt, war weniger offensichtlich als gedacht.

Jede Entdeckung wurde Teil unseres Entwicklungszyklus.

App benutzen. Etwas finden. Melden. Beheben. Neue Version bauen. Erneut testen.

Während des Closed Tests durchlief Kleos Music Build für Build. Manche Änderungen waren klein. Andere betrafen ganze Teile der Benutzererfahrung. Entscheidend war nicht die Anzahl der Builds. Entscheidend war, dass jeder Build etwas darstellte, das wir durch echte Nutzung gelernt hatten.

Das brachte uns auch dazu, anders über ein weiteres Kleos-Projekt nachzudenken, Kleos Breathe.

Breathe zeigte uns die andere Seite des Closed Testings. Das Problem war nicht, dass wir Hunderte von Bugs gefunden hatten. Es war fast das Gegenteil: Es gab nicht genug Interaktion. Es gab wenig Feedback, wenige gemeldete Probleme und dadurch nur wenige Anzeichen dafür, dass das Produkt bei den Testern wirklich ankam.

Diese Erfahrung hat unsere Sicht auf Tests verändert.

Ein Closed Test ist nicht nur eine Hürde, die man vor der Veröffentlichung überwinden muss. Er kann auch ein Filter für das Produkt selbst sein.

Wenn Menschen eine Anwendung wiederholt kaum nutzen, nicht zu ihr zurückkehren und wenig dazu zu sagen haben, besteht die Lösung nicht immer darin, weitere Tester zu finden. Manchmal muss das Produkt selbst neu betrachtet werden.

Dieser Unterschied war für uns wichtig. Kleos Music erzeugte Fragen, weil die Menschen die App tatsächlich nutzten. Breathe erzeugte deutlich weniger Signale, weil es deutlich weniger Interaktion gab. Beide Erfahrungen waren nützlich, aber auf völlig unterschiedliche Weise.

Google bittet Entwickler außerdem darum, beim Antrag auf Produktionszugang zu erklären, was während des Closed Tests passiert ist. Dazu gehört unter anderem, wie die Tester gefunden wurden, wie sie die App genutzt haben, welches Feedback sie gegeben haben, was daraufhin geändert wurde und warum der Entwickler die App für bereit zur Veröffentlichung hält.

Für uns waren diese Fragen nicht einfach nur ein weiteres Formular. Sie waren fast eine Zusammenfassung des gesamten Entwicklungsprozesses.

Wir konnten auf echte Gespräche mit Testern, echte Probleme auf echten Geräten und echte Korrekturen verweisen.

Das war wahrscheinlich der wertvollste Teil des Google Play Closed Testings.

Es zwang uns, Annahmen zu hinterfragen, von denen wir nicht einmal wussten, dass wir sie hatten.

Wir gingen davon aus, dass bestimmte Bildschirme korrekt skalieren würden. Das war nicht immer der Fall.

Wir gingen davon aus, dass bestimmte Interaktionen sofort verständlich wären. Das waren sie nicht immer.

Wir gingen davon aus, dass unser Metadatensystem mit jeder Musikbibliothek gleich funktionieren würde. Echte Bibliotheken erwiesen sich als komplexer.

Und wir gingen davon aus, dass etwas, das für uns vollkommen logisch war, auch für alle anderen logisch sein würde.

Das ist es nicht.

Deshalb ist Android-App-Testing viel mehr als die Frage, ob eine Anwendung abstürzt. Ein guter Closed Test zeigt die Distanz zwischen dem, was der Entwickler bauen wollte, und dem, was der Nutzer tatsächlich erlebt.

Für kleosvic ist genau in dieser Distanz ein großer Teil der nützlichen Arbeit passiert.

Das Ziel war nie einfach, die Anforderung von 12 Testern zu erfüllen und den Produktions-Button zu drücken. Das Ziel war, die Zeit vor dem Launch zu nutzen, um das Produkt besser zu machen.

Wir haben den Prozess begonnen und dachten, wir würden eine App testen.

Wir haben ihn beendet und unsere eigenen Annahmen über die App getestet.

Und das war wesentlich wertvoller.