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

⚡ Rezumat inteligent

Testarea localizării verifică dacă software-ul se comportă corect pentru o anumită regiune, setări regionale sau cultură, acoperind conținutul tradus, aspectul interfeței utilizator, moneda, formatele de dată și oră și convențiile locale pe care le așteaptă un utilizator de pe piața respectivă.

🌐 Prescurtare: Tehnica se scrie L10N, deoarece zece caractere se află între L și N în localizare.
🎯 Obiective principale: Conținutul și interfața cu utilizatorul absorb aproape fiecare defect de localizare pe care un tester îl va înregistra.
🧭 Patru faze: Verificarea construcției, testarea funcțională, testarea de regresie și aprobarea finală alcătuiesc un ciclu tipic.
📐 Risc de aspect: Șirurile traduse se extind, iar scripturile pe doi octeți și de la dreapta la stânga sparg machetele pe care limba engleză nu le-a expus niciodată.
🤖 Automatizare: Suitele scriptate se amortizează rapid odată ce aceleași scenarii se repetă în mai multe locații.
🔀 Nu este același lucru cu I18N: Internaționalizarea pregătește codul; localizarea verifică o piață finalizată.

Citește mai mult

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.

Ilustrația de mai jos prezintă același produs adaptat pentru diferite setări regionale, cu regulile de limbă, monedă și formatare care se schimbă, în timp ce versiunea de bază rămâne aceeași.

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.

Se mai numește și „L10N” deoarece există 10 caractere între L și N în localizarea cuvântului.

Există și un motiv comercial în spatele acestui efort. O etichetă tradusă greșit sau o dată care scrie 03/04 ca martie în loc de aprilie erodează încrederea într-o piață pentru care o echipă a plătit deja să intre, iar aceste defecte sunt găsite de un tester în locația țintă, mai degrabă decât de... Testarea interfeței grafice efectuată în limba engleză.

Testarea localizării vs. testarea internaționalizării

Cele două activități sunt secvențiale, nu concurente. Testarea internaționalizării (I18N) confirmă faptul că baza de cod poate accepta orice setări regionale; testarea localizării (L10N) confirmă apoi că o anumită setare regională este corectă.

Testarea localizării (L10N)	Testarea Internaționalizării (I18N)
Verifică dacă produsul este specific unei regiuni țintă	Verifică faptul că produsul poate fi utilizat în multe regiuni fără a fi necesară reamenajarea.
Verifică textul tradus, moneda, data, ora și compatibilitatea culturală	Verifică codificarea caracterelor, externalizarea șirurilor de caractere și codul cu funcție de localizare
Rulează odată ce versiunea tradusă pentru piața respectivă există	Rulează mai întâi, înainte ca orice text să fie trimis pentru traducere
Are nevoie de un tester sau recenzent care cunoaște limba locală	Poate fi realizat de echipa principală folosind versiuni pseudo-traduse

Verificați acest tutorial pentru Diferența dintre testarea prin localizare și cea prin globalizare.

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ă, care se efectuează înainte de începerea asigurării calității cu orice testare detaliată. Este aproape ca spirit de testarea fumuluiVersiunea localizată este respinsă rapid dacă pachetul lingvistic nu se încarcă deloc.

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.

Fiecare fază se repetă pentru fiecare setare regională, nu o singură dată pentru produs. Un defect remediat în versiunea franceză trebuie regresat și în versiunile germană și japoneză, deoarece aceeași resursă de tip șir de caractere este adesea partajată între ele.

Automatizare în testarea localizării

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.

Automatizarea are o limită care merită menționată clar. Un script poate dovedi că un simbol valutar s-a modificat și că niciun șir nu este trunchiat, dar nu poate evalua dacă o traducere se citește natural sau dacă o pictogramă ofensează. Verificările automate se ocupă de stratul mecanic; un recenzent nativ se ocupă în continuare de stratul lingvistic.

Instrumente de testare a localizării

Munca de localizare se bazează pe trei clase diferite de instrumente, iar majoritatea echipelor ajung să le utilizeze pe toate trei.

Cadre de automatizare funcțională: Selenium, Appium și framework-uri comparabile rulează din nou aceeași suită pentru fiecare versiune de localizare, unde are loc cea mai mare parte a verificării repetitive.
Sisteme de gestionare a traducerilor: Platformele care dețin resursele de tip șir de caractere permit traducătorilor, dezvoltatorilor și testerilor să lucreze dintr-un singur glosar, astfel încât un termen să nu fie tradus în două moduri diferite pe două ecrane.
Utilitare de pseudo-localizare: Acestea înlocuiesc șirurile de caractere în limba engleză cu substituenți accentuați și alungiți înainte de începerea traducerii reale, expunând text codificat fix și machete care nu pot absorbi cuvinte mai lungi.

Acoperirea dispozitivului și a browserului contează la fel de mult ca instrumentul. Fonturile, metodele de introducere a datelor și setările regionale implicite diferă în funcție de platformă, așa că versiunea localizată trebuie testată pe dispozitive țintă reale în timpul... testarea mobilă și în setul de browsere definit pentru testarea aplicațiilor web.

