A lo largo del último mes, he dedicado casi el 95% de mis horas de trabajo a realizar testings de diversas aplicaciones de una importantísima empresa de desarrollo de aplicaciones de software de diseño. Por ello, me ha parecido que comentar una serie de aspectos era una buena excusa para volver a retomar el blog.
En primer lugar, definamos qué es el testing dentro del proceso de localización. El testing es la última etapa del control de calidad de la localización de software y consiste en llevar a cabo una serie de procedimientos que permiten verificar y garantizar la calidad, operabilidad, usabilidad y adecuación del producto final para su lanzamiento a los distintos mercados. A efectos prácticos, en la mayoría de los casos podemos distinguir tres tipos distintos (y complementarios) de testing: el funcional, el estético y el lingüístico (en realidad existe una gran variabilidad en este sentido, y cada cual acaba por nombrar y organizar cada tipo o fase como le parece).
En segundo, lugar, y en todos los tipos, el testing se realiza en dos fases:
1) Análisis (testing propiamente dicho): primera fase, en la que se trata de examinar a fondo la aplicación informática en cuestión, ya sea mediante la ayuda de una serie de pasos o casos (test cases) elaborados por los desarrolladores para verificar todas las cadenas[1], o bien de forma libre (ad-hoc), de manera que el tester (persona encargada de realizar el testing) tiene potestad para moverse por toda la aplicación en busca de errores o defectos. A medida que se detectan errores (que suelen denominarse bugs, haciendo uso del término informático para fallos en la programación de una aplicación), el tester debe informar de ellos. Esto se hace habitualmente a través de un programa o sistema de registro y seguimiento de bugs (como por ejemplo, Bugzilla), en el que se introduce toda la información correspondiente (si el bug es funcional, lingüístico o estético, qué pasos hay que llevar a cabo para generar o acceder a él, instrucciones sobre cómo arreglarlo, gravedad, captura de pantalla de referencia para visualizarlo, etc.).
2) Regresión: en esta segunda fase, el tester debe asegurarse de que todos los errores de los que se ha informado se han corregido. Para ello, los ingenieros informáticos le proporcionan sucesivas versiones actualizadas del software (denominadas builds en términos informáticos) y el tester sigue los pasos especificados en el sistema de registro y seguimiento de bugs para garantizar que todo está solucionado antes de publicar la versión final de la aplicación.
Aunque el proceso puede parecer sencillo, es muy importante realizar todo con el mayor nivel de detalle posible, proporcionando las instrucciones de forma clara y concisa a fin de garantizar que el flujo de comunicación con los ingenieros es el adecuado. Ha de tenerse en cuenta que, en circunstancias normales, el testing de una aplicación se realiza a escala internacional, por lo que muchos idiomas participan en él, de forma que si no se aplica el mayor rigor a todo el proceso, puede acabar por convertirse en una masa de trabajo verdaderamente inmanejable.
Hechas estas aclaraciones, me gustaría comentar que en el caso de los localizadores, las tareas que se nos asignan suelen ser aquellas correspondientes a los tipos de testing lingüístico y estético (no obstante, si se detectan bugs funcionales que incidan sobre la funcionalidad o usabilidad del software, se debe informar de ello), aunque en función de los conocimientos de programación y de la propia aplicación también se pueden recibir encargos de carácter funcional. Esto significa que, en la mayoría de los casos, el responsable del testing lingüístico debería tener en cuenta los siguientes puntos:
- El objetivo primordial es el de asegurarse que desde la perspectiva lingüística el software queda lo más correcto posible (sin fallos orto-tipográficos ni gramaticales). En este aspecto es importante comprobar que la aplicación está bien traducida en cuanto a la concordancia de número y género en listas desplegables, botones de radio, texto generado dinámicamente, gestión de variables, mensajes de la barra de estado, etc. Por ejemplo, debemos tratar de evitar que aparezcan mensajes del tipo «1 mensajes recibidos» (para ello se suele utilizar el clásico truco de los dos puntos, es decir, traducir como «Mensajes recibidos: 1») o que en una lista desplegable correspondiente a la opción Estado, lo opción None se traduzca como Ninguno (es probable que durante el proceso de traducción no hubiese suficiente información contextual para decidir qué género escoger). Al principio he comentado que el software debe quedar lo más correcto posible porque en muchos casos la solución óptima requeriría que se rediseñase el código fuente de la aplicación y, en la mayoría de los casos, los ingenieros son muy reacios a ese tipo de cambios de tanto calado cuando la aplicación ya está en una fase tan avanzada (suelen esgrimir como razón que sólo se trata de un aspecto estético, que al fin y al cabo el programa funciona bien).
- Teclas de acceso rápido (hotkeys) y atajos de teclado (shortcuts): es importante comprobar que en los distintos menús y cuadros de diálogo no hay hotkeys duplicadas. Además, en español se debe evitar que las hotkeys correspondan a vocales acentuadas (teóricamente también deben evitarse las letras con trazos hacia abajo como g, p o y, pero en la mayoría de los casos es necesario utilizarlas para evitar la duplicación). Por cuanto respecta a los atajos de teclado, es absolutamente necesario comprobar no sólo que están localizados (Mayús en lugar de Shift, etc.), sino que funcionan y abren los cuadros de diálogo apropiados (un caso que a veces falla es cuando se asigna un atajo como Ctrl + ñ).
- Aspectos referentes al local (entandamos local como “A collection of rules and data specific to a language and a geographic area”): en este sentido es necesario comprobar, entre otras cosas, que las fechas (tanto las que se muestran fijas en la interfaz como las generadas dinámicamente para nombres de archivos, fechas de modificación, etc.) utilizan un formato propio del español, que la moneda utilizada es el euro y que los números utilizan los separadores correctos para decimales y unidades de millar (coma y punto respectivamente[2]).
- Seguimiento y vigencia de los glosarios, listas terminológicas y guías de estilo en contexto: durante el testing se tiene la oportunidad de ver la traducción del software en su contexto real. Esto ofrece la posibilidad de constatar que todo el software sigue las directrices de estilo determinadas por el cliente, al tiempo que permite comprobar que la aplicación de la terminología se ha llevado a cabo de forma consistente y coherente no sólo de forma interna (con respecto a la propia aplicación), sino también de forma externa (con respecto a la versión del sistema operativo en que se ejecute).
- Alineación y desbordamiento (truncation): se debe comprobar que todo el texto está correctamente alineado (por ejemplo, que todas las casillas de verificación del mismo nivel jerárquico tienen idéntica alineación). Por otra parte, es necesario asegurarse de que todas las opciones de software (ya sean menús desplegables, texto descriptivo, de casillas de verificación, etc.) se ven completas, de forma que no haya texto que desborda el espacio que le ha sido asignado, es decir, que no haya lo que comúnmente se denomina “texto truncado”.
- Puntuación: una correcta, y sobre todo consistente, puntuación ayuda no sólo a diferenciar las distintas opciones dentro de la aplicación, si no que facilita la lectura. Por ello, es necesario comprobar que la puntuación en mensajes de error, información sobre herramientas (tooltip), opciones de software de un mismo cuadro de diálogo o panel es consistente.
- Adecuación de las traducciones a la parte de la interfaz de usuario donde aparecen: si es importante asegurarse de que todo está lingüística y gramaticalmente correcto, también lo es garantizar que se ha utilizado la forma adecuada en cada parte de la interfaz de usuario. Así, el infinitivo se utiliza en la gran mayoría (siempre hay excepciones) de los casos para botones, elementos de menú y casillas de verificación (aquellas opciones que desencadenan una acción), mientras que se suelen utilizar otro tipo de construcciones (imperativo o texto de corrido) para el resto de cadenas como, por ejemplo, mensajes de error, información sobre herramientas, mensajes de la barra de estado y otros mensajes de diversa naturaleza mostrados en la interfaz.
Creo que, a grandes rasgos, estas son las comprobaciones básicas que siempre se han de tener en cuenta (al menos son las que yo trato de no olvidar). Existen algunas más, pero ya muchas veces dependen de las instrucciones del cliente, del tiempo del que se dispone o incluso de la propia naturaleza de la aplicación.
Un testing realizado de forma concienzuda puede no sólo mejorar de forma sustancial la calidad lingüística y estética de un producto (los aspectos en los que el traductor y localizador puede incidir de forma directa), sino que es esencial para detectar errores graves o muy obvios que pueden perjudicar seriamente no sólo la calidad del producto, sino que pueden dañar la reputación del cliente que ha desarrollado la aplicación.
Espero que esta reflexión os haya resultado interesante. Si alguien quiere aportar algún punto que se me haya pasado ahora al escribir o desee completarlo, soy todo oídos.
Un saludo,
Álvaro
PD: si os interesa el testing, os recomiendo echar un vistazo al último número de Multilingual y, por otra parte, al blog Algo más que traducir para cononcer la opinión al respecto de un especialista en localización de videojuegos.
Recomendación musical: Heaven can wait, de Charlotte Gainsbourg con Beck
[1] Este tipo de casos (test cases) se compilan en una guía o mapa de testing que el tester debe seguir y cumplimentar a medida que avanza en la tarea.
[2] La polémica acerca de los separadores en los números ha sido ampliamente debatido en diversas publicaciones. A modo de introducción, recomendamos consultar en primer lugar la referencia de la RAE con respecto a la separación en números.
Cervantes. No son una maravilla desde el punto de vista económico, pero pueden resultar interesantes para estudiantes que vayan a licenciarse en breve o para aquellos que deseen cambiar de aires.
(Nunca) sobran las palabras 