4 kritische Bereiche, die beim Testen von mobilen Banking Apps berücksichtigt werden müssen

Gemäß eines Berichts von KPMG wird sich die Anzahl der Nutzer des Mobile Bankings verdoppeln und im Jahr 2019 ein Viertel der Weltbevölkerung ausmachen. Gartner erwartet, dass 2018 50% der Nutzer in den entwickelten Märkten Smartphones oder Wearables für mobile Zahlungen verwenden werden. Mit dem Erscheinen von Web und mobilen Bank-Dienstleistungen hat sich ein Großteil der täglichen Transaktionen bereits von alten Kanälen, wie z.B. Bankzweigstellen und Bankomaten abgewandt.

Die Banken verstehen die Notwendigkeit einer Fokussierung auf eine durchgängige Cross-Channel Erfahrung für Ihre Kunden, um diese bei sich zu halten. Bei der Entwicklung von Anwendungen sind eine hohe Leistung und Benutzerfreundlichkeit Schlüsselfaktoren, jedoch führt die steigende Kundennachfrage an mobilen Anwendungen zu entsprechend gestiegenen Anforderungen in Bezug auf robustes mobiles Testen.

In den meisten Testszenarien für Banking-Anwendungen neigen QA Teams dazu, sich auf die Gewährleistung von App Security zu konzentrieren. Dies ist bei Retail-Banking-Anwendungen, die auf öffentlichen Plattformen betrieben werden, eine größere Sorge, da Anwender anfälliger für Cyber-Diebstähle sind. Jedoch gibt es abgesehen von den standardisierten Testmethoden, die die Sicherheit einer App garantieren sollen (funktionales Testen, Sicherheits- und Leistungstests), vier kritische Bereiche, welche selbst erfahrene Tester oft übersehen..

Generierung von spezifischen Testdaten

Die persönlichen Daten eines Kunden, wie dessen Telefonnummer, Adresse, Geburtsdatum oder dessen Kontonummer, sind jene vertraulichen Daten, die leicht missbraucht werden können, sollten diese öffentlich zugänglich sein. In den meisten Ländern bestehen daher gesetzliche Anforderungen zum Schutz persönlicher Daten. Dies führt jedoch häufig zur Nichtverfügbarkeit von produktionsähnlichen Daten und stellt somit eine Herausforderung für Tester dar. Ein gutes Beispiel für die richtige Generierung von Testdaten ist die Retail-Banking-App, welche Tests auf verschiedenen Geräten mit unterschiedlichen Bildschirmauflösungen garantiert. Beispielsweise kann ein Kunde mit einem langen Namen 1 Milliarde USD ($ 1.000.000.000) auf dem Konto haben, wogegen ein anderer Kunde nur ein Guthaben von wenigen tausend Dollar hat. In beiden Fällen ist das Testen der App mit Daten, die der Produktionsumgebung ähnlich sind, entscheidend, um sicherzustellen, dass das Layout des Bildschirms mit den verschiedenen Datensätzen intakt ist.

Ein Ansatz der Datenmaskierung und die Erstellung von synthetischen Daten kombiniert kann dieses Problem erfolgreich lösen. Bei der Datenmaskierung werden die auf das Konto bezogenen Informationen durch automatische Scripts maskiert. Die maskierten Daten werden dann in eine für Testzwecke abgespeckte Datenbank eingespeist. Auf ähnliche Art und Weise werden synthetische Testdaten in einer Testumgebung erstellt, sobald das Verständnis für den gesamten Geschäftsablauf erworben wurde.

Klare Hervorhebung von Unterschieden in Testplänen

Die Testpläne sollten die funktionalen, datenbezogenen und technischen Unterschiede zwischen Produktions- und Testumgebungen klar darstellen, damit die damit verbundenen Risiken im Vorfeld vermieden werden können. In den meisten Banking Anwendungen ist der Datentransfer zwischen verschiedenen Produktionssystemen üblicherweise durch FTP automatisiert, wogegen in den meisten Testsystemen der Datentransfer manuell erfolgt. Lassen Sie uns annehmen, der monatliche Kontoauszug wird in der Produktion automatisch an ein Data Warehouse (DWH) übermittelt, um die Transaktionshistorie zu bewahren, wird jedoch in der Testumgebung manuell abgewickelt (d.h. der Tester gibt die Daten in ein bestimmtes Verzeichnis ein und das DWH verwendet diese anschließend). Der automatische Übergang in die Produktion ermöglicht das Testen von Szenarien wie Übertragungsverzögerung, Mehrfachübermittlung, eine neue Datei überschreibt eine bestehende Datei usw. Bei der mobilen App kann die Verzögerung bei der Übermittlung zu einer erheblichen Kundenunzufriedenheit führen, da die Nutzer von Smartphones eine schnelle Reaktion der App erwarten. Solche Szenarien müssen berücksichtigt werden, und die Risiken sollten frühzeitig behandelt oder in den Testplänen deutlich hervorgehoben werden.

