Lokalisatietesten uitvoeren: een stapsgewijze handleiding met praktijkvoorbeelden

De meeste handleidingen voor lokalisatietesten geven u een lijst met fasen en daarmee is de kous af. Plannen, ontwerpen, uitvoeren, hertesten. Het probleem is dat u na het lezen nog steeds geen idee heeft hoe een werkelijke testcase eruitziet, welke bugs u kunt verwachten in het Duits versus Arabisch versus Japans, of dat uw dekking voldoende is om live te gaan.

Deze walkthrough doet het tegenovergestelde. We nemen één functie, een aanmeldproces, en doorlopen vijf concrete stappen in drie doellocaties. Duits voor tekstuitbreiding en telefoonvalidatie. Arabisch voor rechts-naar-links lay-out en tijdzoneverwerking. Japans voor karakterverwerking en datumnotaties. U ziet de testcases die de bugs vangen, de bugtickets waarmee ze worden opgelost en de regressies die de oplossingen veroorzaken in naburige locaties.

Volgens Capital One Shopping ligt de grensoverschrijdende e-commercemarkt op schema om in 2025 ongeveer $1,21 biljoen en in 2030 $1,84 biljoen te bereiken, en onderzoek van VisionGroup met vermelding van CSA Research toont aan dat 76% van de online shoppers liever producten koopt met informatie in hun eigen taal. Lever een kapotte aanmelding op in een nieuwe regio en die omzet loopt de deur uit. Het is ook de reden waarom lokalisatietesten zijn verschoven van een extraatje naar een release-blokkerend checkpoint voor elk team dat uitbreidt buiten de thuismarkt.

Het aanmeldproces dat we testen en waarom het elke veelvoorkomende bug blootlegt

De functie is bewust alledaags. Een e-mailveld, een wachtwoordveld met een sterkte-indicator, een veld voor de volledige naam, een telefoonnummer met landcode, een datumkiezer voor geboortedatum, een land-dropdown, een selectievakje voor marketingtoestemming, een verzendknop, een countdown van “bevestig uw e-mail binnen 24 uur” en een welkomstmail die via de server wordt verzonden.

Elk product heeft wel zoiets. Alles heeft te maken met invoervalidatie, lay-out, datum- en getalnotatie, karaktercodering, tijdzoneberekeningen en microcopy. Dat maakt het de perfecte functie om te laten zien hoe u lokalisatietesten van begin tot eind uitvoert, omdat elke categorie waarin lokalisatie faalt, op hetzelfde scherm samenkomt.

Voordat er met locatiespecifiek werk wordt begonnen, richten we de omgeving correct in. Locatie wordt op OS-niveau gewijzigd, niet alleen in de app. Browser-taalheaders die overeenkomen met de locatie. Native lettertypes geïnstalleerd voor elk script. Echte apparaten voor ten minste één Android, één iOS en twee desktopbrowsers per locatie. Het overslaan van deze configuratie is de meest voorkomende reden waarom teams in productie lay-outbugs vinden die in hun staging-omgeving stilletjes verborgen bleven.

Stap 1: De locatiematrix die markten koppelt aan hun bekende bugs

Het algemene advies is “bepaal uw scope”. Daar heeft u niets aan. De nuttige oefening is het koppelen van elke locatie aan de foutcategorieën waarvoor deze bekendstaat, voordat u ook maar één testcase schrijft. Dit is wat we doen bij elk lokalisatietraject, en het verkort de ontwerptijd van tests met ongeveer een derde.

Voor onze walkthrough ziet de matrix er als volgt uit:

De matrix is de ruggengraat van elke volgende stap. De Duitse kolom vertelt de tester om geobsedeerd te zijn door tekstafbreking en getalpatronen. De Arabische kolom instrueert om te letten op richting en tijdzoneberekeningen aan de serverzijde. De Japanse kolom wijst op het controleren van invoeracceptatie en datumvolgorde. U stopt met het verspillen van moeite aan het verifiëren van zaken die in die locatie nooit stuk zouden gaan.

Stap 2: Testcases geschreven op basis van risico, met de exacte bugs die ze vingen

De meest gemaakte fout die wij in testplannen van klanten zien, is één algemene testcase per landinstelling, geformuleerd als “controleer of het formulier correct wordt verzonden in de doeltaal”. Daar wordt niets mee opgespoord. Een goede testcase benoemt de landinstelling, het veld, het risico en het verwachte resultaat. Hieronder staan zes reële testcases, twee per landinstelling, gebaseerd op de meest risicovolle velden en de bug die elk ervan aan het licht bracht. Zo ziet een bruikbaar voorbeeld van lokalisatietesten er in de praktijk uit.

