Ce este testarea de localizare? Exemple de cazuri de testare și listă de verificare

Testare de localizare

Testare de localizare este o tehnică de testare a software-ului în care comportamentul unui software este testat pentru o anumită regiune, locație sau cultură. Scopul efectuării testării de localizare pentru un software este de a testa aspectele lingvistice și culturale adecvate pentru o anumită locație. Este procesul de personalizare a software-ului în funcție de limba și țara vizate.

Zona majoră afectată de testarea localizării include conținutul și interfața de utilizare.

Este un proces de testare a unei aplicații globalizate a cărei interfață de utilizare, limbă implicită, monedă, format de dată, oră și documentație sunt proiectate în funcție de țara sau regiunea vizată. Se asigură că aplicația este suficient de capabilă pentru utilizare în acea țară.

Exemplu:

1. Dacă proiectul este conceput pentru statul Tamil Nadu din India, proiectul ar trebui să fie în limba tamilă, tastatura virtuală tamilă ar trebui să fie prezentă etc.

2. Dacă proiectul este proiectat pentru SUA, atunci formatul orei ar trebui schimbat în conformitate cu ora standard din SUA. De asemenea, limba și formatul de bani ar trebui să respecte standardele SUA.

The illustration below shows the same product being adapted for different locales, with the language, currency and formatting rules changing while the underlying build stays the same.

De ce se face testarea de localizare?

Scopul efectuării testării de localizare este de a verifica aspectele lingvistice și culturale adecvate pentru o anumită locație. Include o modificare a interfeței cu utilizatorul sau chiar setările inițiale conform cerințelor.

În acest tip de testare, mulți testeri diferiți vor repeta aceleași funcții. Ei verifică diverse lucruri, cum ar fi erorile de tipar, caracterul adecvat cultural al interfeței de utilizare, erorile lingvistice etc.

It is also called “L10N” because there are 10 characters in between L & N in the word localization.

There is a commercial reason behind the effort as well. A mistranslated label or a date that reads 03/04 as March instead of April erodes trust in a market a team has already paid to enter, and those defects are found by a tester in the target locale rather than by Testarea interfeței grafice performed in English.

Localization Testing vs Internationalization Testing

The two activities are sequential rather than competing. Internationalization testing (I18N) confirms that the code base can accept any locale at all; localization testing (L10N) then confirms that one specific locale is correct.

Localization Testing (L10N)	Internationalization Testing (I18N)
Verifies that the product feels native in one target region	Verifies that the product can support many regions without redevelopment
Checks translated text, currency, date, time and cultural fit	Checks character encoding, string externalisation and locale-aware code
Runs once the translated build for that market exists	Runs first, before any text is sent for translation
Needs a tester or reviewer who knows the local language	Can be performed by the core team using pseudo-translated builds

Verificați acest tutorial pentru a difference between localization and globalization testing.

Cum se face testarea de localizare

Pentru o testare tipică de localizare, am configurat testarea de verificare a build-ului, Functional Testing, Testarea regresiei, și semnarea finală.

1. Testarea de verificare a construcției este un mic subset de testarea funcțională, which is performed before QA starts with any detailed testing. It is close in spirit to testarea fumului: the localized build is rejected quickly if the language pack fails to load at all.

2. Testarea normală este pasul pentru a rula cazurile de testare normale și pentru a găsi defecte de jurnal în timpul execuției.

3. Testarea de regresie este Defect proces de regresie pentru a se asigura că defectul este reparat în timp ce defectele remediate nu au impact asupra zonelor înconjurătoare.

4. Închiderea finală este de a efectua verificarea finală a construcției înainte de livrarea către client.

Each phase is repeated per locale, not once for the product. A defect fixed in the French build has to be regressed in the German and Japanese builds too, because the same string resource is often shared between them.

Automation in Localization Testing

Dacă proiectul este mare și trebuie testat des, atunci mergem pentru Testarea automatizării.

• Alegeți instrumentul de automatizare pentru a scrie scripturi.
• Luați scenariul pentru a fi testat pentru strategia de localizare.
• Scrieți scenarii în funcție de asta.
• Colectați rezultatele și actualizați scenariul ca Reușit/Eșuat.

Notă: Selenium este unul dintre instrumentele de pionierat în acest domeniu. Este foarte bogat în funcții, dar necesită mai multe cunoștințe tehnice pentru utilizare.

