La plupart des guides de tests de localisation vous donnent une liste d’étapes et c’est tout. Planifier, concevoir, exécuter, tester à nouveau. Le problème, c’est qu’après avoir lu le guide, vous n’avez toujours aucune idée de ce à quoi ressemble un cas de test concret, du type de bug auquel vous pouvez vous attendre en allemand, en arabe ou en japonais, ni même si votre couverture de test est suffisante pour la mise en production.
Cette démonstration fait l’inverse. Nous prenons une fonctionnalité, le processus d’inscription, et la testons en cinq étapes concrètes dans trois langues cibles : l’allemand pour l’expansion du texte et la validation du numéro de téléphone ; l’arabe pour la mise en page de droite à gauche et la gestion des fuseaux horaires ; et le japonais pour la gestion des caractères et les formats de date. Vous verrez les cas de test qui détectent les bogues, les tickets de bogues qui permettent de les corriger, et les régressions que les correctifs engendrent dans les langues voisines.
D’après Capital One Shopping, le marché du e-commerce transfrontalier devrait atteindre environ 1 210 milliards de dollars en 2025 et 1 840 milliards de dollars d’ici 2030. Une étude de VisionGroup, citant CSA Research, révèle que 76 % des acheteurs en ligne préfèrent acheter des produits dont les informations sont disponibles dans leur langue maternelle. Envoyer un formulaire d’inscription défectueux dans une nouvelle zone géographique, c’est s’exposer à une perte de revenus considérable. C’est aussi pourquoi les tests de localisation sont passés d’un atout appréciable à un point de contrôle bloquant la mise en production pour toute équipe s’étendant au-delà de son marché national.
Le processus d'inscription que nous testons et pourquoi il révèle tous les bugs courants
La fonctionnalité est délibérément ordinaire. Un champ e-mail, un champ de mot de passe avec un indicateur de force, un champ de nom complet, un numéro de téléphone avec indicatif pays, un sélecteur de date de naissance, un menu déroulant de pays, une case à cocher de consentement marketing, un bouton de soumission, un compte à rebours « vérifiez votre e-mail dans les 24 heures » et un e-mail de bienvenue envoyé côté serveur.
Chaque produit en a un. Chacun touche la validation des entrées, la mise en page, le formatage des dates et des nombres, l’encodage des caractères, les calculs de fuseaux horaires et la microcopy. Cela en fait la fonctionnalité parfaite pour montrer comment effectuer des tests de localisation de bout en bout car chaque catégorie où la localisation se casse se trouve sur le même écran.
Avant tout travail spécifique au paramètre régional, nous configurons l’environnement correctement. Le paramètre régional est changé au niveau de l’OS, pas seulement dans l’application. Les en-têtes de langue du navigateur correspondent au paramètre régional. Les polices natives sont installées pour chaque script. De vrais appareils pour au moins un Android, un iOS et deux navigateurs desktop par paramètre régional. Sauter cette configuration est la raison la plus courante pour laquelle les équipes trouvent des bogues de mise en page en production que leur environnement de staging avait silencieusement cachés.
Étape 1 : La matrice de localisation qui associe les marchés aux bugs qui leur sont connus
Le conseil générique est « définissez votre périmètre ». Cela ne vous dit rien. L’exercice utile consiste à mapper chaque paramètre régional aux catégories de défaillance pour lesquelles il est connu, avant d’écrire un seul cas de test. C’est ce que nous faisons sur chaque engagement de localisation, et cela réduit le temps de conception des tests d’environ un tiers.
Pour notre parcours, la matrice ressemble à ceci :
Allemand (Allemagne)
Expansion de texte, validation du numéro de téléphone
Étiquette de case à cocher de consentement, saisie téléphonique, bouton de soumission
Arabe (Arabie saoudite)
Miroir de droite à gauche, gestion des fuseaux horaires
Indicatif pays du téléphone, indicateur de force, compte à rebours e-mail
Japonais (Japon)
Saisie en double octet, conventions de format de date
Champ de nom complet, sélecteur de date de naissance, menu déroulant de pays
La matrice est la colonne vertébrale de chaque étape ultérieure. La colonne allemande dit au testeur de se concentrer sur le retour à la ligne et les schémas de nombres. La colonne arabe lui dit de se concentrer sur la direction et les calculs de temps côté serveur. La colonne japonaise lui dit de se concentrer sur l’acceptation des entrées et l’ordre des dates. Vous arrêtez de perdre du temps à vérifier des choses qui n’allaient jamais se casser dans ce paramètre régional.
Étape 2 : Cas de test rédigés en tenant compte des risques, avec les bogues exacts détectés
L’erreur la plus fréquente que nous constatons dans les plans de test client est la présence d’un seul cas de test générique par langue, formulé comme « vérifier la soumission du formulaire dans la langue cible ». Cette approche est inefficace. Un cas de test correct spécifie la langue, le champ, le risque et le résultat attendu. Vous trouverez ci-dessous six cas de test réels, deux par langue, rédigés pour les champs à haut risque et le bogue qu’ils ont permis de détecter. Voici un exemple concret de test de localisation utile.
Cas de test allemand 1 — expansion du texte de la case à cocher. Vérifier que l’étiquette de la case à cocher de consentement marketing ne pousse pas le bouton de soumission en dehors du viewport visible sur un point de rupture mobile de 375px quand le formulaire est affiché en allemand.
Attendu : l’étiquette se replie sur un maximum de deux lignes, le bouton de soumission reste entièrement cliquable.
Bogue trouvé : l’étiquette de consentement traduite s’est repliée sur quatre lignes sur iPhone SE, poussant le bouton de soumission sous le pli.
Cas de test allemand 2 — validation du numéro de téléphone. Vérifier que la saisie téléphonique accepte un numéro de mobile allemand valide (11 chiffres incluant l’indicatif pays +49, ex. +49 151 23456789) et rejette uniquement les schémas véritablement invalides.
Attendu : les numéros allemands valides passent, les invalides échouent avec un message d’erreur adapté au paramètre régional.
Bogue trouvé : le validateur était codé en dur sur 10 chiffres au format américain et rejetait chaque numéro allemand valide. Le message d’erreur indiquait « le numéro de téléphone doit comporter 10 chiffres », ce qui n’a aucun sens sur tout marché en dehors de l’Amérique du Nord.
Cas de test arabe 1 — miroir de mise en page de droite à gauche. Vérifier que l’ensemble du formulaire d’inscription se met en miroir quand le paramètre régional est défini sur l’arabe, y compris la position de l’indicatif pays sur la saisie téléphonique, l’ordre des icônes sur les états d’erreur et la direction de remplissage de l’indicateur de force du mot de passe.
Attendu : miroir complet de droite à gauche sur chaque élément.
Bogue trouvé : le formulaire s’est mis en miroir correctement, mais l’indicateur de force du mot de passe se remplissait toujours de gauche à droite. Un mot de passe arabe fort produisait un signal visuel lu comme « faible » par les utilisateurs natifs car ils lisent la barre dans la direction opposée.
Cas de test arabe 2 — gestion du fuseau horaire sur le compte à rebours de vérification. Vérifier que le compte à rebours « vérifiez votre e-mail dans les 24 heures » affiche l’heure d’expiration locale correcte pour un utilisateur en Arabie saoudite (UTC+3, pas d’heure d’été), et que le lien n’expire pas prématurément.
Attendu : le compte à rebours affiche l’heure d’expiration convertie en heure locale de Riyad, et le lien reste valide pendant 24 heures complètes depuis l’émission côté serveur.
Bogue trouvé : le compte à rebours s’affichait en UTC tandis que la ligne d’objet de l’e-mail indiquait une heure locale. Les utilisateurs saoudiens ont vu une divergence de trois heures et certains ont cliqué sur des liens que le serveur traitait comme déjà expirés à cause d’un bogue de cache distinct.
Cas de test japonais 1 — saisie de caractères en double octet. Vérifier que le champ de nom complet accepte les caractères japonais en double octet, les stocke en UTF-8 et les affiche correctement dans le message de succès.
Attendu : la saisie accepte jusqu’à 20 caractères en double octet, la base de données les stocke sans corruption et le message de succès affiche le nom japonais.
Bogue trouvé : la saisie acceptait les caractères au niveau de l’interface, mais l’expression régulière de validation ne requiérait que des lettres latines, bloquant la soumission avec une erreur générique « nom invalide ». Chaque inscription japonaise aurait échoué à la soumission.
Cas de test japonais 2 — format de date dans le sélecteur de date de naissance. Vérifier que le sélecteur de date de naissance affiche les dates dans l’ordre AAAA/MM/JJ pour le paramètre régional japonais, et que le menu déroulant des pays est trié par ordre de lecture japonais plutôt que par ordre alphabétique anglais.
Attendu : le sélecteur lit AAAA/MM/JJ, le menu déroulant trie les pays par leurs noms japonais (Doitsu, pas Germany).
Bogue trouvé : le sélecteur affichait MM/JJ/AAAA quel que soit le paramètre régional, amenant les utilisateurs à saisir leur année de naissance dans le champ du jour et à échouer la validation. Le menu déroulant des pays était trié par noms anglais, obligeant les utilisateurs japonais à chercher « Germany » au lieu de ドイツ.
Chaque cas est un paragraphe. Chacun nomme la catégorie de risque, le champ et le comportement attendu. C’est la forme que nous voulons que chaque cas de test de votre suite prenne.
Étape 3 : Exécution sur des appareils réels et aperçu des tickets de bogues
Un bogue trouvé en localisation n’est utile que si le développeur peut agir dessus sans deviner. Trois choses transforment un ticket vague en un ticket exploitable : la chaîne source et la chaîne traduite côte à côte, les métadonnées complètes de l’environnement avec des captures d’écran pour chaque état, et un tag indiquant si le bogue est de mise en page, saisie, format, fuseau horaire ou contenu.
Pour le validateur de téléphone allemand, le ticket incluait le numéro rejeté, le schéma d’expression régulière de la base de code, les règles de validation allemandes et une capture d’écran du message d’erreur. Sévérité critique, car il bloquait chaque inscription allemande.
Pour le bogue de fuseau horaire arabe, le ticket incluait un enregistrement du rendu du compte à rebours en UTC, la ligne d’objet de l’e-mail montrant l’heure locale et un journal côté serveur de l’horodatage d’expiration du lien. Sévérité élevée, car les utilisateurs perdaient l’accès à un flux qu’ils avaient déjà commencé.
Pour le sélecteur de date japonais, le ticket incluait la capture d’écran du sélecteur dans l’ordre MM/JJ/AAAA, le paramètre de paramètre régional qui aurait dû déclencher AAAA/MM/JJ et un ticket séparé pour l’ordre de tri du menu déroulant des pays. La détection de bugs de cette profondeur nécessite l’intervention d’un humain effectuant des sessions sur de véritables appareils, ce qui constitue la base du processus de test manuel multilingue de QAwerk et explique pourquoi la couverture entièrement automatisée passe à côté de toute une catégorie de problèmes de localisation.
Étape 4 : Correctifs, nouveaux tests et régressions qui apparaissent dans les régions voisines
Le travail de localisation intéressant se produit après l’arrivée du premier correctif, car chaque correctif a un rayon d’explosion à travers les paramètres régionaux que personne n’avait signalé dans le ticket original.
Le correctif du validateur de téléphone allemand a remplacé la règle codée en dur à 10 chiffres par une bibliothèque sensible au paramètre régional qui charge les schémas de validation par indicatif pays. Le retest en allemand a confirmé le correctif. Le retest en France, Italie et au Royaume-Uni a confirmé le correctif. Le retest au Brésil a révélé que la version de la bibliothèque n’incluait pas la mise à jour du format de numéro brésilien 2024, donc les numéros mobiles brésiliens valides échouaient toujours.
Le correctif du fuseau horaire arabe a déplacé le calcul du compte à rebours vers le rendu côté client en utilisant le fuseau horaire local de l’utilisateur. Le retest à Riyad a confirmé l’affichage correct. Le retest à Tokyo, qui est UTC+9 sans heure d’été non plus, a confirmé le correctif. Le retest à Berlin lors d’une transition d’heure d’été a révélé que le compte à rebours sautait d’une heure lors du changement d’horloge, car la bibliothèque côté client mettait en cache le décalage au chargement du formulaire.
Le correctif du sélecteur de date japonais a introduit un composant de format de date sensible au paramètre régional. Le retest au Japon a confirmé AAAA/MM/JJ. Le retest en Chine et en Corée, qui utilisent également AAAA/MM/JJ, a confirmé le correctif. Le retest en Iran a révélé que le sélecteur ne prenait pas en charge le calendrier persan, ce qui est une exigence de localisation distincte au-delà de la réorganisation des formats.
Ce schéma est exactement ce que nous exécutons sur les portails d’étude Keystone, où huit verticaux sont localisés en plus de 40 langues et un seul changement de format ou de validateur doit être retesté dans l’ensemble des paramètres régionaux avant de pouvoir être livré.
Étape 5 : Là où l'automatisation est rentable et là où le manuel reste gagnant
En revoyant les six bogues que nous avons détectés, l’automatisation en aurait trouvé la plupart. Savoir lesquels et lesquels elle aurait ratés est au cœur de la façon d’effectuer des tests de localisation à grande échelle sans brûler votre budget QA.
L’automatisation aurait détecté le validateur de téléphone allemand, l’expression régulière japonaise et le sélecteur de date japonais. Les tests fonctionnels paramétrés avec des payloads spécifiques au paramètre régional échouent bruyamment sur ces cas. L’automatisation aurait détecté le dépassement de la case à cocher allemande avec un diff de captures d’écran. L’automatisation n’aurait pas détecté la direction de l’indicateur de force arabe ni la divergence de fuseau horaire arabe sur le compte à rebours, car les deux s’affichaient sans erreurs et seul un humain lisant de droite à gauche ou vivant en UTC+3 les aurait enregistrés comme erronés.
Ce ratio se maintient dans la plupart des projets de localisation que nous exécutons. Environ deux tiers des bogues tombent dans le seau automatable. Le tiers restant couvre l’adéquation culturelle, les cas limites de calcul de fuseau horaire, le ton de la traduction, le contenu bidirectionnel et le type de jugements visuels que l’automatisation ne peut pas faire. L’erreur que font les équipes est de tout mettre dans un seul seau. Soit ils retestent manuellement chaque paramètre régional à chaque publication et épuisent l’équipe, soit ils font confiance à l’automatisation pour signaler des problèmes culturels et de timing qu’elle n’a jamais été conçue pour attraper.
Un exemple clair de cet équilibre est la plateforme Escuela Coaching, où nous avons vérifié la localisation anglaise d’un produit d’origine espagnole sur un calendrier d’un mois. La revue manuelle a détecté des problèmes de précision de traduction dans le texte des boutons, les menus, les messages d’erreur et le contenu informatif qu’aucun passage automatisé n’aurait fait remonter.
Un ensemble de cas de test prêts à l'emploi pour votre propre flux d'inscription
Le parcours ci-dessus utilisait six cas de test à titre d’illustration. Un vrai flux d’inscription a besoin d’une couverture plus large dans chaque catégorie que la localisation touche : expansion du texte, mise en page de droite à gauche, gestion des caractères, formats de date et de nombre, devise, validation téléphonique, formats d’adresse, fuseaux horaires, heures de travail et méthodes de paiement locales si votre flux s’étend jusqu’au paiement.
Nous utilisons un modèle de 18 cas de test lors de son exécution sur des projets clients, six par paramètre régional, couvrant chaque catégorie ci-dessus. Chaque cas a une structure fixe : nom du cas, paramètre régional, champ testé, catégorie de risque, conditions préalables, étapes, résultat attendu, sévérité en cas d’échec. Le modèle est indépendant du paramètre régional, donc ajouter un nouveau marché comme le polonais, le turc ou l’hébreu est une question de remplacement de jeux de données plutôt que de réécriture de la suite. Contactez-nous si vous souhaitez le modèle adapté à votre produit.
Le modèle en cinq étapes, appliqué à toute langue que vous ajoutez ensuite
Le schéma reste le même à mesure que votre liste de marchés grandit. Identifiez les catégories de défaillance pour lesquelles le paramètre régional est connu. Écrivez des cas de test contre chaque catégorie, pas contre le formulaire génériquement. Exécutez sur de vrais appareils et journalisez les bogues avec le contexte source, traduction, environnement et fuseau horaire côte à côte. Retestez les paramètres régionaux voisins après chaque correctif, car la régression apparaît rarement là où vous l’attendez. Automatisez les couches répétables et gardez les humains sur les couches de jugement.
Les tests de localisation sont l’étape peu glamour qui décide si votre prochain marché s’ouvre ou se ferme. Un utilisateur qui rencontre une inscription cassée dans sa langue, obtient une erreur téléphonique dans un format qu’il ne peut pas analyser, ou regarde un lien de vérification expirer trois heures plus tôt ne dépose pas de bogue. Il part chez un concurrent dont le produit semble avoir été vraiment construit pour lui. Si exécuter cette matrice sur trois ou trente paramètres régionaux semble plus lourd que ce que votre équipe peut absorber, contactez-nous et nous le définirons ensemble.
Découvrez comment l’équipe QA de QAwerk maintient 40+ versions localisées stables sur 8 verticaux pour un portail d’enseignement supérieur avec 110 millions de visites annuelles.