Abwicklung von hohen Datenvolumen

Eine weitere Herausforderung im Umgang mit Retail-Banking-Apps besteht in der Handhabung von hohen Datenvolumen. Eine kleiner Vorgang kann substanzielle Mengen an Daten verursachen. Eine einfache Aktion eines online Kunden kann zum Beispiel die Erfassung des Log-In Zeitpunkts, des Standorts des Benutzers und aller durchgeführten Schritte dieser Aktion zur Folge haben. Banken müssen genügend Ressourcen für die Speicherung dieser Details, die für Abwehr und Problembehebung von Cyber-Kriminalität helfen können, zur Verfügung haben. Tatsächlich ist die Datenerfassung sehr oft eine Anforderung bei der Auditierung und Teil der Einhaltung gesetzlicher Vorschriften. Mobile Geräte verfügen jedoch teilweise über limitierte Hardware Ressourcen, wie RAM, Prozessorgeschwindigkeit usw. Es ist absolut kritisch, dass die Device Performance mit hohen Datenvolumen getestet wird, um sicherzustellen, dass der Endnutzer beim Einsatz der App eine positive Erfahrung macht. Der Benutzer möchte keine App mit beeinträchtigter Leistung benutzen, selbst wenn die zugrundeliegende Funktionalität wie erwartet funktioniert.

In diesem Fall muss der Testansatz die Erstellung von unverwechselbaren Datensätzen für alle Schnittstellen erforderlich machen, um Schlüsselbereiche, die einen Einfluss auf eine bestimmte Eigenschaft über Schnittstellen hinweg haben, zu bereinigen. Separate Datensätze sollten für jede Umgebung erstellt werden, da die verfügbare Backend Datenbank für eine Umgebung über eine andere abgespeckte Version aus der Produktion verfügt. Während das getan wird, muss die Leistung des Geräts mit Werkzeugen wie Little Eye oder Xcode gemessen werden.

Verständnis für Nutzungsverhalten

Die hohe Fragmentierung bei den Geräten und Plattformen ist eine weitere Herausforderung, der QA normalerweise gegenübersteht. Der Versuch, alle Kombinationen zu testen, kann oft sehr kostspielig und auch ein vergebliches Unterfangen sein, da im Mobilbereich regelmäßig neue Kombinationen auf den Markt kommen. Tests auf verschiedenen Plattformen, wie iOS, Android und Windows unter Berücksichtigung verschiedener Versionen, wie iOS 5.x, 6.x, 7.x, Android 4.4, 5.0 und eine Reihe von Geräten von Herstellern, wie Nokia, Samsung, HTC oder Apple ist praktisch unmöglich.

Anstatt die monumentale Aufgabe des Testens in einer fragmentierten Art und Weise anzugehen, sollte ein subjektiver Ansatz gewählt werden. Es sollten nur die Plattformen oder Geräte berücksichtigt werden, die in einer bestimmten Region die höchste Marktdurchdringung aufweisen. In den USA und Kanada könnte der Fokus zum Beispiel auf hochklassigen iOS/ Android Telefonen liegen, während für Brasilien und andere Länder in Lateinamerika das Testen der Anwendung für einfachere Android Telefone infrage kommen könnte. Für optimales Testen können Erfahrungen durch die Nutzung von Daten von Google Analytics und Dynatrace usw. gewonnen werden. Holen Sie sich Input von Ihrem Marktforschungs-Team und erfassen Sie, was Ihre Anwender mit der Anwendung machen. Beispielsweise nutzen 70% - 80% der Anwender die Privatkundenanwendung nur zur Überprüfung Ihres Kontostands und für einfache Transaktionen, wie die Bezahlung von Rechnungen oder Überweisungen. Verschaffen Sie sich Klarheit über die Mentalität des Kunden und dessen Nutzungsverhalten und priorisieren Sie Ihre Testaktivitäten dementsprechend.

Abschließend: Die Teams, welche die Apps testen, müssen bestens informiert sein und sich in eine strategische und technisch kreative Richtung bewegen. Somit ist beim Arbeiten in einer speziellen Domäne, wie Mobile-Banking-Applications, der Extraaufwand, der über das Standardtestverhalten hinausgeht, ein wesentlicher Bestandteil des Erfahrungsgewinns und der Weiterentwicklung eines jeden Testers.