Duitse testcase 1 — tekstuitbreiding van het selectievakje. Controleer of het label van het selectievakje voor marketingtoestemming de verzendknop niet buiten de zichtbare viewport duwt op een mobiel breekpunt van 375px wanneer het formulier in het Duits wordt weergegeven.

Verwacht: het label loopt door over maximaal twee regels, de verzendknop blijft volledig aanklikbaar.

Gevonden bug: het vertaalde toestemmingslabel liep door over vier regels op een iPhone SE, waardoor de verzendknop onder de vouw (below the fold) werd geduwd.

Duitse testcase 2 — validatie van telefoonnummers. Controleer of het invoerveld voor telefoonnummers een geldig Duits mobiel nummer accepteert (11 cijfers inclusief de +49 landcode, bijv. +49 151 23456789) en alleen daadwerkelijk ongeldige patronen afwijst.

Verwacht: geldige Duitse nummers worden geaccepteerd, ongeldige nummers worden geweigerd met een voor de landinstelling geschikte foutmelding.

Gevonden bug: de validator was hardcoded op 10 cijfers in de Amerikaanse indeling en wees elk geldig Duits nummer af. De foutmelding luidde “telefoonnummer moet 10 cijfers bevatten”, wat voor elke markt buiten Noord-Amerika betekenisloos is.

Arabische testcase 1 — spiegeling van de rechts-naar-links lay-out. Controleer of het volledige aanmeldformulier spiegelt wanneer de landinstelling is ingesteld op Arabisch, inclusief de positie van de landcode bij het telefoonnummer, de volgorde van de iconen bij foutmeldingen en de vulrichting van de meter voor wachtwoordsterkte.

Verwacht: volledige rechts-naar-links spiegeling van elk element.

Gevonden bug: het formulier spiegelde correct, maar de meter voor wachtwoordsterkte vulde nog steeds van links naar rechts. Een sterk Arabisch wachtwoord produceerde een visueel signaal dat voor moedertaalsprekers als “zwak” werd gelezen, omdat zij de balk in de tegenovergestelde richting scannen.

Arabische testcase 2 — tijdzoneverwerking bij de verificatie-afteller. Controleer of de afteller “verifieer uw e-mail binnen 24 uur” de juiste lokale verlooptijd weergeeft voor een gebruiker in Saudi-Arabië (UTC+3, geen zomertijd), en dat de link niet voortijdig verloopt.

Verwacht: de afteller toont de verlooptijd omgerekend naar de lokale tijd in Riyad, en de link blijft geldig gedurende 24 uur vanaf de uitgifte aan serverzijde.

Gevonden bug: de afteller werd weergegeven in UTC, terwijl de onderwerpregel van de e-mail een lokale tijd vermeldde. Saudische gebruikers zagen een discrepantie van drie uur en sommigen klikten op links die door de server als reeds verlopen werden beschouwd vanwege een afzonderlijke caching-bug.

Japanse testcase 1 — invoer van double-byte tekens. Controleer of het veld voor de volledige naam Japanse double-byte tekens accepteert, deze opslaat als UTF-8 en ze correct weergeeft in het succesbericht.

Verwacht: het invoerveld accepteert tot 20 double-byte tekens, de database slaat deze zonder corruptie op en het succesbericht toont de Japanse naam.

Gevonden bug: de invoer accepteerde de tekens in de UI, maar de validatie-regex vereiste alleen Latijnse letters, waardoor verzending werd geblokkeerd met een algemene “ongeldige naam”-fout. Elke Japanse aanmelding zou bij verzending zijn mislukt.

Japanse testcase 2 — datumnotatie in de datumkiezer voor geboortedatum. Controleer of de datumkiezer voor de geboortedatum datums weergeeft in de volgorde JJJJ/MM/DD voor de Japanse landinstelling, en of de vervolgkeuzelijst voor landen gesorteerd is volgens de Japanse leesvolgorde in plaats van de Engelse alfabetische volgorde.

Verwacht: de kiezer leest JJJJ/MM/DD, de vervolgkeuzelijst sorteert landen op hun Japanse namen (Doitsu, niet Germany).

