App-Fehler:
prüfen und beheben

Mit einem reproduzierbaren Symptom beginnen

Ein App-Fehler kann in der Oberfläche, im Backend, in einer Anbindung oder schon in der Prozessbeschreibung liegen. „Die App ist langsam“ reicht nicht, um eine Korrektur auszuwählen. Benötigt werden Gerät, Betriebssystemversion, Build-Nummer, Netzwerkzustand und Handlungsschritte.

Prüfen Sie Probleme mit vereinbarten Testkonten und Testdaten. Halten Sie für jede Beanstandung Soll- und Ist-Ergebnis, Zeitpunkt und eine Bildschirmaufnahme fest. Veröffentlichen Sie keine Zugriffstoken, personenbezogenen Daten oder Arbeitsdokumente in einem Gruppenchat. Tritt das Problem nur beim Kunden auf, beschaffen Sie zunächst eine Beschreibung der Bedingungen ohne sensible Inhalte.

Die Tabelle gibt eine Prüfrichtung vor, ermittelt die Ursache aber nicht automatisch. Dasselbe Symptom kann verschiedene Ursachen haben. Stellen Sie nach der Korrektur die ursprünglichen Bedingungen wieder her; andernfalls bleibt die Prüfung reine Formsache.

Fehler: Entwicklung nur anhand von Bildern kalkulieren

Im Entwurf gibt es eine Schaltfläche „Speichern“, doch Datenziel, Änderungsrechte und Verhalten ohne Internet sind nicht definiert. Diese Entscheidungen müssen dann während der Entwicklung getroffen werden. Das führt zu Streit über den Leistungsumfang und ständigen Änderungen an bereits fertigen Ansichten.

So prüfen Sie es: Wählen Sie drei zentrale Abläufe und lassen Sie jeden vom Anfang bis zum tatsächlichen Ergebnis durchspielen. Legen Sie Rollen, Felder, Datenquellen, alternative Zustände und Abnahmekriterien fest. Beschreiben Beteiligte unterschiedliche Ergebnisse derselben Funktion, ist die Anforderung noch nicht abgestimmt.

So beheben Sie es: Halten Sie die Grenzen der ersten Version und ein Änderungsprotokoll fest. Jede neue Funktion braucht eine Kalkulation, eine Priorität und die Entscheidung einer bevollmächtigten Person auf Kundenseite. Kürzen Sie Fehlerbehandlung nicht zugunsten der Zahl der Ansichten: Eine Aktion sicher wiederholen zu können, kann wichtiger sein als ein weiterer Bereich.

In der Beispiel-App für Außendiensttechniker kann „Auftrag abschließen“ bedeuten, einen Bericht lokal zu speichern, an die Einsatzleitung zu senden oder eine Abnahmebestätigung zu erhalten. Das sind drei verschiedene Zustände. Den genauen Ablauf der Anforderungsplanung beschreibt der Leitfaden zur App-Entwicklung.

Fehler: Nur die ideale Ansicht testen

Ein Entwurf mit kurzen Bezeichnungen wirkt aufgeräumt, doch in einem echten Datensatz verdeckt eine lange Adresse die Schaltfläche. Die Tastatur überlagert ein Feld, vergrößerter Text wird abgeschnitten und eine leere Liste wirkt wie ein Stillstand. Nutzer wissen nicht, ob die App funktioniert.

1. Füllen Sie die Ansicht mit langen und leeren Werten, die im tatsächlichen Prozess vorkommen können.
2. Vergrößern Sie die Systemschrift und wiederholen Sie den Hauptablauf.
3. Öffnen Sie die Tastatur im letzten Feld und prüfen Sie, ob Fehlermeldung und Schaltfläche sichtbar bleiben.
4. Gehen Sie sowohl über die Systemnavigation als auch über die App-Oberfläche zurück.
5. Prüfen Sie die Screenreader-Ausgabe wichtiger Elemente und verständliche Aktionsbeschriftungen.

Die Korrektur muss Umbruch, Scrollen, Beschriftungen und Zustände berücksichtigen, nicht nur kleinere Schrift. Prüfen Sie außerdem den Schutz vor versehentlichem Löschen und die Korrektur falscher Eingaben. Rot allein erklärt nicht, was geändert werden muss.

Ein gutes Ergebnis: Nutzer verstehen den aktuellen Zustand, erkennen den nächsten Schritt und können Eingaben ohne Verlust ausgefüllter Felder korrigieren. Wiederholen Sie die Prüfung auf kleinen und großen Bildschirmen sowie mit den Barrierefreiheitseinstellungen des Systems.

Fehler: Verbindungsabbruch führt zu Datenverlust

Smartphones wechseln zwischen Netzen, Apps werden in den Hintergrund versetzt und das System kann ihren Prozess beenden. Hat das Team nur stabiles WLAN getestet, können Entwürfe und Übertragungen unvorhersehbar reagieren. Nicht jede App muss vollständig offline funktionieren, aber jede muss ihre Grenzen verständlich erklären.

