Banking-Apps sicher testen: gute Beobachtungen ohne private Daten

Nutzbarkeit prüfen ist keine echte Banktransaktion

Bei Banking- und Fintech-Oberflächen treffen verständliche Bedienung und sensible Daten aufeinander. Gerade deshalb muss ein Test klar begrenzt sein. Du kannst untersuchen, ob Begriffe, Navigation, Hinweise und Fehlermeldungen verständlich sind, ohne mit einem echten Privatkonto zu experimentieren. Eine UI-Beobachtung ist zudem keine Sicherheitszertifizierung und keine Bonitäts- oder Finanzberatung.

Der erste Schritt ist immer die Klärung der Testumgebung: Gibt es ein freigegebenes Testsystem oder einen internen Prototyp? Welche Testdaten sind vorgesehen? Wo endet der Ablauf? Fehlt eine klare Freigabe, stoppe vor einer echten Kontoeröffnung, einem Kreditantrag oder einer Überweisung. Für Pruviso-Aufträge steht die jeweils erlaubte Umgebung im Briefing des Testerbereichs.

Vor dem Test: Grenzen schriftlich festhalten

Ein gutes Briefing unterscheidet drei Dinge: Was soll bewertet werden? Welche Daten dürfen verwendet werden? Welche Aktion darf auf keinen Fall ausgelöst werden? Eine Oberfläche kann äußerlich einem echten Bankangebot gleichen, während der Test ausschließlich bis zur Vorschau oder zum nächsten Informationsschritt reicht.

Bereich	Sinnvoller Beobachtungspunkt	Klare Grenze
Login	Sind Hinweise und Fehlertexte verständlich?	Keine private PIN oder echten Zugangsdaten eingeben.
Kontenübersicht	Sind Bezeichnungen, Beträge und Hilfe auffindbar?	Nur freigegebene fiktive Konten verwenden.
Überweisung	Ist vor der Bestätigung erkennbar, was passieren würde?	Keine echte Zahlung oder TAN auslösen.
Kreditantrag	Sind Schritte, Kosten und Abbruch verständlich?	Nicht mit echten Personendaten absenden.
Verifizierung	Sind Gerätehinweise und Zuständigkeiten klar?	Nur den ausdrücklich autorisierten Testablauf starten.

Lege für Screenshots fest, wie du personenbezogene Daten schwärzt. Ein gut lesbarer Fehlerhinweis reicht meist als Ausschnitt; eine ganze Kontoseite ist selten nötig.

Fünf Beobachtungen, die wirklich helfen

Orientierung: Weißt du in jedem Schritt, wo du bist und wie du zurückkommst? Gerade nach einem Fehlversuch ist ein verlässlicher Rückweg wichtig.

Begriffe: Werden Fachwörter erklärt, bevor eine Entscheidung verlangt wird? Schreibe konkrete missverständliche Formulierungen auf, statt die gesamte Seite pauschal als „kompliziert“ zu bewerten.

Folgen einer Aktion: Unterscheidet die Oberfläche deutlich zwischen Vorschau, Speicherung und verbindlicher Bestätigung? Bei Finanzprozessen ist diese Unterscheidung besonders wichtig, auch wenn du im Test nicht tatsächlich abschließt.

Fehlerbehandlung: Bleibt eine fiktive Eingabe erhalten, wenn ein Feld korrigiert werden muss? Gibt die Meldung einen nächsten Schritt an, ohne private Daten offenzulegen?

Mobile Nutzung: Sind Kostenhinweise, Schaltflächen und Kontaktmöglichkeiten auf einem schmalen Bildschirm erreichbar? Eine zentrale Information darf nicht nur am Desktop sichtbar sein.

Wie du diese Beobachtungen in einen Testplan übersetzt, zeigt Usability-Tests für Websites planen. Für reproduzierbare technische Probleme hilft die Bug-Report-Vorlage.

Testbericht ohne private Daten

