Was sind Lokalisierungstests? Beispieltestfälle und Checkliste

⚡ Intelligente Zusammenfassung

Lokalisierungstests prüfen, ob sich die Software für eine bestimmte Region, einen bestimmten Sprachgebrauch oder eine bestimmte Kultur korrekt verhält. Dabei werden übersetzte Inhalte, das Layout der Benutzeroberfläche, Währungen, Datums- und Zeitformate sowie die lokalen Konventionen, die ein Benutzer in diesem Markt erwartet, berücksichtigt.

  • 🌐 Kurzschrift: Die Technik wird als L10N bezeichnet, weil zwischen dem L und dem N in der Lokalisierung zehn Zeichen stehen.
  • 🎯 Hauptziele: Inhalte und die Benutzeroberfläche absorbieren nahezu jeden Lokalisierungsfehler, den ein Tester protokolliert.
  • 🧭 Vier Phasen: Build-Verifizierung, Funktionstests, Regressionstests und die finale Abnahme bilden einen typischen Zyklus.
  • 📐 Layoutrisiko: Übersetzte Zeichenketten dehnen sich aus, und Doppelbyte- und Rechts-nach-links-Schriften bringen Layouts zum Erliegen, die im Englischen nie aufgetaucht sind.
  • 🤖 Automation: Vorgefertigte Testläufe amortisieren sich schnell, sobald die gleichen Szenarien an vielen verschiedenen Orten ablaufen.
  • 🔀 Nicht dasselbe wie I18N: Die Internationalisierung bereitet den Code vor; die Lokalisierung überprüft ihn auf einem fertigen Markt.

Lokalisierungstests von Sprache, Währung und Datumsformaten für ein Zielgebietsschema

Lokalisierungstests

Lokalisierungstests ist eine Softwaretesttechnik, bei der das Verhalten einer Software für eine bestimmte Region, einen bestimmten Standort oder eine bestimmte Kultur getestet wird. Der Zweck von Lokalisierungstests für eine Software besteht darin, geeignete sprachliche und kulturelle Aspekte für ein bestimmtes Gebietsschema zu testen. Dabei handelt es sich um den Prozess der Anpassung der Software an die Zielsprache und das Zielland.

Der Hauptbereich, der von Lokalisierungstests betroffen ist, umfasst Inhalte und Benutzeroberfläche.

Dabei handelt es sich um einen Prozess zum Testen einer globalisierten Anwendung, deren Benutzeroberfläche, Standardsprache, Währung, Datum, Zeitformat und Dokumentation auf das Zielland oder die Zielregion abgestimmt sind. Dadurch wird sichergestellt, dass die Anwendung für die Verwendung in diesem bestimmten Land geeignet ist.

Ejemplo:

1. Wenn das Projekt für den Bundesstaat Tamil Nadu in Indien konzipiert ist, sollte das entworfene Projekt in tamilischer Sprache sein, eine tamilische virtuelle Tastatur sollte vorhanden sein usw.

2. Wenn das Projekt für die USA konzipiert ist, sollte das Zeitformat entsprechend der USA-Standardzeit geändert werden. Auch die Sprache und das Währungsformat sollten den US-amerikanischen Standards entsprechen.

Die folgende Abbildung zeigt dasselbe Produkt, das für verschiedene Regionen angepasst wird. Dabei ändern sich Sprache, Währung und Formatierungsregeln, während die zugrundeliegende Struktur gleich bleibt.

Lokalisierungstests: Anpassung eines Produkt-Builds an mehrere Zielsprachen

Warum Lokalisierungstests durchführen?

Der Zweck von Lokalisierungstests besteht darin, geeignete sprachliche und kulturelle Aspekte für ein bestimmtes Gebietsschema zu überprüfen. Dazu gehört eine Änderung der Benutzeroberfläche oder auch der Grundeinstellungen entsprechend den Anforderungen.

Bei dieser Art von Tests wiederholen viele verschiedene Tester dieselben Funktionen. Sie überprüfen verschiedene Dinge wie Tippfehler, kulturelle Angemessenheit der Benutzeroberfläche, sprachliche Fehler usw.

Es wird auch „L10N“ genannt, weil zwischen L und N im Wort Lokalisierung 10 Zeichen stehen.

Hinter diesem Aufwand steckt auch ein kommerzieller Grund. Eine falsch übersetzte Beschriftung oder ein Datum, das beispielsweise 03/04 als März statt April angibt, untergräbt das Vertrauen in einem Markt, für dessen Eintritt ein Team bereits bezahlt hat. Solche Fehler werden von einem Tester im Zielland entdeckt, anstatt von einem externen Experten. GUI-Tests Auf Englisch aufgeführt.