1. Beginnen Sie mit einem Auftrag und trennen Sie die Netzwerkverbindung.
2. Speichern Sie auf dem vorgesehenen Weg und starten Sie die App neu.
3. Prüfen Sie, ob die vereinbarten Felder und Anhänge erhalten geblieben sind.
4. Stellen Sie die Verbindung wieder her und warten Sie auf die Bestätigung des Datenaustauschs.
5. Wiederholen Sie den Ablauf mit einem Verbindungsabbruch nach dem Senden, wenn das Ergebnis noch unbekannt ist.

Die Versandwarteschlange muss für Nutzer sichtbar sein. Steht ein Datensatz im Konflikt mit einer Serveränderung, dürfen aktuelle Daten nicht stillschweigend durch eine alte Kopie ersetzt werden. Vereinbaren Sie die Konfliktregeln mit der prozessverantwortlichen Person.

Fehler: Berechtigungen nur durch versteckte Schaltflächen umsetzen

Blendet die App einen fremden Auftrag in der Liste aus, liefert der Server ihn aber auf Anfrage aus, ist die Zugriffstrennung nicht umgesetzt. Ein weiteres Risiko besteht, wenn nach dem Abmelden Daten des vorherigen Nutzers auf einem gemeinsam verwendeten Gerät verbleiben.

Richten Sie in der Testumgebung zwei Rollen und Datensätze mit unterschiedlichen Eigentümern ein. Prüfen Sie Listen, Suche, direkte Aufrufe aus Benachrichtigungen und Kontowechsel. Lassen Sie Entwicklung oder Sicherheitsspezialisten die serverseitigen Prüfungen an denselben Objekten bestätigen. Testen Sie keine fremden Systeme oder echten Konten ohne Erlaubnis.

Verweigern Sie separat den Zugriff auf Kamera, Standort oder Benachrichtigungen. Die App muss erklären, welche Funktion nicht verfügbar ist, und andere Funktionen erhalten, soweit der Prozess dies zulässt. Berechtigungen sollten zu einer nachvollziehbaren Aktion angefragt werden, statt alle beim ersten Öffnen einzufordern.

Nutzen Sie für die Planung technischer Prüfungen OWASP MASVS. Besprechen Sie die anwendbaren Anforderungen an Speicherung, Autorisierung, Datenaustausch und Datenschutz. Ein formaler Verweis auf einen Standard ersetzt keine Beschreibung durchgeführter Prüfungen und festgestellter Grenzen.

Fehler: Eine Erfolgsmeldung mit einem erfolgreichen Vorgang gleichsetzen

Die Schaltfläche reagiert, doch die Bestellung erscheint nicht im CRM. Eine Benachrichtigung kommt an, öffnet aber einen anderen Datensatz. Der Zahlungsstatus ist unklar, und der Nutzer versucht es erneut. Solche Probleme werden über die gesamte Systemkette geprüft.

Prüfen Sie Zahlungsabläufe zuerst in der vorgesehenen Testumgebung des Anbieters. Vereinbaren Sie Tests im Echtbetrieb separat. Die Anzeige auf dem Endgerät darf nicht die einzige Grundlage für eine Zahlungsbestätigung sein.

Jeder Datenaustausch braucht eine verantwortliche Person und die Möglichkeit, einen Vorgang über seine Kennung zu finden. Kann nur der Autor des Codes einen verlorenen Auftrag nachvollziehen, ergänzen Sie Diagnosemöglichkeiten und Supportanleitung. Dazu gehört auch die Einrichtung von CRM und Anbindungen.

Fehler: „Auf unserem Smartphone funktioniert alles“

Ein Modell steht nicht für den gesamten Gerätebestand. Die Geschwindigkeit hängt von Arbeitsspeicher, Datenmenge, Netzwerk und Ablauf ab. Ein Test mit fünf Datensätzen bestätigt keinen Katalog mit Tausenden von Objekten, und eine Neuinstallation prüft keine bestehende Nutzungshistorie.

Vereinbaren Sie eine Gerätematrix anhand der Zielgruppe: unterstützte Betriebssystemversionen, typische Bildschirmgrößen und ein leistungsschwaches Gerät. Prüfen Sie Kaltstart, lange Listen, das Hochladen eines Anhangs und die Rückkehr aus dem Hintergrund. Erfassen Sie Dauer, Bedingungen und Ergebnis; vergleichen Sie nach Änderungen denselben Vorgang.

In dem Google-Play-Bericht vor der Veröffentlichung klappen Sie den Fehler auf und wählen Sie ein Gerät. Die Diagnoseunterlagen helfen, Absturz, Hänger und Oberflächenproblem zu unterscheiden. Übermitteln Sie dem Entwickler Build-Nummer und verfügbare Angaben und wiederholen Sie die Prüfung mit der korrigierten Version.

