Qu'est-ce qu'un test de localisation ? Exemples de cas de test et liste de contrôle

Test de localisation

Test de localisation est une technique de test de logiciels dans laquelle le comportement d'un logiciel est testé pour une région, un lieu ou une culture spécifique. Le but des tests de localisation d'un logiciel est de tester les aspects linguistiques et culturels appropriés pour une région particulière. Il s'agit du processus de personnalisation du logiciel en fonction de la langue et du pays ciblés.

Le principal domaine affecté par les tests de localisation comprend le contenu et l’interface utilisateur.

Il s'agit d'un processus de test d'une application mondialisée dont l'interface utilisateur, la langue par défaut, la devise, la date, le format de l'heure et la documentation sont conçus en fonction du pays ou de la région ciblé. Cela garantit que l’application est suffisamment performante pour être utilisée dans ce pays particulier.

Exemple :

1. Si le projet est conçu pour l'État du Tamil Nadu en Inde, le projet conçu doit être en langue tamoule, un clavier virtuel tamoul doit être présent, etc.

2. Si le projet est conçu pour les États-Unis, le format de l'heure doit être modifié en fonction de l'heure standard des États-Unis. En outre, la langue et le format monétaire doivent suivre les normes américaines.

L'illustration ci-dessous montre le même produit adapté à différentes régions, la langue, la devise et les règles de mise en forme changeant tandis que la structure sous-jacente reste la même.

Pourquoi effectuer des tests de localisation ?

Le but des tests de localisation est de vérifier les aspects linguistiques et culturels appropriés pour un lieu particulier. Cela inclut une modification de l’interface utilisateur ou même des paramètres initiaux en fonction des exigences.

Dans ce type de test, de nombreux testeurs différents répéteront les mêmes fonctions. Ils vérifient diverses choses comme les erreurs typographiques, la pertinence culturelle de l'assurance-chômage, les erreurs linguistiques, etc.

On l'appelle aussi « L10N » car il y a 10 caractères entre le L et le N dans le mot localisation.

Il existe également une raison commerciale à cette démarche. Une étiquette mal traduite ou une date affichée comme mars au lieu d'avril (03/04) érodent la confiance sur un marché pour lequel une équipe a déjà investi, et ces défauts sont détectés par un testeur sur place plutôt que par l'équipe de test. Tests d'interface graphique interprété en anglais.

Tests de localisation vs tests d'internationalisation

Ces deux activités sont séquentielles et non concurrentes. Les tests d'internationalisation (I18N) confirment que le code source peut accepter n'importe quelle langue ; les tests de localisation (L10N) confirment ensuite qu'une langue spécifique est correcte.

Tests de localisation (L10N)	Tests d'internationalisation (I18N)
Vérifie que le produit est perçu comme natif dans une région cible.	Vérifie que le produit peut prendre en charge de nombreuses régions sans redéveloppement
Vérifie le texte traduit, la devise, la date, l'heure et l'adéquation culturelle	Vérifie l'encodage des caractères, l'externalisation des chaînes et le code prenant en compte les paramètres régionaux
S'exécute une fois que la version traduite pour ce marché existe	Exécute en premier, avant que tout texte ne soit envoyé pour traduction.
Il faut un testeur ou un relecteur qui connaisse la langue locale.	Peut être réalisé par l'équipe principale à l'aide de versions pseudo-traduites.

Consultez ce tutoriel pour une différence entre les tests de localisation et de mondialisation.

Comment faire des tests de localisation

Pour un test de localisation typique, nous mettons en place des tests de vérification de build, Essais fonctionnels, Les tests de régression, et approbation finale.

1. Les tests de vérification de build sont un petit sous-ensemble de test fonctionel, qui est effectuée avant que l'assurance qualité ne commence par des tests détaillés. Elle est proche dans son esprit de test de fumée: la version localisée est rapidement rejetée si le pack de langue ne parvient pas à se charger.

2. Les tests normaux sont l'étape permettant d'exécuter les scénarios de test normaux et de rechercher les défauts du journal pendant l'exécution.

3. Les tests de régression sont Défaut processus de régression pour garantir que le défaut est corrigé sans qu’il n’y ait d’impact des défauts corrigés sur les zones environnantes.

4. L'approbation finale consiste à effectuer la vérification finale de la construction avant la livraison au client.

Chaque phase est répétée pour chaque langue, et non une seule fois pour l'ensemble du produit. Un défaut corrigé dans la version française doit également être réintégré dans les versions allemande et japonaise, car la même ressource de chaîne de caractères est souvent partagée entre elles.

Automatisation des tests de localisation

Si le projet est grand et doit être testé souvent, alors nous optons pour Tests d'automatisation.

• Choisissez un outil d'automatisation pour écrire des scripts.
• Prenons le scénario à tester pour la stratégie de localisation.
• Écrivez des scripts en fonction de cela.
• Collectez les résultats et mettez à jour le scénario en tant que Réussite/Échec.

À noter: Selenium est l'un des outils pionniers dans ce domaine. Il est très riche en fonctionnalités, mais son utilisation nécessite plus de connaissances techniques.

L'automatisation a ses limites, qu'il convient de rappeler. Un script peut prouver qu'un symbole monétaire a changé et qu'aucune chaîne de caractères n'est tronquée, mais il ne peut juger de la fluidité d'une traduction ni du caractère inapproprié d'une icône. Les vérifications automatiques gèrent l'aspect technique ; seul un relecteur natif peut garantir l'aspect linguistique.

Outils de test de localisation

