Vad är lokaliseringstestning? Exempel på testfall och checklista

Lokaliseringstestning

Lokaliseringstestning är en mjukvarutestteknik där beteendet hos en programvara testas för en specifik region, lokal eller kultur. Syftet med att göra lokaliseringstestning för en programvara är att testa lämpliga språkliga och kulturella aspekter för en viss plats. Det är processen att anpassa programvaran enligt målspråket och landet.

Det huvudsakliga området som påverkas av lokaliseringstestning inkluderar innehåll och användargränssnitt.

Det är en process för att testa en globaliserad applikation vars användargränssnitt, standardspråk, valuta, datum, tidsformat och dokumentation är utformade enligt det land eller region som du riktar dig till. Det säkerställer att applikationen är tillräckligt kapabel för användning i just det landet.

Exempel:

1. Om projektet är designat för delstaten Tamil Nadu i Indien, ska det designade projektet vara på tamilskt språk, tamilskt virtuellt tangentbord ska finnas osv.

2. Om projektet är designat för USA, bör tidsformatet ändras enligt USA Standard Time. Språk- och pengaformat bör också följa USA:s standarder.

Illustrationen nedan visar samma produkt som anpassas för olika språkinställningar, där språk-, valuta- och formateringsreglerna ändras medan den underliggande versionen förblir densamma.

Varför gör lokaliseringstestning?

Syftet med att göra lokaliseringstestning är att kontrollera lämpliga språkliga och kulturella aspekter för en viss plats. Det inkluderar en förändring av användargränssnittet eller till och med de initiala inställningarna enligt kraven.

I denna typ av testning kommer många olika testare att upprepa samma funktioner. De verifierar olika saker som typografiska fel, kulturell lämplighet för UI, språkliga fel, etc.

Det kallas också ”L10N” eftersom det finns 10 tecken mellan L och N i ordet lokalisering.

Det finns också en kommersiell anledning bakom ansträngningen. En felöversatt etikett eller ett datum som lyder 03/04 som mars istället för april urholkar förtroendet för en marknad som ett team redan har betalat för att komma in på, och dessa brister upptäcks av en testare på målplatsen snarare än av GUI-testning framfördes på engelska.

Lokaliseringstestning kontra internationaliseringstestning

De två aktiviteterna är sekventiella snarare än konkurrerande. Internationaliseringstestning (I18N) bekräftar att kodbasen kan acceptera vilken språkinställning som helst; lokaliseringstestning (L10N) bekräftar sedan att en specifik språkinställning är korrekt.

Lokaliseringstestning (L10N)	Internationaliseringstestning (I18N)
Verifierar att produkten känns naturlig i en målregion	Verifierar att produkten kan stödja många regioner utan ombyggnad
Kontrollerar översatt text, valuta, datum, tid och kulturell anpassning	Kontrollerar teckenkodning, strängexternalisering och språkanpassad kod
Körs när den översatta versionen för den marknaden finns	Körs först, innan någon text skickas för översättning
Behöver en testare eller recensent som kan det lokala språket	Kan utföras av kärnteamet med hjälp av pseudoöversatta versioner

Kolla denna handledning för skillnaden mellan lokaliserings- och globaliseringstestning.

Hur man gör lokaliseringstestning

För en typisk lokaliseringstestning, ställer vi upp byggverifieringstestning, funktions~~POS=TRUNC, Regressionstestning, och slutlig sign-off.

1. Byggverifieringstestning är en liten delmängd av funktionstestning, vilket utförs innan kvalitetssäkringen påbörjas med någon detaljerad testning. Det är i sin anda nära röktestningDen lokaliserade versionen avvisas snabbt om språkpaketet inte laddas alls.

2. Normal testning är steget för att köra de normala testfallen och hitta loggfel under körning.

3. Regressionstestning är defekt regressionsprocess för att säkerställa att defekten åtgärdas medan det inte finns någon påverkan av fixerade defekter på omgivande områden.

4. Slutlig sign-off är att utföra slutlig kontroll av bygget innan leverans till kunden.

Varje fas upprepas per språkinställning, inte en gång för produkten. En defekt som åtgärdats i den franska versionen måste även regresseras i de tyska och japanska versionerna, eftersom samma strängresurs ofta delas mellan dem.

Automatisering i lokaliseringstestning

Om projektet är stort och behöver testas ofta så går vi för Automationstestning.

• Välj automatiseringsverktyg för att skriva skript.
• Ta scenariot som ska testas för lokaliseringsstrategi.
• Skriv manus enligt det.
• Samla resultaten och uppdatera scenariot som Godkänt/Underkänd.

Obs: Selenium är ett av de banbrytande verktygen inom detta område. Det är mycket funktionsrikt, men det kräver mer teknisk kunskap att använda.

Automatisering har en begränsning som är värd att tydligt ange. Ett skript kan bevisa att en valutasymbol har ändrats och att ingen sträng är avkortad, men det kan inte bedöma om en översättning läses naturligt eller om en ikon är stötande. Maskinkontroller hanterar det mekaniska lagret; en granskare med inbyggd granskning hanterar fortfarande det språkliga lagret.

Verktyg för lokaliseringstestning

