Apps testen: eine Anleitung für nachvollziehbares Feedback

Was bedeutet „eine App testen“ überhaupt?

Eine App zu benutzen und eine App zu testen sind nicht dasselbe. Bei einem Test versuchst du, eine konkrete Aufgabe zu lösen, achtest auf Hindernisse und hältst fest, was passiert ist. Die Frage ist nicht nur „gefällt mir die App?“, sondern beispielsweise: „Kann ich nach einer Unterbrechung meinen begonnenen Vorgang wiederfinden?“ oder „Verstehe ich, warum eine Eingabe nicht angenommen wird?“

Nutzertests machen besonders dort einen Unterschied, wo ein Ablauf auf dem Entwicklungssystem funktioniert, aber im Alltag scheitert: langsame Verbindungen, kleine Bildschirme, unterschiedliche Betriebssysteme, abgelenkte Nutzung oder unklare Formulierungen. Ein einzelner Test beweist nicht, wie sich alle Nutzer verhalten. Er kann jedoch eine konkrete, nachvollziehbare Hürde sichtbar machen.

Vor dem ersten Klick: Testziel, Gerät und Daten klären

Lies zuerst das Briefing und notiere das Ziel in einem Satz. Sollst du die Navigation prüfen, einen Tarif vergleichen oder eine Fehlermeldung bewerten? Prüfe dann Gerät, Betriebssystem und benötigte Kamera- oder Browserberechtigungen. Wichtig: Wenn eine Aufgabe eine freigegebene Testumgebung vorsieht, arbeite ausschließlich dort und nutze die bereitgestellten Testdaten. Private Bank-PINs, TANs und Passwörter gehören weder in Testformulare noch in Screenshots oder Berichte.

Ein kurzer Vorab-Check vermeidet später schwer deutbare Befunde:

Vorbereitung	Konkrete Frage
Aufgabe	Welche Handlung soll am Ende gelingen?
Umgebung	Welche App-Version, welches Gerät und welches Betriebssystem nutze ich?
Startzustand	Bin ich ausgeloggt, angemeldet oder mitten in einem Vorgang?
Daten	Sind fiktive Zugangsdaten und Testlinks freigegeben?
Abbruch	Bei welchem Schritt muss ich stoppen und das Team fragen?

Wenn das Briefing nicht sagt, ob du einen echten Antrag abschicken darfst, schicke ihn nicht ab. Frage nach, bevor du personenbezogene Angaben oder Zahlungen übermittelst. Für digitale Aufträge bei Pruviso sind die jeweiligen Anweisungen im Testerbereich maßgeblich.

Vier Durchläufe, die unterschiedliche Probleme zeigen

1. Der normale Weg: Löse die Aufgabe einmal ohne Hilfe. Notiere, ob die Beschriftungen zu deiner Erwartung passen und wie du erkennst, dass der Schritt erfolgreich war. Ein Bildschirm, der schön aussieht, aber kein Ergebnis bestätigt, lässt Nutzer im Unklaren.

2. Ein plausibler Fehler: Lass ein freiwilliges Feld leer, korrigiere eine zulässige Fehleingabe oder verwende die Zurück-Funktion. Geht die Eingabe verloren? Steht die Fehlermeldung direkt am betroffenen Feld? Hilft sie beim nächsten Versuch? Bitte keine Sperren provozieren und keine fremden Konten ausprobieren.

3. Eine Unterbrechung: Wechsle kurz zu einer anderen App oder lade eine Seite erneut, soweit es das Briefing erlaubt. Gerade auf dem Smartphone ist ein unterbrochener Ablauf normal. Prüfe, ob gespeicherte Eingaben und der aktuelle Schritt noch nachvollziehbar sind.

4. Ein anderes Nutzungsformat: Prüfe Hoch- und Querformat, größere Schrift oder einen schmaleren Bildschirm. Dabei zählt nicht nur, ob der Inhalt noch sichtbar ist, sondern ob Schaltflächen erreichbar und Informationen verständlich bleiben. Wer zusätzlich Tastatur und Fokus testen möchte, findet eine eigene Anleitung zur Barrierefreiheit.

Bei jedem Durchlauf gilt: Beobachtung und Interpretation trennen. „Der Weiter-Button war nach dem Drehen des Smartphones nicht sichtbar“ ist beobachtbar. „Die App ist schlecht entwickelt“ ist eine Wertung ohne ausreichende Diagnose.

Eine Beobachtung so notieren, dass ein Team damit arbeiten kann

Ein hilfreicher Bericht beantwortet fünf Fragen: Wo? Was war die Aufgabe? Welche Schritte führten zum Problem? Was wurde erwartet? Was passierte tatsächlich? Dazu kommen Gerät, Betriebssystem, App- oder Browserversion und – falls bekannt – der Zeitpunkt. Stelle nur die Information bereit, die für die Wiederholung nötig ist. Bilder sollten private Daten schwärzen und den relevanten Ausschnitt zeigen.

