Cos'è il test di localizzazione? Casi di test di esempio e lista di controllo

Test di localizzazione

Test di localizzazione è una tecnica di test del software in cui il comportamento di un software viene testato per una regione, un locale o una cultura specifica. Lo scopo di eseguire test di localizzazione per un software è testare gli aspetti linguistici e culturali appropriati per una particolare località. È il processo di personalizzazione del software in base alla lingua e al paese di destinazione.

L'area principale interessata dai test di localizzazione include contenuti e interfaccia utente.

Si tratta di un processo di test di un'applicazione globalizzata la cui interfaccia utente, lingua predefinita, valuta, data, formato ora e documentazione sono progettati in base al paese o alla regione di destinazione. Garantisce che l'applicazione sia sufficientemente capace per essere utilizzata in quel particolare paese.

Esempio:

1. Se il progetto è progettato per lo stato del Tamil Nadu in India, il progetto progettato dovrebbe essere in lingua tamil, dovrebbe essere presente la tastiera virtuale tamil, ecc.

2. Se il progetto è progettato per gli Stati Uniti, il formato dell'ora deve essere modificato in base all'ora standard degli Stati Uniti. Inoltre, la lingua e il formato del denaro dovrebbero seguire gli standard statunitensi.

L'illustrazione seguente mostra lo stesso prodotto adattato a diverse aree geografiche, con la modifica della lingua, della valuta e delle regole di formattazione, mentre la struttura di base rimane invariata.

Perché eseguire i test di localizzazione?

Lo scopo di eseguire test di localizzazione è verificare gli aspetti linguistici e culturali appropriati per un particolare luogo. Comprende una modifica dell'interfaccia utente o anche delle impostazioni iniziali in base alle esigenze.

In questo tipo di test, molti tester diversi ripeteranno le stesse funzioni. Verificano varie cose come errori tipografici, adeguatezza culturale dell'interfaccia utente, errori linguistici, ecc.

Viene anche chiamato “L10N” perché ci sono 10 caratteri tra la L e la N nella parola "localizzazione".

Dietro a questo sforzo c'è anche una ragione commerciale. Un'etichetta tradotta male o una data che riporta 03/04 come marzo invece di aprile erode la fiducia in un mercato in cui un team ha già pagato per entrare, e questi difetti vengono rilevati da un tester nel luogo di destinazione piuttosto che da Test GUI eseguito in inglese.

Test di localizzazione vs test di internazionalizzazione

Le due attività sono sequenziali, non in competizione tra loro. Il test di internazionalizzazione (I18N) verifica che il codice sorgente sia in grado di accettare qualsiasi impostazione locale; il test di localizzazione (L10N) conferma quindi che una specifica impostazione locale sia corretta.

Test di localizzazione (L10N)	Test di internazionalizzazione (I18N)
Verifica che il prodotto risulti nativo in una regione target.	Verifica che il prodotto possa supportare molte regioni senza necessità di riprogettazione.
Verifica il testo tradotto, la valuta, la data, l'ora e l'adattamento culturale.	Verifica la codifica dei caratteri, l'esternalizzazione delle stringhe e il codice sensibile alle impostazioni locali.
Si avvia una volta che esiste la versione tradotta per quel mercato	Viene eseguito per primo, prima che qualsiasi testo venga inviato per la traduzione.
Serve un tester o un revisore che conosca la lingua locale.	Può essere eseguito dal team principale utilizzando build pseudo-tradotte

Controlla questo tutorial per una differenza tra test di localizzazione e test di globalizzazione.

Come eseguire i test di localizzazione

Per un tipico test di localizzazione, impostiamo test di verifica della build, Test di funzionalità, Test di regressionee la firma finale.

1. I test di verifica della build sono un piccolo sottoinsieme di test funzionali, che viene eseguito prima che il controllo qualità inizi con qualsiasi test dettagliato. È simile nello spirito a test del fumo: la build localizzata viene rifiutata immediatamente se il pacchetto lingua non viene caricato correttamente.

2. Il test normale è il passaggio per eseguire i casi di test normali e individuare i difetti del registro durante l'esecuzione.

3. Il test di regressione è Difetto processo di regressione per garantire che il difetto venga corretto senza che vi sia alcun impatto dei difetti corretti sulle aree circostanti.

4. L'approvazione finale consiste nell'eseguire il controllo finale sulla build prima della consegna al cliente.

Ogni fase viene ripetuta per ogni lingua, non una sola volta per l'intero prodotto. Un difetto corretto nella versione francese deve essere reintrodotto anche nelle versioni tedesca e giapponese, perché la stessa risorsa stringa è spesso condivisa tra di esse.

Automazione nei test di localizzazione

Se il progetto è grande e necessita di essere testato spesso, allora procediamo Test di automazione.

• Scegli lo strumento di automazione per scrivere script.
• Prendi lo scenario da testare per la strategia di localizzazione.
• Scrivi script in base a quello.
• Raccogli i risultati e aggiorna lo scenario come Pass/Fail.

Nota: Selenium è uno degli strumenti pionieristici in questo settore. È molto ricco di funzionalità, tuttavia richiede conoscenze più tecniche per essere utilizzato.

L'automazione ha un limite che è bene precisare. Uno script può dimostrare che un simbolo di valuta è cambiato e che nessuna stringa è stata troncata, ma non può giudicare se una traduzione risulta naturale o se un'icona è offensiva. I controlli automatici si occupano dell'aspetto tecnico; un revisore madrelingua si occupa ancora dell'aspetto linguistico.

Strumenti per il test di localizzazione

Il lavoro di localizzazione si avvale di tre diverse tipologie di strumenti e la maggior parte dei team finisce per utilizzarli tutti e tre.