Lokaliseringsarbete använder tre olika klasser av verktyg, och de flesta team använder alla tre.

• Funktionella automatiseringsramverk: Selenium, Appium och jämförbara ramverk kör samma svit igen mot varje språkversion, vilket är där huvuddelen av den repetitiva verifieringen sker.
• Översättningshanteringssystem: Plattformar som innehåller strängresurserna gör att översättare, utvecklare och testare kan arbeta från en och samma ordlista, så att en term inte översätts på två olika sätt på två skärmar.
• Pseudolokaliseringsverktyg: Dessa ersätter engelska strängar med accentuerade, förlängda platsmarkörer innan den riktiga översättningen börjar, vilket exponerar hårdkodad text och layouter som inte kan absorbera längre ord.

Enhets- och webbläsartäckning är lika viktig som verktyget. Teckensnitt, inmatningsmetoder och standardspråkinställningar skiljer sig åt mellan plattformar, så den lokaliserade versionen måste utföras på riktiga målenheter under tiden. mobil testning och över webbläsaruppsättningen som definierats för testning av webbapplikationer.

Checklista för bästa praxis för lokaliseringstestning

• Anlita ett lokaliseringsföretag med expertis inom i18n-teknik
• Se till att din lokaliseringsteststrategi ger mer tid för dubbelbyte-språk.
• Se till att du internationaliserar din kod korrekt för DBCS innan du extracskicka valfri text för översättning
• Externisera varje sträng till resursfiler först, så att ingen användarsynlig text förblir hårdkodad i källkoden.
• Kör en pseudolokaliserad version tidigt, eftersom den exponerar trunkering och hårdkodad text innan översättningspengarna är spenderade.
• Reservera layoututrymme för textutökning, eftersom översättningar från engelska ofta blir längre än den ursprungliga etiketten.
• Testa höger-till-vänster-språkinställningar som arabiska och hebreiska på riktiga skärmar, där speglade layouter och text i blandade riktningar oftast misslyckas.
• Upprätthåll en stilguide per språk som täcker datumordning, decimalavgränsare, adressformat, hedersbeteckningar och ton.
• Låt en infödd talare granska de färdiga skärmbilderna, eftersom kulturell anpassning inte kan bekräftas med hjälp av ett manus.

Två av dessa saker beror på plattformen snarare än språket, vilket är anledningen till att lokaliserade versioner vanligtvis schemaläggs parallellt med kompatibilitetstestning och konfigurationstestning snarare än efter dem.

Exempel på testfall för lokaliseringstestning

Tabellen nedan ger en startuppsättning kontroller. Varje rad blir en fullständig rad testfall när det förväntade resultatet för den specifika platsen har ifyllts.

S.No	Testfall Description
1	Ordlistor finns tillgängliga för referens och kontroll.
2	Tid och datum är korrekt formaterade för målregionen.
3	Telefonnummerformat är lämpliga för målregionen.
4	Valuta för målregionen.
5	Följer licensen och reglerna den aktuella webbplatsen (regionen).
6	Textinnehållslayouten på sidorna är felfri, teckensnittsoberoende och linjejusteringar.
7	Funktionalitet för specialtecken, hyperlänkar och snabbtangenter.
8	Valideringsmeddelande för inmatningsfält.
9	Den genererade builden innehåller alla nödvändiga filer.
10	Den lokaliserade skärmen har samma typ av element och nummer som källprodukten.
11	Se till att det lokaliserade användargränssnittet för programvara eller webbapplikationer jämförs med källanvändargränssnittet i måloperativsystemen och användarmiljöerna.
12	Sortering och alfabetisk ordning följer målspråkets regler, inte källspråkets.
13	Höger-till-vänster-språk speglar layouten korrekt, inklusive navigering, ikoner och strängar med blandade riktningar.
14	Tangentbordsinmatning, stavningskontroll och sökning accepterar accenttecken och tecken med flera byte.

Fördelar med lokaliseringstestning

Följande är fördelarna med lokaliseringstestning

• Den totala testkostnaden minskar
• Total supportkostnad minska
• Hjälper till att minska tiden för testning.
• Den har mer flexibilitet och skalbarhet.

Dessa besparingar kommer från att lokaliseringsdefekter upptäcks en gång, centralt, istället för en gång per marknadssupportkö. Tillgänglighetsvinster följer ofta också, eftersom samma disciplin som håller en layout intakt under längre tyska strängar också håller den intakt under förstorad text. tillgänglighetstester.

Nackdelar med lokaliseringstestning

Följande är utmaningarna med lokaliseringstestning

• Kräver en domänexpert
• Att anlita lokal översättare gör ofta processen dyr
• Lagring av DBCS-tecken skiljer sig åt i olika länder
• En testare kan möta schemautmaningar

Schemapressen är den som de flesta team underskattar. Översättningen kommer per definition sent i cykeln, så lokaliseringsfel dyker upp nära lanseringen, vilket är precis då en layoutändring är som dyrast. Planeringen av lokaliseringen ingår i den bredare plan som beskrivs i typer av mjukvarutestning håller den pressen hanterbar, och det allmänna mjukvarutestning Introduktionen täcker var fasen befinner sig överlag.

Vanliga frågor