Gevonden bug: de kiezer gaf MM/DD/JJJJ weer, ongeacht de landinstelling, waardoor gebruikers hun geboortejaar in het veld voor de dag invoerden en de validatie faalden. De vervolgkeuzelijst voor landen was gesorteerd op Engelse namen, waardoor Japanse gebruikers moesten zoeken naar “Germany” in plaats van ドイツ.

Elke testcase is één alinea. Elke case benoemt de risicocategorie, het veld en het verwachte gedrag. Dat is de vorm die wij voor elke testcase in uw testsuite willen zien.

Stap 3: Uitvoering op echte apparaten en hoe de bugtickets er daadwerkelijk uitzagen

Een bug gevonden bij lokalisatie is alleen nuttig als de ontwikkelaar ernaar kan handelen zonder te gokken. Drie dingen maken van een vaag ticket een bruikbaar ticket: de brontekst en vertaalde tekst naast elkaar, volledige omgevingsmetadata met screenshots voor elke status, en een tag of de bug betrekking heeft op lay-out, invoer, opmaak, tijdzone of inhoud.

Voor de Duitse telefoonvalidator bevatte het ticket het afgewezen nummer, het regex-patroon uit de codebase, de Duitse validatieregels en een screenshot van het foutbericht. Kritieke ernst, omdat het elke Duitse aanmelding blokkeerde.

Voor de Arabische tijdzone-bug bevatte het ticket een opname van de countdown die in UTC rendert, de onderwerpregel van de e-mail die de lokale tijd toont, en een logboek aan de serverzijde van de verloopdatum van de link. Hoge ernst, omdat gebruikers de toegang verloren tot een proces dat ze al waren gestart.

Voor de Japanse datumkiezer bevatte het ticket een screenshot van de kiezer in de volgorde MM/DD/YYYY, de locatie-instelling die YYYY/MM/DD had moeten activeren, en een apart ticket voor de sorteervolgorde van de land-dropdown. Voor het vangen van bugs van deze diepgang is een mens nodig die sessies op echte apparaten uitvoert; dit is de ruggengraat van het handmatige testproces voor meerdere locaties van QAwerk en de reden waarom volledig geautomatiseerde dekking een hele klasse lokalisatieproblemen mist.

Stap 4: Oplossingen, hertests en de regressies die opduiken in naburige locaties

Het interessante lokalisatiewerk vindt plaats nadat de eerste fix is doorgevoerd, omdat elke oplossing een impact heeft op andere locales die niemand in de oorspronkelijke ticket had gemarkeerd.

De fix voor de Duitse telefoonvalidator verving de hardcoded regel van 10 cijfers door een locale-bewuste library die validatiepatronen per landcode inlaadt. hertesten in het Duits bevestigde de fix. Hertesten in Frankrijk, Italië en het VK bevestigden de fix eveneens. Hertesten in Brazilië onthulde dat de library-versie de update van 2024 voor Braziliaanse nummers niet bevatte, waardoor geldige Braziliaanse mobiele nummers nog steeds niet werden geaccepteerd.

De fix voor de Arabische tijdzone verplaatste de aftelberekening naar client-side rendering met gebruik van de lokale tijdzone van de gebruiker. Hertesten in Riyad bevestigden een correcte weergave. Hertesten in Tokio, dat ook UTC+9 gebruikt zonder zomertijd, bevestigde de fix. Hertesten in Berlijn tijdens een overgang naar zomertijd onthulde echter dat de countdown een uur versprong toen de klok werd verzet, omdat de client-side library de offset cachete bij het laden van het formulier.

De fix voor de Japanse datumkiezer introduceerde een component voor een locale-bewuste datumnotatie. Hertesten in Japan bevestigden JJJJ/MM/DD. Hertesten in China en Korea, die ook JJJJ/MM/DD gebruiken, bevestigden de fix. Hertesten in Iran onthulde echter dat de picker geen ondersteuning bood voor de Perzische kalender, wat een aparte lokalisatievereiste is die verder gaat dan het aanpassen van de notatie.

Dit patroon is precies wat we toepassen op de Keystone-studieportals, waar acht verticale markten zijn gelokaliseerd in meer dan 40 talen en een enkele wijziging in een notatie of validator in de gehele set aan locales opnieuw moet worden getest voordat deze live kan gaan.

Stap 5: Waar automatisering loont en waar handmatig testen nog steeds de voorkeur heeft