Beispiel: „Android 15, App-Version 2.4, Tarifvergleich: Nach Auswahl eines Filters und anschließendem Zurückspringen wird die Auswahl zurückgesetzt. Erwartet: Die vorherige Auswahl bleibt erhalten. Tatsächlich: Alle Filter stehen wieder auf Standard.“ Das ist für ein Team nützlicher als „Filter kaputt“.

Die ausführliche Bug-Report-Vorlage zeigt, wie du diese Angaben ohne unnötigen Fachjargon strukturierst.

Checkliste vor dem Einreichen

• Habe ich genau die vereinbarte Testumgebung genutzt?
• Kann jemand meine Schritte auf einem vergleichbaren Gerät wiederholen?
• Sind Beobachtung, erwartetes Verhalten und Verbesserungsvorschlag getrennt?
• Sind Screenshots frei von echten Zugangsdaten und Daten Unbeteiligter?
• Habe ich auch funktionierende Schritte fair beschrieben?
• Habe ich unklare oder risikoreiche Schritte abgebrochen und nachgefragt?

Wenn du mehr über den Bewerbungs- und Testablauf wissen möchtest, lies So funktioniert Pruviso und die häufigen Fragen. Unternehmen finden unter digitale Tests eine Übersicht der Testbereiche.

Weiterführende Grundlagen

• W3C WAI: Menschen in Evaluationen einbeziehen – warum direkte Beobachtung automatisierte Prüfungen ergänzt.
• W3C WAI: Web-Angebote prüfen und bewerten – Überblick über manuelle und technische Methoden.

Ein Testprotokoll, das auch später noch verständlich ist

Während einer Aufgabe entstehen schnell viele Eindrücke. Schreibe sie deshalb möglichst zeitnah in einer kleinen Tabelle auf. Eine Spalte enthält den Schritt, eine die Beobachtung, eine die mögliche Auswirkung und eine offene Frage. So bleiben Fakten, Bewertung und Rückfrage getrennt. Gerade bei mobilen Tests ist das sinnvoll, weil sich ein kurzer Moment – etwa ein verschwundener Button nach dem Drehen – später nur schwer aus dem Gedächtnis rekonstruieren lässt.

Ein gutes Protokoll muss nicht jede Sekunde des Bildschirms beschreiben. Wähle die Details danach aus, ob sie die Aufgabe erklären oder die Wiederholung ermöglichen. Ein Wechsel zu einer anderen App kann relevant sein, wenn danach Eingaben fehlen. Die Farbe einer unwichtigen Trennlinie ist es meistens nicht. Wenn ein Verhalten nur einmal auftritt, kennzeichne es als einmalige Beobachtung und beschreibe die Bedingungen. So entsteht kein stärkerer Eindruck, als die Beobachtung trägt.

Hilfreich sind außerdem kurze Zeitmarken: „00:00 Aufgabe gestartet“, „00:02 Filter gewählt“, „00:04 nach Zurücksetzen Auswahl verloren“. Bei einer freigegebenen Bildschirmaufnahme kann das Team direkt zur Stelle springen. Falls Aufnahmen nicht erlaubt sind, ersetzt eine solche Chronologie keine Beweissicherung, macht den Bericht aber trotzdem präziser. Vor dem Einreichen prüfst du noch einmal, ob Benachrichtigungen, echte Namen oder Zugangsdaten im Material sichtbar sind.

Gute und schlechte Ergebnisse gleichermaßen beschreiben

Ein fairer Testbericht nennt auch Schritte, die ohne Hürde funktioniert haben. Das zeigt, welcher Teil des Ablaufs bereits verständlich ist und verhindert, dass ein einzelner Fehler den gesamten Prozess scheinbar unbrauchbar macht. Formuliere trotzdem konkret: „Die Suche war nach Öffnen des Menüs auffindbar und lieferte die erwarteten Ergebnisse“ ist informativer als „alles gut“.

Verbinde einen Befund nicht automatisch mit einer fertigen Lösung. Eine Beobachtung kann mehrere Ursachen haben: Ein Button wird vielleicht übersehen, weil seine Beschriftung unklar ist, weil er erst nach dem Scrollen erscheint oder weil ein früherer Schritt keine Bestätigung gezeigt hat. Beschreibe zunächst, was die Person erlebt hat. Ein Produktteam kann anschließend Hypothesen prüfen und eine Änderung mit einem neuen Test absichern.

Damit wird aus dem App-Test ein kleiner Lernkreislauf: Ziel festlegen, Aufgabe durchführen, Beobachtung dokumentieren, Änderung priorisieren und denselben kritischen Schritt erneut prüfen. Mehr zur Aufbereitung findest du in der Vorlage für Bug-Reports; den Unterschied zwischen einer einzelnen qualitativen Beobachtung und einer größeren Studie erklärt die Anleitung für Website-Usability-Tests.