Listă de verificare a celor mai bune practici pentru testarea localizării

Angajați o firmă de localizare cu expertiză în inginerie i18n
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
Externalizați mai întâi fiecare șir în fișiere de resurse, astfel încât niciun text vizibil utilizatorului să nu rămână codificat în sursă.
Rulați o versiune pseudo-localizată devreme, deoarece expune trunchierea și textul codificat hard-coded înainte ca banii pentru traducere să fie cheltuiți.
Rezervați spațiu de aspect pentru extinderea textului, deoarece traducerile din engleză sunt adesea mai lungi decât eticheta originală.
Testați setările regionale de la dreapta la stânga, cum ar fi araba și ebraica, pe ecrane reale, unde aspectele oglindite și textul cu direcții mixte eșuează cel mai adesea.
Mențineți un ghid de stil pentru fiecare setare regională care să acopere ordinea datelor, separatorii zecimali, formatul adresei, titlurile onorifice și tonul.
Rugați un vorbitor nativ să verifice ecranele finalizate, deoarece compatibilitatea culturală nu poate fi afirmată printr-un scenariu.

Două dintre aceste elemente depind de platformă și nu de limbă, motiv pentru care versiunile localizate sunt de obicei programate odată cu testarea de compatibilitate și testarea configurației mai degrabă decât după ei.

Exemple de cazuri de testare pentru testarea localizării

Tabelul de mai jos oferă un set inițial de verificări. Fiecare rând devine un set complet caz de testare odată ce rezultatul așteptat pentru setarea regională specifică este completat.

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	Sortarea și ordonarea alfabetică respectă regulile limbii țintă, nu ale limbii sursă.
13	Localizările de la dreapta la stânga oglindesc corect aspectul, inclusiv navigarea, pictogramele și șirurile cu direcții mixte.
14	Introducerea de la tastatură, verificarea ortografică și căutarea acceptă caractere accentuate și caractere pe mai mulți octeți.

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.

Aceste economii provin din detectarea defectelor de localizare o singură dată, centralizat, în loc de o singură dată per coadă de asistență pentru piață. De multe ori apar și câștiguri de accesibilitate, deoarece aceeași disciplină care menține un layout intact sub șiruri de caractere mai lungi în germană îl menține și sub text mărit în timpul... 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

Presiunea asupra programului este cea pe care majoritatea echipelor o subestimează. Traducerea ajunge prin definiție târziu în ciclu, așa că defectele de localizare apar aproape de lansare, exact atunci când o modificare a aspectului este cea mai costisitoare. Planificarea localizării trece în planul mai larg descris în tipuri de testare software menține acea presiune gestionabilă, iar generalul testare software Introducerea acoperă locul în general al fazei.

Întrebări frecvente

Prin comutarea dispozitivului la arabă sau ebraică și verificarea faptului că întregul aspect reflectă — navigarea, pictogramele, indicatorii de progres și direcția de derulare. Șirurile mixte, în care un nume de produs latin se află în text arab, reprezintă punctul de eroare obișnuit.

Textul tradus este adesea mai lung decât originalul în limba engleză, astfel încât butoanele, meniurile și anteturile de tabel se depășesc sau se trunchiază. Rezervarea lățimii libere în design, apoi verificarea acesteia în cea mai lungă limbă țintă, previne majoritatea acestor defecte.

Înlocuiește fiecare șir traductibil cu o versiune accentuată, prelungită în mod deliberat. Orice text care apare încă în limba engleză simplă este codificat fix, iar orice etichetă tăiată dovedește că aspectul nu poate absorbi expansiunea. Ambele se găsesc înainte de achiziționarea traducerii.

Un inginer de asigurare a calității efectuează verificările funcționale și de aspect, iar un vorbitor nativ al limbii țintă verifică formularea, tonul și compatibilitatea culturală. Împărțirea acestui sistem evită plata unui lingvist pentru a relua etapele de regresie mecanică.

Șiruri de caractere în limba engleză codificate hard, etichete trunchiate, ordine ambiguă a datelor, separatoare zecimale și de mii greșite, caractere accentuate rupte și propoziții concatenate care se traduc în nonsensuri deoarece fragmentele au fost asamblate în cod.

Verificările pseudo-localizate încep imediat ce șirurile de caractere sunt externalizate, cu mult înainte de traducere. Verificările complete ale setărilor regionale încep atunci când este disponibilă prima versiune tradusă și repetă fiecare sprint în loc să aștepte o singură trecere înainte de lansare.

Învățarea automată compară capturile de ecran localizate cu aspectul sursă pentru a semnala trunchierile și suprapunerile, evaluează traducerile pentru abaterile de terminologie și clasifică setările regionale care prezintă cel mai mare risc. Judecata culturală finală aparține în continuare unui recenzent nativ.

Da. Redactează parametrizați în funcție de locație Selenium schele, aserțiuni de fișiere de resurse și bucle bazate pe date peste codurile de regionalizare. Valorile așteptate pentru fiecare regionalizare trebuie să provină în continuare din ghidul de stil, nu din model.