¿Qué son las pruebas de localización? Ejemplos de casos de prueba y lista de verificación

Por: Tomas Hamilton Tomas Hamilton
Hours Actualizado

⚡ Resumen inteligente

Localization Testing checks that software behaves correctly for one specific region, locale or culture, covering translated content, user interface layout, currency, date and time formats, and the local conventions a user in that market expects.

  • 🌐 Taquigrafía: The technique is written L10N, because ten characters sit between the L and the N in localization.
  • 🎯 Objetivos principales: Content and the user interface absorb almost every localization defect a tester will log.
  • 🧭 Cuatro fases: Build verification, functional testing, regression testing and final sign-off make up a typical cycle.
  • 📐 Layout risk: Translated strings expand, and double-byte and right-to-left scripts break layouts that English never exposed.
  • 🤖 Automatización: Scripted suites repay themselves quickly once the same scenarios run across many locales.
  • 🔀 Not the same as I18N: Internationalization prepares the code; localization verifies one finished market.
Descubre más

Localization Testing of language, currency and date formats for a target locale

Pruebas de localización

Pruebas de localización Es una técnica de prueba de software en la que se prueba el comportamiento de un software para una región, localidad o cultura específica. El propósito de realizar pruebas de localización para un software es probar los aspectos lingüísticos y culturales apropiados para una ubicación particular. Es el proceso de personalizar el software según el idioma y país de destino.

El área principal afectada por las pruebas de localización incluye el contenido y la interfaz de usuario.

Es un proceso de prueba de una aplicación globalizada cuya interfaz de usuario, idioma predeterminado, moneda, formato de fecha, hora y documentación están diseñados según el país o región de destino. Garantiza que la aplicación sea lo suficientemente capaz para usarse en ese país en particular.

Ejemplo:

1. Si el proyecto está diseñado para el estado de Tamil Nadu en India, el proyecto diseñado debe estar en idioma tamil, debe estar presente un teclado virtual tamil, etc.

2. Si el proyecto está diseñado para EE. UU., entonces el formato de hora debe cambiarse de acuerdo con la hora estándar de EE. UU. Además, el idioma y el formato del dinero deben seguir los estándares de EE. UU.

The illustration below shows the same product being adapted for different locales, with the language, currency and formatting rules changing while the underlying build stays the same.

Localization testing adapting one product build to several target locales

¿Por qué realizar pruebas de localización?

El propósito de realizar pruebas de localización es verificar los aspectos lingüísticos y culturales apropiados para un lugar en particular. Incluye un cambio en la interfaz de usuario o incluso la configuración inicial según los requisitos.

En este tipo de prueba, muchos probadores diferentes repetirán las mismas funciones. Verifican varias cosas como errores tipográficos, idoneidad cultural de la interfaz de usuario, errores lingüísticos, etc.

It is also called “L10N” because there are 10 characters in between L & N in the word localization.

There is a commercial reason behind the effort as well. A mistranslated label or a date that reads 03/04 as March instead of April erodes trust in a market a team has already paid to enter, and those defects are found by a tester in the target locale rather than by Pruebas de GUI performed in English.

Localization Testing vs Internationalization Testing

The two activities are sequential rather than competing. Internationalization testing (I18N) confirms that the code base can accept any locale at all; localization testing (L10N) then confirms that one specific locale is correct.

Localization Testing (L10N) Internationalization Testing (I18N)
Verifies that the product feels native in one target region Verifies that the product can support many regions without redevelopment
Checks translated text, currency, date, time and cultural fit Checks character encoding, string externalisation and locale-aware code
Runs once the translated build for that market exists Runs first, before any text is sent for translation
Needs a tester or reviewer who knows the local language Can be performed by the core team using pseudo-translated builds

Revisa este tutorial para a difference between localization and globalization testing.

Cómo hacer pruebas de localización

Para una prueba de localización típica, configuramos pruebas de verificación de compilación, Prueba de funcion, Pruebas de regresióny aprobación final.

1. Las pruebas de verificación de compilación son un pequeño subconjunto de prueba funcional, which is performed before QA starts with any detailed testing. It is close in spirit to smoke testing: the localized build is rejected quickly if the language pack fails to load at all.

2. La prueba normal es el paso para ejecutar los casos de prueba normales y encontrar defectos en los registros durante la ejecución.

3. Las pruebas de regresión son Defecto proceso de regresión para garantizar que el defecto se solucione mientras que no haya impacto de los defectos reparados en las áreas circundantes.

4. La aprobación final consiste en realizar una verificación final de la construcción antes de la entrega al cliente.

Each phase is repeated per locale, not once for the product. A defect fixed in the French build has to be regressed in the German and Japanese builds too, because the same string resource is often shared between them.

ARTÍCULOS RELACIONADOS

Automation in Localization Testing

Si el proyecto es grande y necesita ser probado con frecuencia, entonces optamos por Pruebas de automatización.

  • Elija una herramienta de automatización para escribir guiones.
  • Tome el escenario que se va a probar para la estrategia de localización.
  • Escribe guiones de acuerdo con eso.
  • Recopile los resultados y actualice el escenario como Pasa/Falla.

Nota: Selenium es una de las herramientas pioneras en este ámbito. Tiene muchas funciones, sin embargo, requiere más conocimientos técnicos para su uso.

Automation carries a limit worth stating plainly. A script can prove that a currency symbol changed and that no string is truncated, but it cannot judge whether a translation reads naturally or whether an icon offends. Machine checks handle the mechanical layer; a native reviewer still handles the linguistic layer.

Localization Testing Tools