Verbessern Sie Kennzahlen nicht durch Funktionsverlust: Ausgeblendete Fotos, deaktivierte Synchronisation oder eine fehlende Ansicht müssen auf ihre Folgen für das Produkt geprüft werden.

Fehler: Installation prüfen, Updates aber nicht

Eine neue Version kann auf einem leeren Gerät funktionieren und beim Update einer alten Installation Daten verlieren. Auch der Server darf bisher unterstützte Versionen nicht unerwartet beeinträchtigen: Nutzer aktualisieren nicht alle gleichzeitig.

1. Installieren Sie den vorherigen unterstützten Build auf einem Testgerät.
2. Erstellen Sie die zu erhaltenden Datensätze, Entwürfe und Zustände.
3. Aktualisieren Sie die App auf dem regulär vorgesehenen Weg.
4. Prüfen Sie Anmeldung, Daten, Versand, Benachrichtigungen und Zusammenarbeit mit dem aktuellen Server.
5. Vereinbaren Sie Maßnahmen bei Fehlern: Verteilung anhalten, Korrektur bereitstellen oder die betroffene Funktion deaktivieren, falls ein solcher Mechanismus vorgesehen ist.

Ein Server-Rollback ist nicht immer mit bereits aktualisierten Daten kompatibel. Prüfen Sie den Wiederherstellungsplan im Voraus. Für iOS ermöglicht TestFlight die Verteilung von Builds an Gruppen und das Sammeln testbezogener Rückmeldungen.

Gehen Sie bei einer Store-Ablehnung vom konkreten Prüfhinweis aus. Vergleichen Sie tatsächliches Verhalten, Beschreibung, Prüferzugang und Datenangaben mit den App-Store-Prüfrichtlinien oder den Regeln der gewählten Plattform. Beheben Sie die Ursache, fügen Sie eine Erläuterung bei und prüfen Sie den Build erneut. Eine Genehmigung kann nicht garantiert werden.

Fehler: Installationen statt erledigter Aufgaben messen

Eine App kann ohne Absturz laufen und trotzdem nutzlos sein: Nutzer finden die benötigte Aktion nicht, verstehen die Registrierung nicht oder kehren zum gewohnten Kanal zurück. Stellen Sie zuerst sicher, dass Analyseereignisse tatsächliche Ergebnisse abbilden.

Führen Sie einen Testablauf durch und gleichen Sie die Ereigniskette mit dem Serverdatensatz ab. Prüfen Sie wiederholte Klicks und fehlgeschlagene Versuche: Sie dürfen den Erfolgszähler nicht automatisch erhöhen. Unterteilen Sie die Daten anschließend nach Version, Gerät sowie neuen und wiederkehrenden Nutzern.

Bricht der Ablauf an einem bestimmten Schritt ab, beobachten Sie Nutzer und prüfen Sie ihre Bedingungen. Eine andere Schaltflächenfarbe löst kein Pflichtfeld, dessen Antwort die Person nicht kennt. Beseitigen Sie zuerst das Hindernis und bewerten Sie dann Veränderungen bei abgeschlossenen Aktionen und Supportanfragen.

Übernehmen Sie keine unnötigen Formularinhalte in die Analyse. Für Untersuchungen reichen oft Ereignisname, Version und technisches Ergebnis. Die Nutzergewinnung sollte mit messbarem Marketing verknüpft werden, nachdem der Weg zur nützlichen Aktion geprüft wurde.

Ursache beheben und Ergebnis erneut prüfen

Sammeln Sie Beanstandungen in einer gemeinsamen Liste. Unterscheiden Sie bestätigte Fehler, neue Wünsche und Fragen zu Anforderungen. Erfassen Sie für jeden Punkt Priorität, Zuständigkeit, korrigierten Build und Ergebnis des erneuten Tests.

Prüfen Sie nach der Korrektur benachbarte Funktionen. Eine geänderte Anmeldung kann Benachrichtigungen beeinflussen, ein Update des lokalen Speichers die Entwürfe. „Im Code behoben“ ersetzt nicht die Prüfung des gelieferten Builds.

Prüfen Sie zugleich die Betreuungsfähigkeit: Zugänge des Eigentümers, Quellcode, Build-Anleitungen, Diensteverzeichnis und Zuständigkeiten. Eine andere Fachkraft muss das Projekt anhand der Dokumentation bauen und starten können. Besprechen Sie Wiederherstellung und Weiterentwicklung im Rahmen der Arbeiten an Ihrer mobilen App; die Kosten nach der Veröffentlichung erläutert der Beitrag zum Budget.

Vor dem Schließen einer Beanstandung prüfen

Häufige Fragen zu App-Fehlern