Hva er lokaliseringstesting? Eksempel på testtilfeller og sjekkliste

Lokaliseringstesting

Lokaliseringstesting er en programvaretestingsteknikk der oppførselen til en programvare testes for en bestemt region, lokalitet eller kultur. Hensikten med å utføre lokaliseringstesting for en programvare er å teste passende språklige og kulturelle aspekter for et bestemt sted. Det er prosessen med å tilpasse programvaren i henhold til målspråket og landet.

Det viktigste området som påvirkes av lokaliseringstesting inkluderer innhold og brukergrensesnitt.

Det er en prosess for å teste en globalisert applikasjon hvis brukergrensesnitt, standardspråk, valuta, dato, tidsformat og dokumentasjon er utformet i henhold til det målrettede landet eller området. Det sikrer at applikasjonen er egnet nok til å brukes i det aktuelle landet.

Eksempel:

1. Hvis prosjektet er designet for Tamil Nadu-staten i India, skal det utformede prosjektet være på tamilsk språk, tamilsk virtuelt tastatur skal være til stede, osv.

2. Hvis prosjektet er designet for USA, bør tidsformatet endres i henhold til USAs standardtid. Språk og pengeformat bør også følge amerikanske standarder.

Illustrasjonen nedenfor viser det samme produktet tilpasset for forskjellige språk, der språk-, valuta- og formateringsreglene endres, mens den underliggende versjonen forblir den samme.

Hvorfor utfører lokaliseringstesting?

Hensikten med å utføre lokaliseringstesting er å sjekke passende språklige og kulturelle aspekter for en bestemt lokalitet. Det inkluderer en endring i brukergrensesnittet eller til og med de første innstillingene i henhold til kravene.

I denne typen testing vil mange forskjellige testere gjenta de samme funksjonene. De bekrefter forskjellige ting som typografiske feil, kulturell hensiktsmessighet av brukergrensesnittet, språklige feil, etc.

Det kalles også «L10N» fordi det er 10 tegn mellom L og N i ordet lokalisering.

Det er også en kommersiell grunn til dette. En feiloversatt etikett eller en dato som leser 03/04 som mars i stedet for april, svekker tilliten til et marked et team allerede har betalt for å komme inn i, og disse feilene blir funnet av en tester på målstedet i stedet for av GUI-testing utført på engelsk.

Lokaliseringstesting vs. internasjonaliseringstesting

De to aktivitetene er sekvensielle snarere enn konkurrerende. Internasjonaliseringstesting (I18N) bekrefter at kodebasen kan akseptere alle språkinnstillinger; lokaliseringstesting (L10N) bekrefter deretter at én spesifikk språkinnstillinger er riktig.

Lokaliseringstesting (L10N)	Internasjonaliseringstesting (I18N)
Bekrefter at produktet føles naturlig i ett målområde	Bekrefter at produktet kan støtte mange regioner uten ombygging
Sjekker oversatt tekst, valuta, dato, klokkeslett og kulturell tilpasning	Sjekker tegnkoding, strengeksternalisering og språktilpasset kode
Kjører når den oversatte versjonen for det markedet finnes	Kjører først, før tekst sendes til oversettelse
Trenger en tester eller anmelder som kan det lokale språket	Kan utføres av kjerneteamet ved hjelp av pseudo-oversatte bygg

Sjekk denne opplæringen for forskjellen mellom lokaliserings- og globaliseringstesting.

Slik gjør du lokaliseringstesting

For en typisk lokaliseringstesting setter vi opp byggverifiseringstesting, Funksjonell testing, Regresjonstesting, og endelig avmelding.

1. Byggverifiseringstesting er en liten undergruppe av funksjonstesting, som utføres før kvalitetssikringen starter med detaljert testing. Den er i ånden lik røyktestingDen lokaliserte versjonen avvises raskt hvis språkpakken ikke lastes inn i det hele tatt.

2. Normal testing er trinnet for å kjøre de normale testsakene og finne loggfeil under utførelse.

3. Regresjonstesting er Defekt regresjonsprosess for å sikre at defekten er fikset mens det ikke er noen innvirkning av faste defekter på omkringliggende områder.

4. Final Sign-off er å utføre sluttkontroll av bygget før levering til klienten.

Hver fase gjentas per språk, ikke én gang for produktet. En feil som er rettet i den franske versjonen må også regreseres i den tyske og japanske versjonen, fordi den samme strengressursen ofte deles mellom dem.

Automatisering i lokaliseringstesting

Hvis prosjektet er stort og må testes ofte, så går vi for Automatiseringstesting.

• Velg automatiseringsverktøy for å skrive skript.
• Ta scenariet som skal testes for lokaliseringsstrategi.
• Skriv manus i henhold til det.
• Samle resultatene og oppdater scenariet som Bestått/Ikke bestått.

OBS: Selenium er et av banebrytende verktøy på dette området. Det er veldig funksjonsrikt, men det krever mer teknisk kunnskap å bruke.

Automatisering har en begrensning som er verdt å si tydelig. Et skript kan bevise at et valutasymbol har endret seg og at ingen streng er avkortet, men det kan ikke bedømme om en oversettelse leses naturlig eller om et ikon er støtende. Maskinkontroller håndterer det mekaniske laget; en innfødt anmelder håndterer fortsatt det språklige laget.

Verktøy for lokaliseringstesting