Automation carries a limit worth stating plainly. A script can prove that a currency symbol changed and that no string is truncated, but it cannot judge whether a translation reads naturally or whether an icon offends. Machine checks handle the mechanical layer; a native reviewer still handles the linguistic layer.

Localization Testing Tools

Localization work draws on three different classes of tool, and most teams end up running all three.

• Functional automation frameworks: Selenium, Appium and comparable frameworks re-run the same suite against each locale build, which is where the bulk of repetitive verification happens.
• Translation management systems: Platforms that hold the string resources keep translators, developers and testers working from one glossary, so a term is not translated two different ways in two screens.
• Pseudo-localization utilities: These replace English strings with accented, lengthened placeholders before real translation begins, exposing hard-coded text and layouts that cannot absorb longer words.

Device and browser coverage matters just as much as the tool. Fonts, input methods and default locales differ across platforms, so the localized build has to be exercised on real target devices during testarea mobilă and across the browser set defined for testarea aplicațiilor web.

Best Practices Checklist for Localization Testing

• Hire a localization firm with expertise in i18n engineering
• Asigurați-vă că strategia dvs. de testare a localizării oferă mai mult timp pentru limbile pe doi octeți.
• Asigurați-vă că internaționalizați corect codul pentru DBCS înainte de extractrimiterea oricărui text spre traducere
• Externalise every string into resource files first, so that no user-visible text remains hard-coded in the source.
• Run a pseudo-localized build early, because it exposes truncation and hard-coded text before translation money is spent.
• Reserve layout space for text expansion, since translations from English frequently run longer than the original label.
• Test right-to-left locales such as Arabic and Hebrew on real screens, where mirrored layouts and mixed-direction text fail most often.
• Maintain a per-locale style guide covering date order, decimal separators, address format, honorifics and tone.
• Have a native speaker review the finished screens, because cultural fit cannot be asserted by a script.

Two of those items depend on the platform rather than the language, which is why localized builds are usually scheduled alongside testarea de compatibilitate și testarea configurației rather than after them.

Exemple de cazuri de testare pentru testarea localizării

The table below gives a starting set of checks. Each row becomes a full caz de testare once the expected result for the specific locale is filled in.

S.No	Caz de testare Description
1	Glosarele sunt disponibile pentru referință și verificare.
2	Ora și data sunt formatate corespunzător pentru regiunea țintă.
3	Formatele numerelor de telefon sunt adecvate regiunii vizate.
4	Moneda pentru regiunea țintă.
5	Licența și Regulile respectă site-ul web actual (regiunea).
6	Aspectul de conținut text din pagini este fără erori, independență de font și aliniere a liniilor.
7	Caractere speciale, hyperlink și funcționalitate taste rapide.
8	Mesaj de validare pentru câmpurile de intrare.
9	Compilarea generată include toate fișierele necesare.
10	Ecranul localizat are același tip de elemente și numere ca și cel al produsului sursă.
11	Asigurați-vă că interfața de utilizator localizată a aplicațiilor software sau web se compară cu interfața de utilizator sursă în sistemele de operare și mediile de utilizator țintă.
12	Sorting and alphabetical ordering follow the rules of the target language, not the source language.
13	Right-to-left locales mirror the layout correctly, including navigation, icons and mixed-direction strings.
14	Keyboard input, spell check and search accept accented and multi-byte characters.

Avantajele testării de localizare

Următoarele sunt beneficiile testării de localizare

• Costul total de testare reduce
• Reducerea costului total al suportului
• Ajută la reducerea timpului de testare.
• Are mai multă flexibilitate și scalabilitate.

Those savings come from catching locale defects once, centrally, instead of once per market support queue. Accessibility gains often follow as well, because the same discipline that keeps a layout intact under longer German strings also keeps it intact under enlarged text during testarea accesibilității.

Dezavantajele testării de localizare

Următoarele sunt provocările testării de localizare

• Necesită un expert în domeniu
• Angajarea unui traducător local face adesea procesul costisitor
• Stocarea caracterelor DBCS diferă în diferite țări
• Un tester se poate confrunta cu probleme de program

The schedule pressure is the one most teams underestimate. Translation arrives late in the cycle by definition, so localization defects surface close to release, which is exactly when a layout change is most expensive. Planning the locale passes into the wider plan described in tipuri de testare software keeps that squeeze manageable, and the general testare software introduction covers where the phase sits overall.

Întrebări frecvente