Notiere Version und Gerät, die genaue Stelle, deine Aufgabe sowie erwartetes und tatsächliches Verhalten. Bei einem Fehler wie „Kostenübersicht verschwindet nach Zurück“ genügen ein präziser Schritt und ein geschwärzter Screenshot. Kopiere keine IBAN, keinen Ausweis, keine TAN und keine Zugangsdaten in den Bericht. Wenn eine echte Website für eine Testaufgabe zusätzliche Dokumente anfordert, kläre erst den Zweck mit dem zuständigen Team und halte dich an das Briefing.

Pruviso beschreibt Banking- und Fintech-Tests als Prüfung digitaler Nutzerwege. Wer sich als Testperson interessiert, findet den Bewerbungsablauf unter So funktioniert’s. Unternehmen können unter Kontakt einen sicheren, abgegrenzten Test besprechen.

Zur Einordnung

• OWASP Mobile Application Security behandelt Sicherheitsanforderungen an mobile Anwendungen. Ein Nutzbarkeitstest ersetzt keine der dort beschriebenen technischen Sicherheitsprüfungen.
• W3C WAI: Evaluation von Websites erklärt, warum manuelle Beobachtung und technische Werkzeuge unterschiedliche Fragen beantworten.

Typische Missverständnisse vor einer Bestätigung

Bei Geldthemen ist der wichtigste Testfall häufig nicht die schöne Startseite, sondern der Moment vor einer Entscheidung. Wird eine Auswahl als unverbindliche Vorschau bezeichnet? Sind Bearbeitungs- oder laufende Kosten in derselben Ansicht auffindbar? Ist sichtbar, welche Angaben noch fehlen? Und gibt es eine verständliche Zusammenfassung, bevor ein Schritt verbindlich werden könnte?

Solche Fragen lassen sich mit fiktiven Daten prüfen. Die Testperson beschreibt, was sie an dieser Stelle erwartet hätte, ohne einen echten Vorgang auszulösen. Wenn ein Button, ein Hinweis oder eine Zusammenfassung missverständlich ist, wird der genaue Text zitiert und die Auswirkung notiert. Das ist nützlicher als eine pauschale Aussage wie „zu wenig transparent“.

Grenzen zwischen Usability und Sicherheit

Ein Login, der leicht verständlich ist, ist nicht automatisch sicher. Umgekehrt kann ein zusätzlicher Sicherheitsschritt sinnvoll sein und trotzdem schlecht erklärt werden. Der Testbericht sollte deshalb klar sagen, welche Frage tatsächlich geprüft wurde: Orientierung, Fehlermeldung, Barrierefreiheit oder ein technisches Sicherheitsmerkmal. Für Penetrationstests, Verschlüsselungsprüfungen, Berechtigungsanalysen und regulatorische Bewertungen sind eigene Fachverfahren erforderlich.

Auch die verwendeten Daten gehören in den Bericht: „freigegebener Testzugang“ oder „fiktiver Datensatz“ reicht in der Regel aus. Private Zugangsdaten werden nicht wiederholt. Wenn während eines Tests versehentlich echte Daten sichtbar werden, wird der Vorgang abgebrochen und die zuständige Stelle informiert. Ein Screenshot wird nur erstellt, wenn er freigegeben und sicher geschwärzt werden kann.

Eine kurze Nachbereitung für Teams

Nach mehreren Beobachtungen werden Befunde nach Aufgabe und Risiko geordnet. Ein verlorener Filter ist ärgerlich; ein unklarer Button direkt vor einer verbindlichen Bestätigung kann eine höhere Priorität haben. Prüfe die überarbeitete Ansicht anschließend erneut mit demselben Szenario und dokumentiere, ob die Unterscheidung zwischen Vorschau und Abschluss jetzt klarer ist.

Die Anleitung für Website-Usability-Tests erklärt den Testplan dahinter. Für technische und redaktionelle Details eines einzelnen Befunds ist die Bug-Report-Vorlage geeignet.