Localization work draws on three different classes of tool, and most teams end up running all three.

  • Functional automation frameworks: Selenium, Appium and comparable frameworks re-run the same suite against each locale build, which is where the bulk of repetitive verification happens.
  • Sistemas de gestión de traducciones: Platforms that hold the string resources keep translators, developers and testers working from one glossary, so a term is not translated two different ways in two screens.
  • Pseudo-localization utilities: These replace English strings with accented, lengthened placeholders before real translation begins, exposing hard-coded text and layouts that cannot absorb longer words.

Device and browser coverage matters just as much as the tool. Fonts, input methods and default locales differ across platforms, so the localized build has to be exercised on real target devices during prueba móvil and across the browser set defined for pruebas de aplicaciones web.

Mejores Practices Checklist for Localization Testing

  • Hire a localization firm with expertise in i18n engineering
  • Asegúrese de que su estrategia de pruebas de localización permita más tiempo para idiomas de doble byte.
  • Asegúrese de internacionalizar correctamente su código para el DBCS antes de ejecutarlo.traccualquier texto para enviar para traducción
  • Externalise every string into resource files first, so that no user-visible text remains hard-coded in the source.
  • Run a pseudo-localized build early, because it exposes truncation and hard-coded text before translation money is spent.
  • Reserve layout space for text expansion, since translations from English frequently run longer than the original label.
  • Test right-to-left locales such as Arabic and Hebrew on real screens, where mirrored layouts and mixed-direction text fail most often.
  • Maintain a per-locale style guide covering date order, decimal separators, address format, honorifics and tone.
  • Have a native speaker review the finished screens, because cultural fit cannot be asserted by a script.

Two of those items depend on the platform rather than the language, which is why localized builds are usually scheduled alongside pruebas de compatibilidad y pruebas de configuración rather than after them.

Casos de prueba de ejemplo para pruebas de localización

The table below gives a starting set of checks. Each row becomes a full caso de prueba once the expected result for the specific locale is filled in.

S.No Caso de prueba Description
1 Los glosarios están disponibles para referencia y verificación.
2 La hora y la fecha tienen el formato adecuado para la región de destino.
3 Los formatos de números de teléfono son adecuados para la región de destino.
4 Moneda de la región de destino.
5 ¿La licencia y las reglas obedecen al sitio web (región) actual?
6 El diseño del contenido del texto en las páginas está libre de errores, tiene independencia de fuentes y alineaciones de líneas.
7 Funcionalidad de caracteres especiales, hipervínculos y teclas de acceso rápido.
8 Mensaje de validación para campos de entrada.
9 La compilación generada incluye todos los archivos necesarios.
10 La pantalla localizada tiene el mismo tipo de elementos y números que la del producto original.
11 Asegúrese de que la interfaz de usuario localizada del software o las aplicaciones web sea comparable con la interfaz de usuario de origen en los sistemas operativos y entornos de usuario de destino.
12 Sorting and alphabetical ordering follow the rules of the target language, not the source language.
13 Right-to-left locales mirror the layout correctly, including navigation, icons and mixed-direction strings.
14 Keyboard input, spell check and search accept accented and multi-byte characters.

Ventajas de las pruebas de localización

A continuación se presentan los beneficios de las pruebas de localización.

  • Reducción del costo general de las pruebas
  • Reducción del costo general de soporte
  • Ayuda a reducir el tiempo de prueba.
  • Tiene más flexibilidad y escalabilidad.

Those savings come from catching locale defects once, centrally, instead of once per market support queue. Accessibility gains often follow as well, because the same discipline that keeps a layout intact under longer German strings also keeps it intact under enlarged text during pruebas de accesibilidad.

Desventajas de las pruebas de localización

A continuación se presentan los desafíos de las pruebas de localización.

  • Requiere un experto en el dominio
  • Contratar un traductor local suele encarecer el proceso
  • El almacenamiento de caracteres DBCS difiere en varios países.
  • Un evaluador puede enfrentar desafíos de cronograma

The schedule pressure is the one most teams underestimate. Translation arrives late in the cycle by definition, so localization defects surface close to release, which is exactly when a layout change is most expensive. Planning the locale passes into the wider plan described in tipos de pruebas de software keeps that squeeze manageable, and the general pruebas de software introduction covers where the phase sits overall.

Preguntas Frecuentes

By switching the device to Arabic or Hebrew and checking that the whole layout mirrors — navigation, icons, progress indicators and scroll direction. Mixed strings, where a Latin product name sits inside Arabic text, are the usual failure point.

Translated text is often longer than the English original, so buttons, menus and table headers overflow or truncate. Reserving spare width in the design, then verifying it on the longest target language, prevents most of these defects.

It replaces every translatable string with an accented, deliberately lengthened version. Any text still appearing in plain English is hard-coded, and any clipped label proves the layout cannot absorb expansion. Both are found before translation is purchased.

A QA engineer runs the functional and layout checks, and a native speaker of the target language reviews wording, tone and cultural fit. Splitting it that way avoids paying a linguist to re-run mechanical regression passes.

Hard-coded English strings, truncated labels, ambiguous date order, wrong decimal and thousands separators, broken accented characters, and concatenated sentences that translate into nonsense because the fragments were assembled in code.

Pseudo-localized checks start as soon as strings are externalised, well before translation. Full locale passes start when the first translated build is available, and repeat each sprint rather than waiting for a single pass before release.

Machine learning compares localized screenshots against the source layout to flag truncation and overlap, scores translations for terminology drift, and ranks which locales carry the highest risk. Final cultural judgement still rests with a native reviewer.

Yes. It drafts locale-parameterised Selenium scaffolding, resource-file assertions and data-driven loops over locale codes. The expected values per locale must still come from the style guide, not from the model.

Resumir este post con: