In diesem Ratgeber
Angenommen (Beispielzahl), der Test hat 40 Probleme gefunden, und der Release-Termin rückt näher. Du kannst nicht alles beheben, und du musst es auch nicht. Die Frage lautet nicht „Ist die App perfekt?", sondern „Ist sie sicher und gut genug für echte Nutzer?" Eine kurze Triage beantwortet das in einer Stunde.
Schritt 1: Sammeln und zusammenführen
Lege alle Probleme in eine Liste. Führe Dubletten zusammen und halte je eine Zeile fest: was passiert, wo, wie oft. Wirf weg, womit du nichts anfangen kannst, oder verschiebe es in eine Liste „braucht mehr Infos" (siehe Fehler eines Testers nicht nachstellbar).
Schritt 2: Schwere und Reichweite bewerten
Gib jedem Problem zwei Bewertungen.
Schwere: Was macht es mit dem Nutzer? - 3, kritisch. Absturz, Datenverlust, Anmeldung oder Bezahlung unmöglich, Sicherheits- oder Datenschutzproblem. - 2, ernst. Eine Hauptfunktion ist kaputt oder verwirrend, aber es gibt einen Umweg. - 1, gering. Optisch, selten oder eine Nebenfunktion.
Reichweite: Wie viele Nutzer treffen darauf? - 3, fast alle, auf dem Hauptweg. - 2, eine klare Gruppe (ein Gerätetyp, eine Einstellung, eine Sprache). - 1, Seltenheitsfall.
Schritt 3: Triage-Matrix
| Reichweite 1 | Reichweite 2 | Reichweite 3 | |
|---|---|---|---|
| Schwere 3 | Vor Release beheben | Vor Release beheben | Vor Release beheben |
| Schwere 2 | Später | Beheben, wenn günstig, sonst entscheiden | Vor Release beheben |
| Schwere 1 | Später | Später | Beheben, wenn günstig |
Schwere 3 blockiert den Release immer, auch wenn es selten ist. Ein seltener Absturz, der Nutzerdaten vernichtet, kostet trotzdem Vertrauen. Alles in den „Später"-Feldern kommt mit einer Zielversion auf eine Liste.
Schritt 4: Aufwand dazunehmen
Sieh dir an, was in den Feldern „beheben, wenn günstig, sonst entscheiden" übrig ist. Schätze den Aufwand in drei Größen: unter einer Stunde, etwa ein Tag, mehr als ein Tag. Nimm die schnellen zuerst. Ein Tag Arbeit für ein Problem mit Schwere 2 und Reichweite 2 ist eine echte Abwägung, kein automatisches Ja.
Schritt 5: Entscheiden, was erscheint
Stelle drei Fragen:
- Ist noch ein Release-Blocker offen? Wenn ja, bist du nicht bereit.
- Kann der Rest auf das erste Update warten? Halte es mit Zielversion fest.
- Kannst du das Risiko senken statt beheben? Verstecke eine unfertige Funktion, baue einen sicheren Ausweichweg ein oder begrenze den ersten Release auf weniger Geräte oder Länder.
Kannst du die erste und die zweite Frage nicht mit Ja beantworten, verschiebe den Termin. Eine kurze Verspätung kostet weniger als ein Start mit kaputten Grundlagen.
Tipps für Einzelentwickler
- Triage begrenzen. Eine Stunde, nicht mehr.
- In Runden beheben. Erst die Blocker, erneut testen, dann die günstigen.
- Nicht gleichzeitig beheben und Funktionen ergänzen. Neuer Code bringt neue Fehler.
- Den Hauptweg erneut testen (Installation, Anmeldung, die eine Kernaufgabe), auf mindestens einem echten Gerät nach der letzten Änderung.
- Abstürze separat führen. Zu Abstürzen siehe Absturzberichte priorisieren, wenn du allein entwickelst; für Feedback ohne Absturz App-Feedback priorisieren: Wirkung gegen Aufwand.
Weiterlesen
- Übersicht: Probleme beim App-Testen und Lösungen
- Zu viele Funktionswünsche von Testern
- Absturzprotokolle vom Handy eines Testers holen
Du willst ein zweites Augenpaar auf dem Release-Kandidaten? AppReviewX liefert privates, strukturiertes Feedback von anderen Entwicklern; ein Feedback, das du schreibst, bringt einen Credit. So funktioniert AppReviewX