Lokalisierungstests vs. Internationalisierungstests

Die beiden Aktivitäten erfolgen nacheinander und stehen nicht im Wettbewerb. Internationalisierungstests (I18N) bestätigen, dass die Codebasis alle Sprachen unterstützt; Lokalisierungstests (L10N) bestätigen anschließend, dass eine bestimmte Sprache korrekt ist.

Lokalisierungstests (L10N) Internationalisierungstests (I18N)
Stellt sicher, dass sich das Produkt in einer Zielregion nativ anfühlt. Stellt sicher, dass das Produkt viele Regionen ohne Neuentwicklung unterstützen kann.
Prüft übersetzten Text, Währung, Datum, Uhrzeit und kulturelle Angemessenheit Prüft Zeichenkodierung, String-Externalisierung und lokalisierten Code
Wird ausgeführt, sobald die übersetzte Version für diesen Markt existiert. Wird zuerst ausgeführt, bevor irgendein Text zur Übersetzung gesendet wird.
Benötigt einen Tester oder Gutachter, der die Landessprache beherrscht. Kann vom Kernteam mithilfe von pseudo-übersetzten Builds durchgeführt werden.

Schauen Sie sich dieses Tutorial an ein Unterschied zwischen Lokalisierungs- und Globalisierungstests.

So führen Sie Lokalisierungstests durch

Für einen typischen Lokalisierungstest richten wir Build-Verifizierungstests ein. Funktionsprüfung, Regressionstestsund endgültige Freigabe.

1. Build-Verifizierungstests sind eine kleine Teilmenge von FunktionsprüfungDiese Durchführung erfolgt, bevor die Qualitätssicherung mit detaillierten Tests beginnt. Sie ist inhaltlich eng verwandt mit RauchprüfungDer lokalisierte Build wird schnell abgelehnt, wenn das Sprachpaket überhaupt nicht geladen werden kann.

2. Beim normalen Testen werden die normalen Testfälle ausgeführt und während der Ausführung Protokollfehler festgestellt.

3. Regressionstests sind Defekt Regressionsprozess, um sicherzustellen, dass der Fehler behoben wird, ohne dass sich die behobenen Fehler auf umliegende Bereiche auswirken.

4. Bei der Endabnahme handelt es sich um eine abschließende Prüfung des Builds vor der Lieferung an den Kunden.

Jede Phase wird für jedes Gebietsschema wiederholt, nicht nur einmal für das gesamte Produkt. Ein im französischen Build behobener Fehler muss auch in den deutschen und japanischen Builds wieder eingeführt werden, da diese oft dieselbe Zeichenkettenressource gemeinsam nutzen.

Automatisierung im Lokalisierungstest

Wenn das Projekt groß ist und häufig getestet werden muss, dann entscheiden wir uns dafür Automatisierungstests.

  • Wählen Sie ein Automatisierungstool zum Schreiben von Skripten.
  • Nehmen Sie das Szenario, um die Lokalisierungsstrategie zu testen.
  • Schreiben Sie entsprechende Skripte.
  • Sammeln Sie die Ergebnisse und aktualisieren Sie das Szenario als Bestanden/Nicht bestanden.

Hinweis: Selenium ist eines der wegweisenden Tools auf diesem Gebiet. Es ist sehr funktionsreich, erfordert jedoch mehr technische Kenntnisse für die Verwendung.

Die Automatisierung hat ihre Grenzen, die klar benannt werden müssen. Ein Skript kann zwar beweisen, dass sich ein Währungssymbol geändert hat und keine Zeichenkette abgeschnitten wurde, aber es kann nicht beurteilen, ob eine Übersetzung natürlich klingt oder ob ein Symbol anstößig ist. Maschinelle Prüfungen decken die mechanische Ebene ab; ein muttersprachlicher Korrekturleser kümmert sich weiterhin um die sprachliche Ebene.

Lokalisierungstestwerkzeuge

Für die Lokalisierungsarbeit werden drei verschiedene Werkzeugklassen verwendet, und die meisten Teams setzen am Ende alle drei ein.

  • Frameworks für die funktionale Automatisierung: Selenium, Appium Vergleichbare Frameworks führen dieselbe Testsuite für jeden Locale-Build erneut aus, wobei der Großteil der sich wiederholenden Überprüfung stattfindet.
  • Übersetzungsmanagementsysteme: Plattformen, die die String-Ressourcen verwalten, sorgen dafür, dass Übersetzer, Entwickler und Tester mit einem einzigen Glossar arbeiten, sodass ein Begriff nicht auf zwei verschiedenen Bildschirmen unterschiedlich übersetzt wird.
  • Pseudo-Lokalisierungs-Dienstprogramme: Diese ersetzen englische Zeichenketten durch akzentuierte, verlängerte Platzhalter, bevor die eigentliche Übersetzung beginnt, wodurch fest codierter Text und Layouts sichtbar werden, die keine längeren Wörter aufnehmen können.

