Die meisten Leitfäden für Lokalisierungstests geben Ihnen eine Phasenliste und nennen das einen fertigen Tag. Planen, entwerfen, ausführen, wiederholen. Das Problem ist, dass Sie nach dem Lesen immer noch keine Ahnung haben, wie ein tatsächlicher Testfall aussieht, welchen Fehler man bei Deutsch versus Arabisch versus Japanisch erwarten kann, oder ob Ihre Abdeckung ausreicht, um auszuliefern.
Dieser Walkthrough macht das Gegenteil. Wir nehmen ein Feature, einen Registrierungs-Flow, und führen ihn in fünf konkreten Schritten in drei Ziel-Locales durch. Deutsch für Texterweiterung und Telefonvalidierung. Arabisch für Rechts-nach-links-Layout und Zeitzonenbehandlung. Japanisch für Zeichenverarbeitung und Datumsformate. Sie sehen die Testfälle, die Fehler abfangen, die Bug-Tickets, die sie beheben, und die Regressionen, die die Fixes in benachbarten Locales erzeugen.
Laut Capital One Shopping wird der Markt für grenzüberschreitenden E-Commerce voraussichtlich im Jahr 2025 ein Volumen von rund 1,21 Billionen US-Dollar und bis 2030 von 1,84 Billionen US-Dollar erreichen. Untersuchungen von VisionGroup, die sich auf CSA Research berufen, zeigen, dass 76 % der Online-Käufer Produkte bevorzugen, deren Informationen in ihrer Muttersprache verfügbar sind. Funktioniert die Anmeldung in einem neuen Land nicht, gehen potenzielle Kunden ums Geld. Aus diesem Grund hat sich das Lokalisierungstesting von einem netten Extra zu einem unverzichtbaren Kontrollpunkt vor der Veröffentlichung für jedes Team entwickelt, das über seinen Heimatmarkt hinaus expandiert.
Der Registrierungs-Flow, den wir testen, und warum er jeden häufigen Fehler aufdeckt
Das Feature ist bewusst gewöhnlich. Ein E-Mail-Feld, ein Passwortfeld mit Stärkemesser, ein vollständiges Namensfeld, eine Telefonnummer mit Ländervorwahl, ein Geburtsdatum-Picker, ein Länder-Dropdown, ein Marketing-Einwilligungs-Kontrollkästchen, ein Absende-Button, ein „Bestätigen Sie Ihre E-Mail innerhalb von 24 Stunden“-Countdown und eine serverseitig gesendete Willkommens-E-Mail.
Jedes Produkt hat eines davon. Jedes berührt Eingabevalidierung, Layout, Datums- und Zahlenformatierung, Zeichenkodierung, Zeitzonenmathematik und Mikrokopie. Das macht es zum perfekten Feature, um zu zeigen, wie man Lokalisierungstests durchführt von Anfang bis Ende, denn jede Kategorie, in der Lokalisierung bricht, lebt auf demselben Bildschirm.
Bevor locale-spezifische Arbeit beginnt, richten wir die Umgebung korrekt ein. Locale auf OS-Ebene umgeschaltet, nicht nur in der App. Browser-Sprach-Header, die dem Locale entsprechen. Native Schriftarten für jedes Schriftsystem installiert. Echte Geräte für mindestens ein Android, ein iOS und zwei Desktop-Browser pro Locale. Das Überspringen dieser Einrichtung ist der häufigste Grund, warum Teams Layout-Fehler in der Produktion finden, die ihre Staging-Umgebung still versteckt hatte.
Schritt 1: Die Locale-Matrix, die Märkte den ihnen bekannten Fehlern zuordnet
Der generische Rat lautet „definieren Sie Ihren Umfang“. Das sagt Ihnen nichts. Die nützliche Übung besteht darin, jede Locale den Fehlerkategorien zuzuordnen, für die sie bekannt ist, bevor Sie einen einzigen Testfall schreiben. Das ist es, was wir bei jedem Lokalisierungs-Engagement tun, und es verkürzt die Testdesign-Zeit um etwa ein Drittel.
Für unseren Walkthrough sieht die Matrix so aus:
Deutsch (Deutschland)
Texterweiterung, Telefonnummernvalidierung
Label des Einwilligungs-Kontrollkästchens, Telefoneingabe, Absende-Button
Arabisch (Saudi-Arabien)
Rechts-nach-links-Spiegelung, Zeitzonenbehandlung
Telefon-Ländercode, Stärkemesser, E-Mail-Countdown
Japanisch (Japan)
Doppelbyte-Eingabe, Datumsformat-Konventionen
Vollständiges Namensfeld, Geburtsdatum-Picker, Länder-Dropdown
Die Matrix ist das Rückgrat jedes späteren Schritts. Die deutsche Spalte sagt dem Tester, sich auf Zeilenumbruch und Zahlenmuster zu konzentrieren. Die arabische Spalte sagt ihm, sich auf Richtung und serverseitige Zeitmathematik zu konzentrieren. Die japanische Spalte sagt ihm, sich auf Eingabeakzeptanz und Datumsreihenfolge zu konzentrieren. Man hört auf, Aufwand für die Verifizierung von Dingen zu verschwenden, die in diesem Locale nie kaputt gehen würden.
Schritt 2: Gegen Risiken geschriebene Testfälle mit den genau abgefangenen Fehlern
Der häufigste Fehler, den wir in Kunden-Testplänen sehen, ist ein generischer Fall pro Locale, geschrieben als „verifizieren Sie, dass das Formular in der Zielsprache abgesendet wird“. Das fängt nichts. Ein korrekter Fall nennt das Locale, das Feld, das Risiko und das erwartete Ergebnis. Im Folgenden sind sechs echte Testfälle, zwei pro Locale, gegen die Felder mit höchstem Risiko geschrieben und den Fehler, den jeder aufgedeckt hat. Das ist, wie ein nützliches Lokalisierungstest-Beispiel in der Praxis aussieht.
Deutscher Testfall 1 — Texterweiterung des Kontrollkästchens. Überprüfen, dass das Label des Marketing-Einwilligungs-Kontrollkästchens den Absende-Button nicht außerhalb des sichtbaren Viewports auf einem 375px-mobilen Breakpoint drückt, wenn das Formular auf Deutsch angezeigt wird.
Erwartet: das Label bricht auf maximal zwei Zeilen um, der Absende-Button bleibt vollständig anklickbar.
Gefundener Fehler: das übersetzte Einwilligungs-Label brach auf dem iPhone SE auf vier Zeilen um und drückte den Absende-Button unter die Sichtlinie.
Deutscher Testfall 2 — Telefonnummernvalidierung. Überprüfen, dass die Telefoneingabe eine gültige deutsche Mobiltelefonnummer (11 Ziffern einschließlich des Ländercodes +49, z. B. +49 151 23456789) akzeptiert und nur wirklich ungültige Muster ablehnt.
Erwartet: gültige deutsche Nummern bestehen, ungültige scheitern mit einer locale-gerechten Fehlermeldung.
Gefundener Fehler: der Validator war fest auf 10 Ziffern im US-Format kodiert und lehnte jede gültige deutsche Nummer ab. Die Fehlermeldung lautete „Telefonnummer muss 10 Ziffern haben“, was in jedem Markt außerhalb Nordamerikas bedeutungslos ist.
Arabischer Testfall 1 — Rechts-nach-links-Layout-Spiegelung. Überprüfen, dass das gesamte Registrierungsformular gespiegelt wird, wenn das Locale auf Arabisch gesetzt ist, einschließlich der Position des Ländercodes bei der Telefoneingabe, der Symbolreihenfolge bei Fehlerzuständen und der Füllrichtung des Passwort-Stärkemessers.
Erwartet: vollständige Rechts-nach-links-Spiegelung über jedes Element.
Gefundener Fehler: das Formular spiegelte korrekt, aber der Passwort-Stärkemesser füllte sich immer noch von links nach rechts. Ein starkes arabisches Passwort erzeugte ein visuelles Signal, das von Muttersprachlern als „schwach“ gelesen wurde, weil sie den Balken in der entgegengesetzten Richtung abtasten.
Arabischer Testfall 2 — Zeitzonenbehandlung beim Verifizierungs-Countdown. Überprüfen, dass der „Bestätigen Sie Ihre E-Mail innerhalb von 24 Stunden“-Countdown die korrekte lokale Ablaufzeit für einen Nutzer in Saudi-Arabien (UTC+3, keine Sommerzeit) anzeigt und dass der Link nicht vorzeitig abläuft.
Erwartet: der Countdown zeigt die Ablaufzeit in Riad-Ortszeit umgerechnet, und der Link bleibt für volle 24 Stunden ab der serverseitigen Ausstellung gültig.
Gefundener Fehler: der Countdown wurde in UTC gerendert, während die E-Mail-Betreffzeile eine lokale Zeit angab. Saudi-Nutzer sahen eine Drei-Stunden-Diskrepanz und einige klickten auf Links, die der Server aufgrund eines separaten Caching-Fehlers als bereits abgelaufen behandelte.
Japanischer Testfall 1 — Doppelbyte-Zeicheneingabe. Überprüfen, dass das vollständige Namensfeld japanische Doppelbyte-Zeichen akzeptiert, sie als UTF-8 speichert und sie korrekt in der Erfolgsmeldung anzeigt.
Erwartet: die Eingabe akzeptiert bis zu 20 Doppelbyte-Zeichen, die Datenbank speichert sie ohne Korruption, und die Erfolgsmeldung rendert den japanischen Namen.
Gefundener Fehler: die Eingabe akzeptierte die Zeichen auf UI-Ebene, aber der Validierungs-Regex erforderte nur lateinische Buchstaben und blockierte die Übermittlung mit einem generischen „Ungültiger Name“-Fehler. Jede japanische Registrierung wäre bei der Übermittlung gescheitert.
Japanischer Testfall 2 — Datumsformat im Geburtsdatum-Picker. Überprüfen, dass der Geburtsdatum-Picker Daten in der Reihenfolge JJJJ/MM/TT für das japanische Locale anzeigt und dass das Länder-Dropdown nach japanischer Lesereihenfolge und nicht nach englischem Alphabet sortiert ist.
Erwartet: der Picker liest JJJJ/MM/TT, das Dropdown sortiert Länder nach ihren japanischen Namen (Doitsu, nicht Germany).
Gefundener Fehler: der Picker renderte MM/TT/JJJJ unabhängig vom Locale, was dazu führte, dass Nutzer ihr Geburtsjahr im Tagesfeld eingaben und die Validierung scheiterte. Das Länder-Dropdown war nach englischen Namen sortiert, sodass japanische Nutzer nach „Germany“ statt nach ドイツ suchen mussten.
Jeder Fall ist ein Absatz. Jeder nennt die Risikokategorie, das Feld und das erwartete Verhalten. Das ist die Form, die jeder Testfall in Ihrer Suite annehmen soll.
Schritt 3: Ausführung auf echten Geräten und wie die Bug-Tickets tatsächlich aussahen
Ein in der Lokalisierung gefundener Fehler ist nur nützlich, wenn der Entwickler ohne Rätselraten handeln kann. Drei Dinge verwandeln ein vages Ticket in ein umsetzbares: die Quellzeichenkette und die übersetzte Zeichenkette nebeneinander, vollständige Umgebungs-Metadaten mit Screenshots für jeden Zustand und ein Tag, ob der Fehler Layout, Eingabe, Format, Zeitzone oder Inhalt ist.
Für den deutschen Telefon-Validator enthielt das Ticket die abgelehnte Nummer, das Regex-Muster aus der Codebasis, die deutschen Validierungsregeln und einen Screenshot der Fehlermeldung. Kritischer Schweregrad, da es jede deutsche Registrierung blockierte.
Für den arabischen Zeitzone-Fehler enthielt das Ticket eine Aufzeichnung des Countdowns, der in UTC gerendert wurde, die E-Mail-Betreffzeile, die die Ortszeit anzeigte, und ein serverseitiges Protokoll des Link-Ablaufzeitstempels. Hoher Schweregrad, da Nutzer den Zugriff auf einen Flow verloren, den sie bereits begonnen hatten.
Für den japanischen Datums-Picker enthielt das Ticket den Picker-Screenshot in MM/TT/JJJJ-Reihenfolge, die Locale-Einstellung, die JJJJ/MM/TT hätte auslösen sollen, und ein separates Ticket für die Sortierreihenfolge des Länder-Dropdowns. Um Fehler dieser Größenordnung aufzuspüren, ist es notwendig, dass ein Mensch Sitzungen auf realen Geräten durchführt. Dies ist das Rückgrat des manuellen Multi-Locale-Testprozesses von QAwerk und der Grund, warum eine rein automatisierte Abdeckung eine ganze Klasse von Lokalisierungsproblemen nicht erfasst.
Schritt 4: Fixes, Nachtests und die Regressionen, die in benachbarten Locales auftauchen
Die interessante Lokalisierungsarbeit passiert, nachdem der erste Fix landet, denn jeder Fix hat einen Wirkungsradius über Locales hinweg, den niemand im ursprünglichen Ticket markiert hatte.
Der Fix des deutschen Telefon-Validators ersetzte die fest kodierte 10-Ziffern-Regel durch eine locale-bewusste Bibliothek, die Validierungsmuster pro Ländercode lädt. Nachtests auf Deutsch bestätigten den Fix. Nachtests in Frankreich, Italien und Großbritannien bestätigten den Fix. Nachtests in Brasilien ergaben, dass die Bibliotheksversion das brasilianische Nummernformat-Update 2024 nicht enthielt, sodass gültige brasilianische Mobilnummern weiterhin scheiterten.
Der arabische Zeitzone-Fix verlagerte die Countdown-Berechnung zum clientseitigen Rendern unter Verwendung der lokalen Zeitzone des Nutzers. Nachtests in Riad bestätigten die korrekte Anzeige. Nachtests in Tokio, das ebenfalls UTC+9 ohne Sommerzeit ist, bestätigten den Fix. Nachtests in Berlin während einer Sommerzeitumstellung ergaben, dass der Countdown beim Uhrzeitwechsel um eine Stunde sprang, weil die clientseitige Bibliothek den Offset beim Laden des Formulars zwischengespeichert hatte.
Der japanische Datums-Picker-Fix führte eine locale-bewusste Datumsformat-Komponente ein. Nachtests in Japan bestätigten JJJJ/MM/TT. Nachtests in China und Korea, die ebenfalls JJJJ/MM/TT verwenden, bestätigten den Fix. Nachtests im Iran ergaben, dass der Picker den persischen Kalender nicht unterstützte, was eine separate Lokalisierungsanforderung jenseits der Format-Neuordnung ist.
Dieses Muster ist genau das, was wir auf den Keystone-Studienportalen ausführen, wo acht Vertikalen in über 40 Sprachen lokalisiert sind und eine einzige Format- oder Validator-Änderung über den gesamten Locale-Satz hinweg nachgetestet werden muss, bevor sie ausgeliefert werden kann.
Schritt 5: Wo Automatisierung sich lohnt und wo Manuell noch gewinnt
Rückblickend auf die sechs Fehler, die wir abgefangen haben, hätte die Automatisierung die meisten davon gefunden. Zu wissen, welche und welche sie verpasst hätte, ist der Kern davon, wie man Lokalisierungstests durchführt im großen Maßstab, ohne das QA-Budget zu verbrennen.
Die Automatisierung hätte den deutschen Telefon-Validator, den japanischen Regex und den japanischen Datums-Picker abgefangen. Parametrisierte Funktionstests mit locale-spezifischen Payloads scheitern bei diesen laut. Die Automatisierung hätte den deutschen Kontrollkästchen-Überlauf mit einem visuellen Screenshot-Diff abgefangen. Die Automatisierung hätte die arabische Stärkemesser-Richtung oder die arabische Zeitzone-Diskrepanz beim Countdown nicht abgefangen, weil beide ohne Fehler gerendert wurden und nur ein Mensch, der von rechts nach links liest oder in UTC+3 lebt, sie als falsch registrierte.
Dieses Verhältnis gilt für die meisten Lokalisierungsprojekte, die wir durchführen. Etwa zwei Drittel der Fehler landen im automatisierbaren Bereich. Das verbleibende Drittel deckt kulturelle Angemessenheit, Zeitzonenmathematik-Randfälle, Übersetzungston, bidirektionale Inhalte und die Art von visuellen Urteilsaufrufen ab, die die Automatisierung nicht treffen kann. Der Fehler, den Teams machen, ist alles in einen Bereich zu stecken. Entweder testen sie jedes Locale bei jedem Release manuell nach und brennen das Team aus, oder sie vertrauen darauf, dass die Automatisierung kulturelle und zeitliche Probleme markiert, für deren Erkennung sie nie gebaut wurde.
Ein sauberes Beispiel für dieses Gleichgewicht ist der Escuela-Coaching-Plattform-Launch, bei dem wir die englische Lokalisierung eines spanischstämmigen Produkts in einem einmonatigen Zeitrahmen verifizierten. Die manuelle Überprüfung fand Übersetzungspräzisions-Probleme bei Button-Texten, Menüs, Fehlermeldungen und Informationsinhalten, die kein automatisierter Durchlauf ans Licht gebracht hätte.
Ein sofort einsetzbares Testfall-Set für Ihren eigenen Registrierungs-Flow
Der obige Walkthrough verwendete sechs Testfälle zur Illustration. Ein echter Registrierungs-Flow benötigt mehr Abdeckung über jede Kategorie, die Lokalisierung berührt: Texterweiterung, Rechts-nach-links-Layout, Zeichenverarbeitung, Datums- und Zahlenformate, Währung, Telefonvalidierung, Adressformate, Zeitzonen, Geschäftszeiten und lokale Zahlungsmethoden, wenn sich Ihr Flow bis zum Checkout erstreckt.
Wir verwenden eine Vorlage von 18 Testfällen bei der Ausführung auf Kundenprojekten, sechs pro Locale, die jede obige Kategorie abdecken. Jeder Fall hat eine feste Struktur: Fallname, Locale, zu testendes Feld, Risikokategorie, Vorbedingungen, Schritte, erwartetes Ergebnis, Schweregrad bei Scheitern. Die Vorlage ist locale-unabhängig, sodass das Hinzufügen eines neuen Marktes wie Polnisch, Türkisch oder Hebräisch eine Frage des Austauschens von Datensätzen ist und nicht des Neuschreibens der Suite. Melden Sie sich, wenn Sie die Vorlage an Ihr Produkt angepasst haben möchten.
Das Fünf-Schritte-Muster, auf jedes Locale angewendet, das Sie als Nächstes hinzufügen
Das Muster bleibt gleich, während Ihre Marktliste wächst. Identifizieren Sie die Fehlerkategorien, für die das Locale bekannt ist. Schreiben Sie Testfälle gegen jede Kategorie, nicht gegen das Formular generisch. Führen Sie auf echten Geräten aus und protokollieren Sie Fehler mit Quell-, Übersetzungs-, Umgebungs- und Zeitzonenkontext nebeneinander. Testen Sie die benachbarten Locales nach jedem Fix nach, denn die Regression taucht selten dort auf, wo Sie es erwarten. Automatisieren Sie die wiederholbaren Schichten und behalten Sie Menschen auf den Urteilsschichten.
Lokalisierungstesting ist der unglänzende Schritt, der entscheidet, ob Ihr nächster Markt öffnet oder schließt. Ein Nutzer, der auf eine defekte Registrierung in seiner Sprache trifft, einen Telefonfehler in einem Format erhält, das er nicht parsen kann, oder dabei zusieht, wie ein Verifizierungslink drei Stunden zu früh abläuft, reicht keinen Fehler ein. Er wechselt zu einem Konkurrenten, dessen Produkt so aussieht, als wäre es tatsächlich für ihn gebaut worden. Wenn die Ausführung dieser Matrix über drei oder dreißig Locales schwerer klingt, als Ihr Team absorbieren kann, kontaktieren Sie uns und wir werden es gemeinsam abstecken.
Erfahren Sie, wie QAwerks QA-Team 40+ lokalisierte Versionen über 8 Vertikalen für ein Hochschulportal mit 110 Millionen jährlichen Besuchen stabil hält.