Als we terugkijken op de zes bugs die we hebben gevonden, dan had automatisering de meeste daarvan kunnen detecteren. Weten welke bugs geautomatiseerd kunnen worden en welke gemist zouden zijn, vormt de kern van hoe u lokalisatietesten op schaal uitvoert zonder uw QA-budget te overschrijden.

Automatisering had de Duitse telefoonvalidator, de Japanse regex en de Japanse datumkiezer kunnen opvangen. Geparametriseerde functionele tests met locale-specifieke payloads falen duidelijk op deze punten. Automatisering had de Duitse checkbox-overflow kunnen detecteren met een visuele screenshot-vergelijking. Automatisering had de richting van de Arabische sterktemeter of de discrepantie in de Arabische tijdzone bij de countdown echter niet opgemerkt, omdat beide correct rendeerden zonder fouten en alleen een mens die van rechts naar links leest of in UTC+3 woont, zou zien dat dit onjuist was.

Die verhouding geldt voor de meeste lokalisatieprojecten die wij uitvoeren. Ongeveer twee derde van de bugs valt in de categorie die automatiseerbaar is. Het resterende derde deel beslaat culturele geschiktheid, randgevallen bij tijdzoneberekeningen, de toon van de vertaling, bi-directionele content en het soort visuele oordeelsvorming waar automatisering niet toe in staat is. De fout die teams maken, is alles in één mandje stoppen. Of ze testen elke locale bij elke release handmatig en branden het team op, of ze vertrouwen op automatisering om culturele en tijdsgerelateerde problemen op te sporen waarvoor het nooit is gebouwd.

Een helder voorbeeld van deze balans is de lancering van het Escuela Coaching-platform, waar we de Engelse lokalisatie van een product van Spaanse oorsprong hebben geverifieerd binnen een tijdlijn van één maand. Handmatige controle bracht precisieproblemen in vertalingen aan het licht in knopteksten, menu’s, foutmeldingen en informatieve content die bij een geautomatiseerde test niet naar voren zouden zijn gekomen.

Een kant-en-klare set testcases voor uw eigen aanmeldproces

De bovenstaande uitleg gebruikte zes testcases ter illustratie. Een echt aanmeldproces heeft meer dekking nodig voor elke categorie die lokalisatie raakt: tekstuitbreiding, lay-out van rechts naar links, karakterverwerking, datum- en getalnotaties, valuta, telefoonvalidatie, adresnotaties, tijdzones, werktijden en lokale betaalmethoden als uw proces doorloopt tot de checkout.

Wij gebruiken een sjabloon van 18 testcases wanneer we dit uitvoeren voor klantprojecten, zes per locale, waarbij alle bovengenoemde categorieën worden afgedekt. Elke case heeft een vaste structuur: casenaam, locale, veld dat wordt getest, risicocategorie, randvoorwaarden, stappen, verwacht resultaat en ernst bij falen. Het sjabloon is locale-agnostisch, dus het toevoegen van een nieuwe markt zoals Pools, Turks of Hebreeuws is een kwestie van datasets verwisselen in plaats van de hele suite herschrijven. Neem contact op als u wilt dat we het sjabloon aanpassen aan uw product.

Het vijfstappenpatroon, toegepast op elke locale die u toevoegt

Het patroon blijft hetzelfde naarmate uw lijst met markten groeit. Identificeer de faalcategorieën waar de locale om bekend staat. Schrijf testcases voor elke categorie, niet generiek voor het hele formulier. Voer tests uit op echte apparaten en log bugs met de bron, vertaling, omgeving en context van de tijdzone naast elkaar. Hertest de naburige locales na elke fix, omdat regressie zelden opduikt waar u het verwacht. Automatiseer de herhaalbare lagen en laat mensen de oordelende taken uitvoeren.

Lokalisatietesten is de onopvallende stap die bepaalt of uw volgende markt openbreekt of sluit. Een gebruiker die tegen een kapotte aanmelding in de eigen taal aanloopt, een telefoonfout krijgt in een notatie die hij niet kan begrijpen, of een verificatielink drie uur te vroeg ziet verlopen, meldt geen bug. Hij vertrekt naar een concurrent wiens product eruitziet alsof het echt voor hem is gebouwd. Als het uitvoeren van deze matrix over drie of dertig locales zwaarder klinkt dan uw team aankan, neem contact met ons op en dan bepalen we samen de scope.