Geräte- und Browserabdeckung sind genauso wichtig wie das Tool selbst. Schriftarten, Eingabemethoden und Standardgebietsschemas unterscheiden sich je nach Plattform, daher muss die lokalisierte Version auf realen Zielgeräten getestet werden. mobile Tests und über alle Browser hinweg, die für definiert sind Testen von Webanwendungen.

Checkliste mit Best Practices für Lokalisierungstests

  • Beauftragen Sie ein Lokalisierungsunternehmen mit Expertise im Bereich Internationalisierung (i18n).
  • Stellen Sie sicher, dass Ihre Lokalisierungsteststrategie mehr Zeit für Double-Byte-Sprachen lässt.
  • Stellen Sie sicher, dass Sie Ihren Code für DBCS ordnungsgemäß internationalisieren, bevor Sie ihn exportieren.traceinen beliebigen Text zur Übersetzung senden
  • Zuerst sollten alle Zeichenketten in Ressourcendateien ausgelagert werden, damit kein für den Benutzer sichtbarer Text im Quellcode fest codiert bleibt.
  • Führen Sie frühzeitig einen pseudolokalisierten Build durch, da dieser Kürzungen und fest codierten Text aufdeckt, bevor Übersetzungskosten anfallen.
  • Lassen Sie im Layout Platz für die Texterweiterung, da Übersetzungen aus dem Englischen häufig länger sind als die Originalbezeichnung.
  • Testen Sie Rechts-nach-links-Sprachen wie Arabisch und Hebräisch auf echten Bildschirmen, wo gespiegelte Layouts und Texte mit gemischter Leserichtung am häufigsten versagen.
  • Pflegen Sie einen Styleguide pro Region, der Datumsreihenfolge, Dezimaltrennzeichen, Adressformat, Höflichkeitsformen und Tonfall abdeckt.
  • Lassen Sie die fertigen Drehbücher von einem Muttersprachler gegenlesen, denn kulturelle Passung lässt sich nicht allein durch ein Drehbuch gewährleisten.

Zwei dieser Elemente hängen eher von der Plattform als von der Sprache ab, weshalb lokalisierte Builds in der Regel zusammen mit anderen Projekten geplant werden. Kompatibilitätstests und Konfigurationstests eher als ihnen nachzujagen.

Beispieltestfälle für Lokalisierungstests

Die folgende Tabelle enthält einen ersten Satz von Prüfungen. Jede Zeile wird zu einer vollständigen Prüfung. Testfall sobald das erwartete Ergebnis für den jeweiligen Standort eingegeben wurde.

S.Nr. Testfall DescriptIon
1 Glossare stehen als Referenz und Überprüfung zur Verfügung.
2 Uhrzeit und Datum sind für die Zielregion richtig formatiert.
3 Telefonnummernformate sind für die Zielregion geeignet.
4 Währung für die Zielregion.
5 Entsprechen die Lizenz und die Regeln der aktuellen Website (Region)?
6 Das Textinhaltslayout auf den Seiten ist fehlerfrei, Schriftartunabhängigkeit und Zeilenausrichtung.
7 Sonderzeichen, Hyperlinks und Hotkeys-Funktionalität.
8 Validierungsnachricht für Eingabefelder.
9 Der generierte Build enthält alle erforderlichen Dateien.
10 Der lokalisierte Bildschirm verfügt über dieselben Elemente und Zahlen wie das Quellprodukt.
11 Stellen Sie sicher, dass die lokalisierte Benutzeroberfläche von Software oder Webanwendungen mit der Quellbenutzeroberfläche in den Zielbetriebssystemen und Benutzerumgebungen vergleichbar ist.
12 Sortierung und alphabetische Reihenfolge richten sich nach den Regeln der Zielsprache, nicht nach denen der Ausgangssprache.
13 Bei Rechts-nach-links-Sprachen wird das Layout korrekt wiedergegeben, einschließlich Navigation, Symbolen und Zeichenketten mit gemischter Leserichtung.
14 Tastatureingabe, Rechtschreibprüfung und Suche akzeptieren Akzentzeichen und Mehrbytezeichen.

Vorteile von Lokalisierungstests