• Framework di automazione funzionale: Selenium, Appium e framework comparabili rieseguono la stessa suite per ogni build locale, ed è qui che avviene la maggior parte delle verifiche ripetitive.
• Sistemi di gestione della traduzione: Le piattaforme che ospitano le risorse di stringhe consentono a traduttori, sviluppatori e tester di lavorare utilizzando un unico glossario, evitando che un termine venga tradotto in due modi diversi su schermate diverse.
• Utilità di pseudo-localizzazione: Questi sistemi sostituiscono le stringhe di testo in inglese con segnaposto accentati e allungati prima che inizi la traduzione vera e propria, mettendo in evidenza testi e layout codificati in modo rigido che non possono accogliere parole più lunghe.

La copertura di dispositivi e browser è importante tanto quanto lo strumento. Font, metodi di input e impostazioni locali predefinite differiscono tra le piattaforme, quindi la build localizzata deve essere testata su dispositivi di destinazione reali durante test mobile e attraverso il set di browser definito per test di applicazioni web.

Lista di controllo delle migliori pratiche per i test di localizzazione

• Assumi un'azienda di localizzazione specializzata in ingegneria i18n.
• Assicuratevi che la vostra strategia di test di localizzazione preveda più tempo per le lingue a doppio byte.
• Assicurati di internazionalizzare correttamente il tuo codice per il DBCS prima di esportarlotracQualsiasi testo da inviare per la traduzione
• Innanzitutto, esternalizza ogni stringa in file di risorse, in modo che nessun testo visibile all'utente rimanga codificato direttamente nel codice sorgente.
• Eseguite una build pseudo-localizzata fin da subito, perché in questo modo emergono troncamenti e testo hardcoded prima che vengano spesi i fondi per la traduzione.
• Riserva spazio nel layout per l'espansione del testo, poiché le traduzioni dall'inglese sono spesso più lunghe dell'etichetta originale.
• Testa le lingue con scrittura da destra a sinistra, come l'arabo e l'ebraico, su schermi reali, dove i layout speculari e il testo con scrittura in direzioni miste spesso non funzionano correttamente.
• Mantenere una guida di stile specifica per ogni lingua e area geografica, che includa l'ordine delle date, i separatori decimali, il formato degli indirizzi, i titoli onorifici e il tono.
• Fate revisionare le schermate finali da un madrelingua, perché la coerenza culturale non può essere garantita da una sceneggiatura.

Due di questi elementi dipendono dalla piattaforma piuttosto che dalla lingua, motivo per cui le build localizzate sono solitamente programmate insieme test di compatibilità and test di configurazione piuttosto che dopo di loro.

Casi di test di esempio per i test di localizzazione

La tabella seguente fornisce un set iniziale di controlli. Ogni riga diventa un controllo completo caso di prova una volta inserito il risultato previsto per la località specifica.

S.No	Test Case Descriptione
1	I glossari sono disponibili per consultazione e verifica.
2	L'ora e la data sono formattate correttamente per la regione di destinazione.
3	I formati dei numeri di telefono sono adatti alla regione di destinazione.
4	Valuta per la regione di destinazione.
5	La Licenza e le Regole sono conformi al sito web attuale (regione).
6	Il layout del contenuto testuale nelle pagine è privo di errori, indipendente dai caratteri e allineati alle linee.
7	Funzionalità di caratteri speciali, collegamenti ipertestuali e tasti di scelta rapida.
8	Messaggio di convalida per i campi di input.
9	La build generata include tutti i file necessari.
10	La schermata localizzata presenta lo stesso tipo di elementi e numeri di quella del prodotto originale.
11	Assicurarsi che l'interfaccia utente localizzata del software o delle applicazioni web sia confrontabile con l'interfaccia utente di origine nei sistemi operativi e negli ambienti utente di destinazione.
12	L'ordinamento e la classificazione alfabetica seguono le regole della lingua di destinazione, non della lingua di partenza.
13	Le impostazioni locali da destra a sinistra rispecchiano correttamente il layout, inclusi la navigazione, le icone e le stringhe a direzione mista.
14	L'inserimento da tastiera, il controllo ortografico e la ricerca accettano caratteri accentati e multibyte.

Vantaggi dei test di localizzazione

Di seguito sono riportati i vantaggi dei test di localizzazione

• Riduzione dei costi complessivi dei test
• Riduzione complessiva dei costi di supporto
• Aiuta a ridurre il tempo per i test.
• Ha più flessibilità e scalabilità.

Questi risparmi derivano dall'individuazione dei difetti di localizzazione una sola volta, centralmente, invece che una volta per ogni coda di supporto del mercato. Spesso ne conseguono anche vantaggi in termini di accessibilità, perché la stessa disciplina che mantiene intatto un layout sotto stringhe tedesche più lunghe lo mantiene intatto anche sotto testo ingrandito durante test di accessibilità.

Svantaggi dei test di localizzazione

Di seguito sono riportate le sfide dei test di localizzazione

• Richiede un esperto di dominio
• Assumere un traduttore locale spesso rende il processo costoso
• La memorizzazione dei caratteri DBCS varia a seconda del paese
• Un tester potrebbe dover affrontare sfide di pianificazione

La pressione della pianificazione è quella che la maggior parte dei team sottovaluta. La traduzione arriva in ritardo nel ciclo per definizione, quindi i difetti di localizzazione emergono in prossimità del rilascio, che è esattamente il momento in cui una modifica del layout è più costosa. La pianificazione della localizzazione passa nel piano più ampio descritto in tipi di test del software mantiene quella stretta gestibile e il generale test del software L'introduzione illustra la posizione generale della fase.

DOMANDE FREQUENTI