Le travail de localisation fait appel à trois catégories d'outils différentes, et la plupart des équipes finissent par utiliser les trois.

• Cadres d'automatisation fonctionnelle : Selenium, Appium et les frameworks comparables réexécutent la même suite de tests sur chaque version locale, ce qui représente la majeure partie des vérifications répétitives.
• Systèmes de gestion de traduction : Les plateformes qui hébergent les ressources de chaînes de caractères permettent aux traducteurs, aux développeurs et aux testeurs de travailler à partir d'un seul glossaire, afin qu'un terme ne soit pas traduit de deux manières différentes sur deux écrans différents.
• Utilitaires de pseudo-localisation : Ces éléments remplacent les chaînes de caractères anglaises par des espaces réservés accentués et allongés avant le début de la traduction proprement dite, révélant ainsi un texte et une mise en page codés en dur qui ne peuvent pas absorber des mots plus longs.

La compatibilité avec les appareils et les navigateurs est tout aussi importante que l'outil lui-même. Les polices, les méthodes de saisie et les paramètres régionaux par défaut diffèrent d'une plateforme à l'autre ; il est donc indispensable de tester la version localisée sur de véritables appareils cibles lors de la phase de test. test mobile et dans l'ensemble du navigateur défini pour tests d'applications Web.

Liste de contrôle des meilleures pratiques pour les tests de localisation

• Faites appel à une agence de localisation spécialisée en ingénierie i18n
• Assurez-vous que votre stratégie de test de localisation accorde plus de temps pour les langues à deux octets.
• Assurez-vous d'internationaliser correctement votre code pour le DBCS avant extracenvoyer tout texte à traduire
• Commencez par externaliser chaque chaîne de caractères dans des fichiers de ressources, afin qu'aucun texte visible par l'utilisateur ne reste codé en dur dans le code source.
• Lancez une version pseudo-localisée dès que possible, car elle met en évidence les troncatures et le texte codé en dur avant même que l'argent de la traduction ne soit dépensé.
• Réservez de l'espace dans la mise en page pour l'extension du texte, car les traductions de l'anglais sont souvent plus longues que l'étiquette originale.
• Testez les paramètres régionaux s'écrivant de droite à gauche, comme l'arabe et l'hébreu, sur de vrais écrans, là où les mises en page en miroir et les textes à sens mixte échouent le plus souvent.
• Maintenir un guide de style par langue et région couvrant l'ordre des dates, les séparateurs décimaux, le format des adresses, les titres honorifiques et le ton.
• Faites relire les captures d'écran finales par un locuteur natif, car l'adéquation culturelle ne peut être garantie par un script.

Deux de ces éléments dépendent de la plateforme plutôt que de la langue, c'est pourquoi les versions localisées sont généralement planifiées en parallèle. test de compatibilité et tests de configuration plutôt que d'après eux.

Exemples de cas de test pour les tests de localisation

Le tableau ci-dessous présente un ensemble initial de chèques. Chaque ligne devient un chèque complet. cas de test une fois que le résultat attendu pour la localisation spécifique est renseigné.

S.No	Cas de test Description CMS
1	Des glossaires sont disponibles pour référence et vérification.
2	L'heure et la date sont correctement formatées pour la région cible.
3	Les formats de numéros de téléphone sont propres à la région cible.
4	Devise de la région cible.
5	La licence et les règles obéissent-elles au site Web (région) actuel.
6	La disposition du contenu du texte dans les pages est sans erreur, indépendante des polices et des alignements de lignes.
7	Caractères spéciaux, hyperliens et fonctionnalités de raccourcis clavier.
8	Message de validation pour les champs de saisie.
9	La version générée comprend tous les fichiers nécessaires.
10	L'écran localisé présente le même type d'éléments et de numéros que celui du produit source.
11	Assurez-vous que l’interface utilisateur localisée des logiciels ou des applications Web se compare à l’interface utilisateur source des systèmes d’exploitation et des environnements utilisateur cibles.
12	Le tri et le classement alphabétique suivent les règles de la langue cible, et non celles de la langue source.
13	Les paramètres régionaux s'écrivant de droite à gauche reflètent correctement la mise en page, y compris la navigation, les icônes et les chaînes de caractères à sens mixte.
14	La saisie au clavier, la correction orthographique et la recherche acceptent les caractères accentués et multi-octets.

Avantages des tests de localisation

Voici les avantages des tests de localisation

• Réduction du coût global des tests
• Réduction globale des coûts de support
• Aide à réduire le temps de test.
• Il a plus de flexibilité et d’évolutivité.

Ces économies proviennent de la détection centralisée des défauts de localisation, au lieu de les traiter un par un dans la file d'attente du support technique. Des gains d'accessibilité en découlent souvent également, car la même rigueur qui préserve la mise en page lors de l'affichage de longs textes en allemand la préserve aussi lors de l'agrandissement du texte. test d'accessibilité.

Inconvénients des tests de localisation

Voici les défis des tests de localisation

• Nécessite un expert du domaine
• L'embauche d'un traducteur local rend souvent le processus coûteux
• Le stockage des caractères DBCS diffère selon les pays
• Un testeur peut être confronté à des problèmes d'horaire

La pression liée au calendrier est celle que la plupart des équipes sous-estiment. La traduction arrive par définition tard dans le cycle, si bien que les défauts de localisation apparaissent peu avant la mise en production, soit précisément au moment où une modification de la mise en page est la plus coûteuse. La planification de la localisation s'intègre au plan global décrit dans types de tests logiciels permet de gérer cette pression et, en général, test logiciel L'introduction explique où se situe globalement cette phase.

FAQ