Lokaliseringsarbeid bruker tre forskjellige verktøyklasser, og de fleste team ender opp med å bruke alle tre.

• Funksjonelle automatiseringsrammeverk: Selenium, Appium og sammenlignbare rammeverk kjører den samme suiten på nytt mot hver lokale versjon, som er der mesteparten av den repeterende verifiseringen skjer.
• Oversettelsesstyringssystemer: Plattformer som inneholder strengressursene, gjør at oversettere, utviklere og testere kan jobbe fra én ordliste, slik at et begrep ikke oversettes på to forskjellige måter på to skjermbilder.
• Pseudo-lokaliseringsverktøy: Disse erstatter engelske strenger med aksentbelagte, forlengede plassholdere før den virkelige oversettelsen begynner, og eksponerer dermed hardkodet tekst og oppsett som ikke kan absorbere lengre ord.

Enhets- og nettleserdekning er like viktig som verktøyet. Skrifter, inndatametoder og standardspråk varierer på tvers av plattformer, så den lokaliserte byggingen må utføres på virkelige målenheter underveis. mobil testing og på tvers av nettlesersettet som er definert for testing av webapplikasjoner.

Sjekkliste for beste praksis for lokaliseringstesting

• Lei inn et lokaliseringsfirma med ekspertise innen i18n-teknikk
• Sørg for at strategien for lokaliseringstesting gir mer tid til dobbeltbyte-språk.
• Sørg for at du internasjonaliserer koden din for DBCS-en på riktig måte før dutracsende hvilken som helst tekst til oversettelse
• Eksternaliser først hver streng til ressursfiler, slik at ingen brukersynlig tekst forblir hardkodet i kildekoden.
• Kjør en pseudolokalisert versjon tidlig, fordi den eksponerer avkorting og hardkodet tekst før oversettelsespengene er brukt opp.
• Reserver plass i layouten for tekstutvidelse, siden oversettelser fra engelsk ofte er lengre enn den opprinnelige etiketten.
• Test høyre-mot-venstre-språkinnstillinger som arabisk og hebraisk på ekte skjermer, der speilede oppsett og tekst i blandede retninger oftest mislykkes.
• Vedlikehold en stilguide per språkområde som dekker datorekkefølge, desimalskilletegn, adresseformat, æresbevisninger og tone.
• Få en morsmålstalende til å se gjennom de ferdige skjermbildene, fordi kulturell tilpasning ikke kan bekreftes av et manus.

To av disse elementene avhenger av plattformen snarere enn språket, og det er derfor lokaliserte bygg vanligvis planlegges sammen med kompatibilitetstesting og konfigurasjonstesting heller enn etter dem.

Eksempel på testtilfeller for lokaliseringstesting

Tabellen nedenfor gir et startsett med kontroller. Hver rad blir en full rad testforsøk når det forventede resultatet for den spesifikke lokalen er fylt ut.

S.No	Testsak Description
1	Ordlister er tilgjengelige for referanse og sjekk.
2	Tid og dato er riktig formatert for målregionen.
3	Telefonnummerformater er riktige for målregionen.
4	Valuta for målregionen.
5	Følger lisensen og reglene gjeldende nettside(region).
6	Tekstinnholdsoppsettet på sidene er feilfritt, skriftuavhengighet og linjejusteringer.
7	Spesialtegn, hyperkoblinger og hurtigtaster funksjonalitet.
8	Valideringsmelding for inndatafelt.
9	Den genererte bygningen inkluderer alle nødvendige filer.
10	Den lokaliserte skjermen har samme type elementer og tall som kildeproduktet.
11	Sørg for at det lokaliserte brukergrensesnittet til programvare eller webapplikasjoner sammenlignes med kildebrukergrensesnittet i måloperativsystemene og brukermiljøene.
12	Sortering og alfabetisk rekkefølge følger reglene for målspråket, ikke kildespråket.
13	Høyre-mot-venstre-språk speiler oppsettet riktig, inkludert navigasjon, ikoner og strenger med blandede retninger.
14	Tastaturinntasting, stavekontroll og søk godtar aksenttegn og tegn på flere byte.

Fordeler med lokaliseringstesting

Følgende er fordelene med lokaliseringstesting

• Total testkostnad reduseres
• Samlet støttekostnad reduseres
• Hjelper med å redusere tiden for testing.
• Den har mer fleksibilitet og skalerbarhet.

Disse besparelsene kommer fra å fange opp lokale feil én gang, sentralt, i stedet for én gang per markedsstøttekø. Tilgjengelighetsforbedringer følger ofte også fordi den samme disiplinen som holder et oppsett intakt under lengre tyske strenger, også holder det intakt under forstørret tekst under tilgjengelighetstesting.

Ulemper med lokaliseringstesting

Følgende er utfordringene med lokaliseringstesting

• Krever en domeneekspert
• Å ansette lokal oversetter gjør ofte prosessen dyr
• Lagring av DBCS-tegn varierer i forskjellige land
• En tester kan møte tidsplanutfordringer

Tidsplanpresset er det de fleste team undervurderer. Oversettelse kommer per definisjon sent i syklusen, så lokaliseringsfeil dukker opp nær lansering, som er akkurat når en layoutendring er mest kostbar. Planlegging av lokalet går inn i den større planen beskrevet i typer programvaretesting holder den pressen håndterbar, og den generelle programvaretesting Innledningen dekker hvor fasen befinner seg generelt.

Spørsmål og svar