Wanneer een product in een nieuwe taal wordt uitgebracht, is de vertaling zelf bijna nooit de oorzaak van problemen. De woorden zijn meestal in orde. Wat wel problemen geeft, is de knop die niet meer past, het afrekenproces dat een lokaal datumnotatie afwijst, het scherm dat links uitgelijnd blijft terwijl het gespiegeld zou moeten worden, en de kleur die in de nieuwe markt een totaal andere betekenis heeft. Het opsporen van dergelijke problemen is de taak van lokalisatie-QA-testen. Het is de reden waarom teams die internationaal serieus van start willen gaan, vóór de release – en niet pas nadat de eerste negatieve recensies binnenstromen – professionele lokalisatie-testdiensten inschakelen.
Dit artikel behandelt wat lokalisatie-QA inhoudt, de vier categorieën fouten die een QA-team opspoort, wie dit werk uitvoert en waarom het essentieel is voor groei.
Wat is lokalisatie-testen en waar past lokalisatie-QA?
Lokalisatie-testen is het proces waarbij wordt geverifieerd of een product dat vertaald en aangepast is voor een specifieke regio, in die regio ook daadwerkelijk goed werkt. Hierbij wordt de draaiende software gecontroleerd, niet alleen het tekstbestand dat de vertaler heeft aangeleverd. Lokalisatie-QA-testen trekt dit breder naar een kwaliteitsdiscipline: een gestructureerde, herhaalbare controle van taal, lay-out, functionaliteit en cultuur voor elke regio die u ondersteunt.
Vaak is er onduidelijkheid over de verschillende rollen. Een vertaler produceert de tekst in de doeltaal. Een lokalisatie-QA-tester verifieert of de vertaalde tekst correct reageert zodra deze in het product wordt geladen, op echte apparaten en via echte gebruikersstromen. Lokalisatie-QA ligt daarom dichter bij functionele en UI-testen met een taalkundige en culturele blik dan bij vertaalwerk. De twee rollen vullen elkaar aan, maar het is niet hetzelfde werk. Wie ze als inwisselbaar beschouwt, riskeert dat defecte builds de productie bereiken.
De vier foutcategorieën die een lokalisatie-QA-team opspoort
De meeste lokalisatiefouten vallen in één van de vier onderstaande categorieën. Het is nuttig om ze te benoemen, omdat voor elke categorie een specifieke vorm van aandacht vereist is; een team dat zich slechts op één type richt, zal de andere drie over het hoofd zien.
Taalkundig
Tekst ontbreekt, is onjuist of staat buiten context
Een tekstreeks die in de brontaal is blijven staan of een term die vreemd overkomt na een automatische vertaling
Een tester met een moedertaalniveau in die taal
Visueel / lay-out
Vertaalde tekst verstoort de interface
Een afgekapt Duits knoplabel of een Arabisch scherm dat niet van rechts naar links spiegelt
Een tester die de build controleert op echte apparaten
Functioneel
Gelokaliseerde invoer of uitvoer werkt niet meer
Een datumformaat dat een geldige checkout blokkeert, of een regiospecifieke link die een foutmelding geeft
Een tester die landspecifieke testgevallen uitvoert
Cultureel
Inhoud leest onjuist of aanstootgevend
Een kleur, icoon of afbeelding die de verkeerde betekenis heeft in een doelmarkt
Een tester met regionale en culturele kennis
Taalkundige fouten: ontbrekende teksten en afwijkingen door machinevertaling
De meest voorkomende bug die een localization QA-tester logt, is ook de minst dramatische: een tekst die nooit is vertaald, of een tekst die is vertaald in iets wat een moedertaalspreker nooit zou zeggen. Machinevertaling maakt dit vaker voor, niet minder, omdat volume fouten verhult. Tijdens de ondersteuning van Keystone, het toonaangevende studieportaal van Noorwegen met inhoud in meer dan 40 gelokaliseerde versies, merkt ons team dat een aanzienlijk deel van de bugs die we loggen precies in deze categorie valt. Om bij te blijven, hebben we de taalkundige scan gedeeltelijk geautomatiseerd met een script dat elke pagina binnen de verticals doorloopt en vertaalfouten logt in één enkel bestand voor beoordeling.
Visuele en lay-outfouten: tekst die uit de ruimte groeit
Vertaalde tekst beslaat zelden dezelfde ruimte als het origineel. Duits en Nederlands kunnen tekst met 35% of meer laten uitzetten, en korte labels zetten het meest uit, wat de reden is dat een net Engels knoplabel zoals “Submit” kan overstromen zodra het een langer samengesteld woord in een andere taal wordt.
Het W3C documenteert dit duidelijk: hoe korter de brontekst, hoe groter de kans op uitzetting, en talen zoals Duits vormen lange woorden waar Engels meerdere korte gebruikt. Dezelfde foutencategorie omvat rechts-naar-links-scripts, waarbij een Arabische of Hebreeuwse lay-out die niet goed gespiegeld is, iconen, navigatie en uitlijning de verkeerde kant op laat wijzen. Geen van deze zijn vertaalfouten. Het zijn interfacefouten die pas aan het licht komen zodra de vertaling is toegepast.
Functionele fouten: het datumnotatie-probleem dat de checkout blokkeerde
In deze categorie houdt lokalisatie op cosmetisch te zijn. Wanneer een regio de datumnotatie, het valutascheidingsteken of de invoervalidatieregels wijzigt, kunnen formulieren en transacties daadwerkelijk falen.
Hoe voert u hier lokalisatietesten uit? Bij het testen van ICONOMI, een in Londen gevestigd platform voor crypto-assetbeheer, besteedde QAwerk veel aandacht aan foutmeldingen, datumnotaties en invoervalidatie per regio, aangezien registratie- en verificatieprocessen zich anders gedragen afhankelijk van waar de gebruiker zich bevindt. Om die gelokaliseerde teksten en formaten efficiënt te verifiëren, vertrouwde het team op Spling, waarbij werd gecontroleerd of foutmeldingen, datums en validaties standhielden in elke ondersteunde taal.
Het werk aan Keystone bracht een gerelateerde functionele bug aan het licht: het klikken op de link naar de Privacyverklaring in de Arabische lokalisatie veroorzaakte een client-side fout en stuurde gebruikers naar een foutpagina.
Culturele fouten: het symbool dat een markt beledigde
De meest subtiele categorie heeft niets te maken met of de software draait. Een kleur kan in de ene markt feest betekenen en in de andere rouw, en een icoon, een handgebaar of een stockfoto kan thuis neutraal overkomen en in het buitenland ongepast. Deze defecten veroorzaken geen fout, dus geautomatiseerde controles missen ze. Games merken dit sterk omdat zoveel betekenis afhangt van beeldspraak, plaatsing en toon. Daarom behandelt game-lokalisatietesten culturele aansluiting als een essentieel punt en niet als een voetnoot.
Plaatsing heeft ook cultureel gewicht, en geautomatiseerde systemen zijn daar blind voor. Toen Pokémon Go in 2016 werd gelanceerd, genereerde het PokéStops en gyms op basis van een bestaande kaartdataset, waardoor game-objecten terechtkwamen op locaties zoals het Hiroshima Peace Memorial Park, Arlington National Cemetery en het United States Holocaust Memorial Museum. Nadat de instellingen bezwaar maakten, verwijderde de ontwikkelaar ze, en het Holocaust Museum bevestigde dat het op verzoek was verwijderd. De app werkte precies zoals ontworpen. Het defect was contextueel; het soort dat iemand met lokale kennis opmerkt en een geautomatiseerde pipeline nooit zal vinden.
Wat doet een QA-lokalisatietester?
Een QA-lokalisatietester verifieert een gelokaliseerde build tegen alle vier de bovenstaande foutencategorieën, waarbij hij in het product werkt in plaats van alleen in de brontekst. In de dagelijkse praktijk betekent dit: landspecifieke testgevallen uitvoeren op echte apparaten, elk vertaald scherm vergelijken met het origineel op integriteit van de lay-out, bevestigen dat regionale formaten en invoervelden functioneren, en beoordelen of de inhoud past bij de doelcultuur. De rol bevindt zich op het snijvlak van functionele QA en taalkundig inzicht, en de beste testers combineren moedertaalvaardigheid (of bijna-moedertaalvaardigheid) met de instincten van een softwaretester.
Wat een localization QA-tester niet doet, is de vertaling genereren. Dat onderscheid is belangrijk. Een vertaler kan een vlekkeloze tekst afleveren die toch een defect product oplevert zodra deze in een knop met vaste breedte, een strikte validatieregel of een rechts-naar-links-lay-out terechtkomt. Het is de taak van de tester om die kloof te vinden voordat de gebruiker dat doet, en vervolgens de juiste lokalisatie-testtools in te zetten om het werk op te schalen.
Lokalisatie-QA versus vertaling: waar de rollen uiteenlopen
De duidelijkste manier om beide te scheiden is door te kijken naar de verantwoordelijkheid. Vertaling is verantwoordelijk voor de woorden. Lokalisatie-QA is verantwoordelijk voor alles wat met die woorden gebeurt zodra ze in de draaiende software terechtkomen, plus de taalkundige nauwkeurigheid van de woorden zelf in hun context. Een vertaler werkt in een document of een vertaaltool; een tester werkt in de build.
Dat verschil verklaart waarom vertaling alleen een wereldwijde lancering niet beschermt. Vertaling kan niet zien of een label uit de container loopt, een checkout een lokale datum weigert, een scherm niet spiegelt of een afbeelding cultureel ongepast is, omdat niets daarvan zichtbaar is in het tekstbestand. Lokalisatie-QA bestaat juist om de defecten op te vangen die zich bevinden tussen een correcte vertaling en een correct product. Teams die een gestructureerde manier willen om beide tegelijk te verifiëren, beginnen vaak met een checklist voor lokalisatietesten die elke controle koppelt aan de vier foutencategorieën.
Waarom lokalisatie-QA-testen belangrijk is voor wereldwijde groei
De zakelijke rechtvaardiging ligt in het gedrag van kopers in hun eigen taal. In het onderzoek van CSA Research onder 8.709 consumenten in 29 landen, gaf 76% van de online shoppers aan dat ze de voorkeur geven aan producten met informatie in hun moedertaal, en 40% zei nooit te kopen op websites in andere talen. Een gelokaliseerde ervaring die faalt in een van de vier foutencategorieën, ondermijnt precies het vertrouwen dat de gebruiker naar uw gelokaliseerde versie dreef.
Daarom moeten bedrijven lokalisatie-QA-testen beschouwen als onderdeel van de release-gereedheid in plaats van een opschoning na de lancering. Een afgekapte knop of een haperende checkout in een nieuwe markt ergert niet alleen gebruikers; het stuurt ze direct naar een concurrent wiens gelokaliseerde proces wél werkt. Voor teams die kijken hoe ze deze dekking betaalbaar kunnen houden terwijl ze meer talen toevoegen, is AI-gestuurde lokalisatie-QA een richting die het overwegen waard is.
Hoe QAwerk lokalisatie-QA benadert
QAwerk levert sinds 2015 softwaretests en heeft inmiddels meer dan 100 lokalisatieprojecten afgerond, waarbij de geteste producten nu ongeveer 110 miljoen mensen bereiken. Wij worden door IAOP wereldwijd erkend als een van de beste QA-bedrijven in de Global Outsourcing 100, en ons lokalisatiewerk omvat zowel handmatige als geautomatiseerde tests voor web, mobiel, SaaS en games. De drie onderstaande projecten laten zien hoe de vier categorieën van fouten in de praktijk worden opgespoord.
Voor Keystone test ons team acht contentrijke onderwijsportalen die naar meer dan 40 talen zijn vertaald en jaarlijks door ruim 110 miljoen studenten worden gebruikt. Onze testers combineren handmatige beoordeling met een herbruikbare crawler die vertaalproblemen op grote schaal documenteert. Zo hebben we functionele lokalisatiefouten ontdekt, zoals de link naar de Arabische privacyverklaring die crashte zodra erop werd geklikt.
Voor ICONOMI, een platform voor het beheer van crypto-assets met een wereldwijd publiek, gebruikte QAwerk Spling om foutmeldingen, datumnotaties en invoervalidatie in meerdere talen te verifiëren. Daarnaast hebben bredere handmatige tests bijgedragen aan een vermindering van het klantverloop met 15% voor een platform dat inmiddels door meer dan 100.000 mensen wordt gebruikt.
Voor Escuela Coaching in Madrid heeft ons team de Engelse lokalisatie van een in Spanje ontwikkeld coachingplatform gecontroleerd. We testten knopteksten, menu’s, foutmeldingen en informatieve inhoud, en spoorden ontbrekende vertalingen en validatiefouten op voorafgaand aan een wereldwijde lancering die binnen ongeveer 30 dagen werd gerealiseerd en inmiddels 300+ organisaties bedient.
Als u een product naar nieuwe talen uitbreidt, biedt een samenwerking met QAwerk u beide kanten van het werk: testers met de taal- en cultuurkennis om linguïstische en culturele defecten op te sporen, en de technische nauwkeurigheid om layout- en functionele problemen te vinden, ondersteund door tools als Spling, Applitools, Playwright en Cypress. Wilt u de omvang van een lokalisatie-QA-traject bepalen? Neem contact met ons op voor een plan op maat.
Ontdek hoe wij Keystone hielpen om een naadloze ervaring te bieden via 8 websites en 40+ gelokaliseerde versies voor 110 miljoen jaarlijkse bezoekers