Nachfolgend sind die Vorteile von Lokalisierungstests aufgeführt

  • Die Gesamtkosten für Tests werden gesenkt
  • Die Gesamtkosten für den Support werden gesenkt
  • Hilft dabei, die Testzeit zu verkürzen.
  • Es bietet mehr Flexibilität und Skalierbarkeit.

Diese Einsparungen ergeben sich daraus, dass Lokalisierungsfehler zentral und nicht einzeln pro Markt-Support-Warteschlange erkannt werden. Oftmals verbessert sich dadurch auch die Barrierefreiheit, da dieselbe Vorgehensweise, die ein Layout bei längeren deutschen Zeichenketten intakt hält, es auch bei vergrößertem Text beibehält. Erreichbarkeitstests.

Nachteile von Lokalisierungstests

Im Folgenden sind die Herausforderungen bei Lokalisierungstests aufgeführt

  • Erfordert einen Domänenexperten
  • Die Beauftragung eines lokalen Übersetzers macht den Prozess oft teuer
  • Die Speicherung von DBCS-Zeichen ist je nach Land unterschiedlich
  • Ein Tester kann mit zeitlichen Herausforderungen konfrontiert sein

Der Zeitdruck wird von den meisten Teams unterschätzt. Übersetzungen treffen definitionsgemäß erst spät im Zyklus ein, sodass Lokalisierungsfehler erst kurz vor der Veröffentlichung auftreten – genau dann, wenn Layoutänderungen am teuersten sind. Die Planung der Lokalisierung ist Bestandteil des übergeordneten Plans, der in Abschnitt 6 beschrieben wird. Arten von Softwaretests hält diesen Druck überschaubar und die allgemeine Softwaretest Die Einleitung beschreibt, wo die Phase insgesamt einzuordnen ist.

Häufig gestellte Fragen

Durch Umschalten des Geräts auf Arabisch oder Hebräisch lässt sich überprüfen, ob das gesamte Layout – Navigation, Symbole, Fortschrittsanzeigen und Scrollrichtung – übereinstimmt. Häufige Fehlerquellen sind gemischte Zeichenketten, bei denen ein lateinischer Produktname in arabischem Text vorkommt.

Übersetzter Text ist oft länger als das englische Original, wodurch Schaltflächen, Menüs und Tabellenüberschriften überlaufen oder abgeschnitten werden. Durch das Einplanen von zusätzlicher Breite im Design und die anschließende Überprüfung in der längsten Zielsprache lassen sich die meisten dieser Fehler vermeiden.

Es ersetzt jede übersetzbare Zeichenkette durch eine akzentuierte, bewusst verlängerte Version. Jeglicher noch in normalem Englisch erscheinender Text wird fest codiert, und jede abgeschnittene Beschriftung beweist, dass das Layout keine Erweiterung zulässt. Beides wird vor dem Kauf der Übersetzung festgestellt.

Ein QA-Ingenieur führt die Funktions- und Layoutprüfungen durch, während ein Muttersprachler der Zielsprache Formulierung, Tonfall und kulturelle Passung überprüft. Durch diese Aufteilung entfällt die Notwendigkeit, einen Linguisten für die erneute Durchführung mechanischer Regressionstests zu bezahlen.

Fest codierte englische Zeichenketten, abgeschnittene Bezeichnungen, uneindeutige Datumsreihenfolge, falsche Dezimal- und Tausendertrennzeichen, fehlerhafte Akzentzeichen und aneinandergereihte Sätze, die sich zu Unsinn übersetzen lassen, weil die Fragmente im Code zusammengesetzt wurden.

Pseudolokalisierte Prüfungen beginnen, sobald Zeichenketten externalisiert werden, also lange vor der Übersetzung. Vollständige Lokalisierungsprüfungen starten, sobald der erste übersetzte Build verfügbar ist, und werden in jedem Sprint wiederholt, anstatt vor der Veröffentlichung auf einen einzelnen Durchlauf zu warten.

Maschinelles Lernen vergleicht lokalisierte Screenshots mit dem Original-Layout, um Kürzungen und Überlappungen zu erkennen, bewertet Übersetzungen hinsichtlich terminologischer Abweichungen und ordnet die Sprachen mit dem höchsten Risiko ein. Die endgültige kulturelle Beurteilung obliegt jedoch weiterhin einem muttersprachlichen Gutachter.

Ja. Es erstellt lokal parametrisierte Entwürfe. Selenium Gerüststrukturen, Ressourcendatei-Assertions und datengesteuerte Schleifen über Gebietsschemacodes. Die erwarteten Werte pro Gebietsschema müssen weiterhin aus dem Styleguide stammen, nicht aus dem Modell.

Fassen Sie diesen Beitrag mit folgenden Worten zusammen: