Das Team testet die Anwendung einen ganzen Sprint lang, veröffentlicht eine Version – und eine Woche später häufen sich die Beschwerden beim Support: „In meiner Stadt ist der Preis anders“, „Push ist nicht angekommen“, „Ich kann nicht mit Karte bezahlen“. Der Grund ist fast immer derselbe: Alle Tests wurden von einer einzigen Unternehmens-IP durchgeführt, während echte Nutzer aus anderen Regionen, Netzwerken und von anderen Anbietern zugreifen. In diesem Artikel werden wir 7 konkrete QA-Szenarien untersuchen, die physisch nicht ohne Änderung der IP-Adresse überprüft werden können, und zeigen, wie man die Testinfrastruktur mit Proxys einrichtet.
Warum Büro-IP eine blinde Zone für QA ist
Die meisten mobilen Anwendungen treffen heute Entscheidungen basierend auf der IP-Adresse: Sie bestimmen das Land des Nutzers, die Sprache der Benutzeroberfläche, die Währung, die verfügbaren Zahlungsmethoden, das Funktionsset und sogar den Preis des Abonnements. Wenn die gesamte QA-Abteilung aus einem Büro mit einer statischen IP-Adresse des Rechenzentrums oder des Unternehmensnetzwerks testet, erhält die Anwendung immer die gleiche Antwort vom Backend – als ob alle Tester an einem Punkt der Welt wären.
Infolgedessen werden Fehler, die von Geolokalisierung, Zeitzonen, Netzbetreibern oder Verbindungstypen abhängen, einfach nicht auf der Testumgebung reproduziert. Sie treten erst in der Produktion auf – wenn ein Nutzer aus Kasachstan Preise in Rubel sieht, ein deutscher Nutzer keine Push-Benachrichtigung aufgrund der GCM-Sperre in seinem Netzwerk erhält, und ein indonesischer Kunde nicht mit Karte bezahlen kann, weil der Zahlungsanbieter für seine Region nicht angeschlossen ist. Die Behebung eines solchen Fehlers nach der Veröffentlichung ist um ein Vielfaches teurer, als ihn in der QA-Phase zu erfassen.
Die Lösung besteht darin, die tatsächliche geografische und netztechnische Vielfalt der Nutzer noch vor der Veröffentlichung zu emulieren. Dazu verwenden QA-Ingenieure zunehmend Proxy-Server: Sie ermöglichen es, das Testgerät oder den Emulator in jedes Land, jede Stadt oder sogar zu jedem Netzbetreiber zu „versetzen“, ohne physisch dorthin reisen oder Dutzende von SIM-Karten kaufen zu müssen.
Szenario 1: Geoinhalt und regionale Preise
Die meisten Anwendungen mit Abonnements (Streaming, Fitness, Bildung) zeigen unterschiedliche Preise in verschiedenen Ländern – dies wird als Geopricing bezeichnet. Wenn QA das Abonnement nur mit einer lokalen IP überprüft, ist es unmöglich sicherzustellen, dass der Preis für einen Nutzer aus der Türkei, Brasilien oder Indien korrekt angezeigt wird, in der richtigen Währung und mit der richtigen Rundung.
Dasselbe Problem gilt für Inhaltskataloge: Die Bibliothek von Filmen, Produkten oder Angeboten ist oft regional. Man muss physisch in dem entsprechenden Land „erscheinen“, um denselben Bildschirm zu sehen, den der echte Nutzer sieht. Für solche Überprüfungen sind residential Proxys praktisch – sie geben die IP von echten Haushaltsnutzern eines bestimmten Landes aus, und das Backend der Anwendung betrachtet die Anfrage als normalen organischen Traffic und nicht als Anfrage aus einem Rechenzentrum.
Praktische Überprüfung: Wir führen das Abonnementsszenario in 8-10 Schlüsselregionen (USA, Deutschland, Brasilien, Indien, Türkei, Japan, Nigeria, VAE) durch, machen Screenshots von Preis und Währung und vergleichen sie mit der Preisliste des Produkts. Dies schließt einen Großteil der Beschwerden wie „Warum habe ich einen anderen Preis?“ aus.
Szenario 2: Geoblockierungen und Zugangsbeschränkungen
Fintech-Anwendungen, Streaming-Dienste und einige Spiele blockieren den Zugang aus bestimmten Ländern aus rechtlichen oder lizenztechnischen Gründen. QA muss sicherstellen, dass die Anwendung nicht nur dort funktioniert, wo sie sollte, sondern auch, dass sie korrekt (und nicht mit einem Absturz) den Zugang verweigert, wo sie nicht sollte.
Typischer Fehler: Anstelle eines ordentlichen Bildschirms „Dienst in Ihrer Region nicht verfügbar“ sieht der Nutzer einen weißen Bildschirm oder einen endlosen Ladebildschirm – weil die Entwickler nur den Happy Path aus dem erlaubten Land getestet haben. Die Überprüfung von Geoblockierungen erfordert eine konsistente Verbindung aus mehreren verbotenen Jurisdiktionen, was mit echten SIM-Karten und Dienstreisen unrealistisch ist, während es über Proxys 10-15 Minuten pro Land dauert.
Für dieses Szenario sind Proxys mit genauer Geolokalisierung auf Stadt- oder Regionsebene geeignet – es ist wichtig, nicht nur „Deutschland insgesamt“ zu überprüfen, sondern spezifische Bundesländer, wenn die Lizenz auf eine Region innerhalb des Landes beschränkt ist.
Szenario 3: A/B-Tests und schrittweise Rollouts nach Ländern
Feature-Flags und schrittweise Rollouts sind fast immer an die Geolokalisierung gebunden: Eine neue Funktion wird zuerst in Kanada aktiviert, eine Woche später in Australien, dann überall. Wenn das QA-Team physisch in einem Land ist, kann es die neue Version grundsätzlich nicht früher sehen als die anderen Regionen, bis das Flag auch zu ihm gelangt.
Um eine Funktion vor dem globalen Release zu testen, muss die Geolokalisierung auf das Land der ersten Rollout-Welle geändert werden. Dies ist eine der häufigsten Aufgaben, die Proxys in Verbindung mit Anti-Detect-Browsern oder Geräteemulatoren lösen – wir ändern die IP auf das benötigte Land, starten die Anwendungssitzung neu, sehen die Funktion früher als andere Nutzer und haben die Möglichkeit, Fehler zu finden, bevor das Flag 100% der Nutzer erreicht.
Ein wichtiger Punkt: Für A/B-Tests ist eine stabile „Registrierung“ der IP für den gesamten Testzyklus erforderlich – die Sitzung sollte zwischen den Anfragen nicht zwischen den Ländern wechseln, da sonst das Backend die Bedingungen des Experiments verwechseln und entweder die Kontrollgruppe oder die Testgruppe anzeigen kann.
Szenario 4: Lokalisierung und Push-Benachrichtigungen
Der Text der Push-Benachrichtigung, der Zeitpunkt ihrer Zustellung und sogar die Tatsache der Zustellung hängen oft von der Geolokalisierung des Geräts ab. In einigen Ländern arbeiten Push-Anbieter (Firebase, APNs, lokale SMS-Gateways) mit Verzögerungen oder über alternative Routen – und das, was im Testumfeld aus dem Büro in Moskau perfekt zugestellt wird, erreicht möglicherweise den Nutzer in Indonesien nicht aufgrund der Sperrung bestimmter Push-Server durch den lokalen Anbieter.
Auch die Lokalisierung der Benutzeroberfläche wird oft durch die IP und nicht nur durch die Systemsprache ausgelöst: Ein Nutzer mit englischer Sprache auf dem Telefon, aber einer IP aus Frankreich, kann eine gemischte Benutzeroberfläche sehen – Überschriften auf Französisch, Schaltflächen auf Englisch. Solche Fehler sind zu 100% unsichtbar, wenn die gesamte QA aus einer Geozone testet.
Empfohlener Prozess: Wir nehmen 5-7 Lokalisierungen aus den priorisierten Märkten des Produkts, verbinden uns über Proxys mit der entsprechenden IP, ändern die Systemsprache auf dem Gerät/Emulator und dokumentieren, welchen Text und welches Datums-/Zahlenformat die Anwendung anzeigt. Diskrepanzen zwischen der IP-Land und der Systemsprache sind ein separater obligatorischer Fall, der oft vergessen wird.
Szenario 5: Zahlungsmethoden und Betrugssysteme
Die Auswahl der verfügbaren Zahlungsmethoden in einer mobilen Anwendung hängt fast immer vom Land ab: In einer Region sind Kartenzahlungen und Apple Pay verfügbar, in einer anderen nur lokale Wallets (Mercado Pago, Boleto, UPI, QIWI), in einer dritten Zahlungen über den Netzbetreiber. Wenn QA sich nicht aus dem benötigten Land verbinden kann, bleibt die Hälfte der Zahlungsszenarien bis zur Produktion ungetestet, wo der Preis eines Fehlers verlorene Einnahmen und Beschwerden beim Support sind.
Ein separates Problem sind die Betrugssysteme der Zahlungsanbieter. Sie bewerten das Risiko einer Transaktion unter anderem anhand der IP: Eine Anfrage von der IP eines Rechenzentrums erhält fast sicher eine Ablehnung oder eine zusätzliche 3D-Secure-Prüfung, selbst wenn die Karte absolut gültig ist. Dies verzerrt die Testergebnisse: QA sieht eine Zahlungsablehnung und meldet einen Fehler an die Entwickler, obwohl das Problem nicht im Code liegt, sondern darin, dass die Test-IP für die Betrugserkennung verdächtig aussieht.
Für Zahlungsszenarien ist es besser, residential Proxys oder mobile Proxys zu verwenden – sie erscheinen wie normaler Traffic eines echten Nutzers und lösen keine unnötigen Auslösungen der Betrugssysteme aus, was ein ehrlicheres Bild des Verhaltens des Zahlungsflusses ergibt.
Szenario 6: Verhalten in mobilen Netzwerken der Anbieter
Eine Anwendung, die im Büro-WLAN mit 200 Mbit/s hervorragend funktioniert, kann sich in einem mobilen 3G/4G-Netz mit instabiler Verbindung, NAT-Proxy des Anbieters und hoher Latenz völlig anders verhalten. Timeouts bei Anfragen, Wiederholungsversuche, Verschlechterung der Video-/Audioqualität, Offline-Modus – all dies muss genau unter Bedingungen überprüft werden, die dem mobilen Internet ähnlich sind und nicht im stabilen Büro-Netzwerk.
Eine zusätzliche Schwierigkeit: Einige Netzbetreiber verwenden eigene Proxys und CGNAT, wodurch der Server nicht die echte IP des Nutzers sieht, sondern die gemeinsame IP des Anbieters, über die gleichzeitig Tausende von Abonnenten verbunden sind. Dies beeinflusst das Rate Limiting und die Geolokalisierung nach IP – die Anwendung kann „denken“, dass der Nutzer sich in einer anderen Stadt befindet, als er tatsächlich ist.
Um ein solches Verhalten zu reproduzieren, sind mobile Proxys erforderlich, die über echte SIM-Karten der benötigten Länder ins Internet gehen – dies gibt ein genaues Bild von NAT, Latenzen und Geschwindigkeiten, das man nicht mit einer normalen Rechenzentrums-IP erhalten kann.
Szenario 7: Rate Limiting und Schutz vor Bots
Viele Backend-APIs mobiler Anwendungen beschränken die Anzahl der Anfragen von einer IP (Rate Limiting) und verwenden Schutzmaßnahmen gegen Bots, ähnlich wie Captchas oder Verhaltensanalysen. Wenn das QA-Team automatisierte Tests von einer Unternehmens-IP aus durchführt, beginnt der Server nach einer gewissen Zeit, mit Fehlern 429 zu antworten oder die Anfragen ganz zu blockieren – und die Tests fallen nicht aufgrund eines Fehlers in der Anwendung aus, sondern weil das Backend den Testtraffic als Angriff interpretiert hat.
Dies ist besonders relevant für Last- und Regressionstests, bei denen in kurzer Zeit Hunderte von ähnlichen Anfragen (Registrierung, Login, Hinzufügen zum Warenkorb) ausgeführt werden müssen. Die Verteilung der Anfragen über verschiedene IPs mithilfe eines Proxy-Pools ermöglicht es, die API ehrlich zu belasten, ohne die Ergebnisse aufgrund von Auslösungen der Betrugsschutzmaßnahmen zu verzerren.
Für solches massives automatisiertes Testen ist es oft vorteilhafter, Rechenzentrums-Proxys zu verwenden – sie sind schneller und günstiger bei großen Anfragevolumina, und die Geolokalisierung ist in diesem Szenario nicht so kritisch wie Geschwindigkeit und Stabilität der Verbindung.
Werkzeuge und Proxy-Einstellungen für QA
Für manuelle QA auf Emulatoren (Android Studio Emulator, Xcode Simulator) wird der Proxy über die Systemeinstellungen des Emulators konfiguriert: Sie geben die IP und den Port des Proxy-Servers an, sowie Benutzername und Passwort, falls eine Authentifizierung verwendet wird. Für echte Geräte sind ähnliche Einstellungen über die WLAN-Verbindung unter „Erweiterte Einstellungen → Proxy → Manuell“ verfügbar.
Für das Abfangen und Analysieren des Traffics zwischen der Anwendung und dem Backend verwenden QA-Ingenieure Charles Proxy oder Proxyman – beide Tools ermöglichen es, den Traffic der Anwendung über einen externen Proxy zu leiten und gleichzeitig alle HTTP/HTTPS-Anfragen, Geolokalisierungsheader und Serverantworten zu sehen. Dies ist praktisch für die Diagnose: Man sieht sofort, welche IP und welches Land das Backend zum Zeitpunkt der Anfrage „sieht“.
Für automatisierte Tests über Appium oder Espresso wird der Proxy in den gewünschten Fähigkeiten der Sitzung oder über die Systemeinstellungen des Geräts vor dem Start des Testsets angegeben. Cloud-Plattformen für das Testen mobiler Anwendungen (BrowserStack, Sauce Labs) unterstützen ebenfalls die Verbindung von benutzerdefinierten Proxys, was es ermöglicht, dass dasselbe automatisierte Testszenario aus verschiedenen Ländern ohne physische Geräte an jedem Punkt der Welt durchgeführt wird.
Wenn im Team eine Webversion der Anwendung vorhanden ist oder mehrere Konten mit unterschiedlicher Geolokalisierung parallel getestet werden müssen, ist es praktisch, Anti-Detect-Browser (Dolphin Anty, AdsPower, Multilogin) zu verwenden – jedes Profil wird an einen separaten Proxy gebunden, und der QA-Ingenieur kann 5-10 Sitzungen aus verschiedenen Ländern gleichzeitig offen halten, ohne Verwirrung bei Cookies und Cache.
Welchen Proxy-Typ für jedes Szenario wählen
| QA-Szenario | Empfohlener Proxy-Typ | Warum |
|---|---|---|
| Geopreise und Inhalte | Residential | Erscheinen wie der Traffic eines normalen Nutzers, lösen keinen Anti-Bot-Schutz aus |
| Geoblockierungen | Residential | Genau Geolokalisierung bis zur Stadt/Region |
| A/B-Tests und Rollouts | Residential / Rechenzentrum | Stabile Sitzung für den gesamten Testzyklus |
| Push und Lokalisierung | Mobile | Reale Bedingungen der Zustellung über Anbieter reproduzieren |
| Zahlungen und Betrug | Residential / Mobile | Geringes Risiko von Fehlalarmen der Betrugssysteme |
| Mobile Netzwerke der Anbieter | Mobile | Echte SIM-Karten der Anbieter, genaue Emulation von NAT und Latenzen |
| Rate Limiting / Lasttests | Rechenzentrums | Hohe Geschwindigkeit und niedrige Kosten bei großen Anfragevolumina |
Checkliste vor der Veröffentlichung
Bevor Sie die Version in die Produktion entlassen, gehen Sie eine kurze Liste von Überprüfungen durch, die mit Geolokalisierung und Netzwerk zu tun haben – dies schließt die meisten der oben beschriebenen Fehler aus:
- Preise und Währung des Abonnements wurden in mindestens 5 Schlüsselregionen des Produkts überprüft
- Die korrekte Anzeige des Geoblockierungsbildschirms in verbotenen Ländern wurde überprüft
- Das Feature-Flag wurde im Land der ersten Rollout-Welle vor dem globalen Release getestet
- Push-Benachrichtigungen wurden mit IP und Systemsprache aus verschiedenen Länder-Kombinationen überprüft
- Verfügbare Zahlungsmethoden wurden für jede Schlüsselregion separat überprüft
- Der Zahlungsfluss wurde ohne Fehlalarme der Betrugssysteme getestet
- Die Anwendung wurde unter Bedingungen eines mobilen Netzwerks (3G/4G) getestet und nicht nur im WLAN
- Automatisierte Tests fallen nicht aufgrund von Rate Limiting bei paralleler Ausführung von einer IP aus
Fazit
Eine mobile Anwendung lebt gleichzeitig in Dutzenden von Ländern, Netzwerken und Zahlungssystemen, während das QA-Team physisch in einem Büro mit einer IP sitzt. Genau dieser Bruch zwischen der realen Zielgruppe und den Testbedingungen erzeugt die meisten „unverständlichen“ Fehler, die bis zur Produktion gelangen. Die sieben oben genannten Szenarien – Geopreise, Geoblockierungen, A/B-Rollouts, Push und Lokalisierung, Zahlungen, mobile Netzwerke der Anbieter und Rate Limiting – decken den Großteil solcher Risiken ab.
Wenn Ihr Team eine Anwendung testet, die mit regionalen Inhalten, Preisen oder Zahlungen arbeitet, ist es sinnvoll, in den Test-Stack residential Proxys zur Simulation echter Nutzer einzubinden, und für Szenarien mit mobiler Verbindung und Push-Zustellung mobile Proxys mit Bindung an bestimmte Anbieter zu verwenden. Dies ermöglicht es, kritische Fehler in der QA-Phase zu finden und nicht erst nach Beschwerden von Nutzern in den Stores.