Si te quieres dedicar a la localización de software o videojuegos, una opción recomendable para ganar experiencia es trabajar de tester lingüístico. No en vano EA convocó este año la segunda edición del EA Campus para formar a profesionales de control de calidad lingüístico de videojuegos (como Ana Fuentes), lo que refleja que hay una importante demanda. Nombres importantes del sector como Sega o Nintendo siempre buscan testers, y hay muchas empresas como Pole to Win o Enzyme dedicadas exclusivamente al testing de videojuegos para diferentes desarrolladores.
No obstante, como traductor también es posible que tengas que hacer ciertas tareas de testing, y yo de hecho llevo informando de fallos (conocidos en la jerga como bugs) casi 5 años a lo tonto para diferentes empresas, tanto de software como de videojuegos (lo más habitual es hacerlo si estás en plantilla, aunque también puede darse el caso de hacerlo desde casa, como le pasó a Yedra e incluso a mí). Por tanto, si bien seguramente habrá testers con más experiencia que yo, me gustaría comentar una serie de recomendaciones útiles a la hora de redactar un informe de fallos.
Elementos básicos de un informe de bugs
Todo bug tiene una serie de campos obligatorios y opcionales que se deben especificar para poder clasificarlos mejor. Cada empresa tiene su método, pero por experiencia propia, los más habituales son (por orden relevante a mi juicio):
ID del bug:
Identificador único para referirse a un determinado bug, p. ej. “34910”. Esto se rellena solo. También es posible que, si el bug es muy parecido a otro, en la descripción se ponga “related to bug #XXXXX”.
Título:
Es habitual que haya un título que resuma brevemente el fallo para tener una idea general de un vistazo. Aquí a veces se pone el nombre del proyecto y el idioma afectado entre corchetes (me parece lo mejor para ahorrar campos).
Descripción detallada del bug:
Este es el campo dónde más tiempo pasarás escribiendo, ya que básicamente debes mencionar dónde sale el bug, explicar el problema, proponer una solución y describir los pasos para reproducirlo.
Idiomas a los que afecta el bug:
Hay muchos errores que podrían afectar a más de un idioma, como los de textos no traducidos o incluso errores de traducción que provienen del original. Los nombres de los idiomas se suelen especificar según la norma ISO 639, por lo que el español de España es ES, el inglés es EN, el alemán es DE, etc. Si el bug afecta a varios idiomas, se suele poner ALL.
Captura de pantalla o vídeo: una imagen vale más que mil palabras, créeme. Es importante resaltar el texto afectado (recuerda que quien arregla el fallo no tiene por qué conocer el idioma). Con la tecla Impr Pant del teclado y el Paint vas sobrado.
Número y fecha de la versión usada: cada X días, los testers reciben una nueva versión del producto que prueban. Las versiones suelen denominarse builds. Esto se puede incluir en la descripción.
Nombre del tester que lo ha encontrado: hay que tener “fichado” a la persona que ha encontrado el fallo por si hay dudas.
Persona asignada al bug:
Puede ser un desarrollador, un traductor…
Tipo de bug:
Esto puede ir desde simplemente a “lingüístico” o “funcional” o ser algo mucho más detallado e incluir subcategorías como spelling (ortografía), grammar (gramática), consistency (coherencia —que no consistencia como se suele oír—), mistranslation (error de traducción), etc.
Zona en la que aparece el bug: aquí se suele especificar la pantalla o fase en la que ocurre el bug.
Archivo y ubicación del texto erróneo: idealmente debería haber un campo para especificar en qué archivo está el texto con el error, aunque esto se puede comentar en la descripción sin problema.
Prioridad: no es lo mismo que haya una falta de ortografía a que el juego se cuelgue siempre en un momento o que no se vean los acentos en el texto. Hay que ser muy riguroso para no alarmar sin necesidad. Normalmente al principio del proyecto no es necesario indicar la prioridad, pero recuerda que cada proyecto es un mundo.
La clave para redactar un informe de bugs eficaz: sé conciso y esquemático. La lista anterior puede asustar, pero por suerte la mayoría de veces contaremos con una plantilla en la que simplemente tenemos que seleccionar la opción adecuada y listo. Ya digo que cada empresa tiene su método (y aplicación propia).
Lo realmente importante es que seas consciente de que la persona que va a leer tu informe está muy ocupado y que tiene que aprovechar su tiempo al máximo, así que olvídate de escribir tochos porque, por experiencia propia, o van a ser confusos o ni se los van a leer, pues los responsables de corregir los bugs suelen leer en vertical. Dicho de otro modo, presenta la información de forma esquemática y ve al grano. No en vano redactar un buen título y adjuntar una captura puede ser la clave de que tu informe no acabe olvidado entre un mar de bugs.
Las posibles respuestas a un informe de bugs:
Esta es mi parte favorita. Lo normal sería que te digan “vale, lo he corregido”, pero muchas veces el responsable de arreglar el bug te seguirá preguntando cosas o, mejor aún, no arreglará el bug. Veamos pues cuáles son los estados típicos de un bug (alguno me habré dejado):
Fixed:
¡bien! Hemos informado de un fallo y ya está solucionado.
Will not fix (WNF):
¿cómo? O sea, me tomo la molestia de escribir un informe sobre un bug y me dicen que no tienen tiempo para corregirlo o que técnicamente no se puede arreglar. Pues vaya. 🙁 Pero al menos, si luego algo sale mal, que no sea por que no lo habíamos dicho…
Working as intended (WAI): esta sí que es buena, ya que al parecer el bug no es un bug, sino que es así por diseño. Busca “It’s not a bug, it’s a feature” en Google.
No bug (NB): sinónimo de WAI. No hay nada que ponga más triste a un tester que ver que te ponen eso.
Duplicate:
Te has pasado 15 minutos escribiendo un bug y… ¡resulta que otra persona ya lo había dicho! Así que encima le has hecho perder tiempo al que lo ha leído. Shame on you.
Obsolete: como el juego o aplicación sigue en desarrollo, resulta que han quitado esa parte del producto, así que ya no es relevante. Pues ya podrían haber avisado antes, grrr.
Not fixed: nos llega una nueva versión, reproducimos los pasos para verificarlo… ¡y sigue saliendo el mismo error! 🙁 Pues nada, esperemos que lo arreglen a la próxima.
¿Por qué está todo en Spanglish en este artículo?
Es que me he vuelto hípster. No, espera… Esta entrada está en Spanglish simplemente porque, te guste o no, para ser tester hay que trabajar en equipos que hablan ya no solo tu lengua materna, sino otros idiomas. Por tanto, la lengua franca va a ser el inglés y vas a tener que escribir en inglés. Ahora te puede parecer aberrante leer “bug”, “testing”, “test plan” o “reportar un bug” (eso sí que he evitado decirlo en esta entrada), pero cuando lleves unas semanas, ya me contarás. Pero, por favor, sí te pido que digas “coherencia” y no “consistencia”.
Un ejemplo de informe de bugs:
Hoy en día parece que no hay término medio: o la localización es de sobresaliente, como la traducción de cualquier El profesor Layton, o te quedas helado con traducciones de Metal Gear Rising o The Walking Dead. Pero en realidad yo creo que es simplemente que destaca más lo malo que lo bueno (obviamente, yo soy el primero que tiene cagadas).
Como creo que no hay nada mejor para explicar algo que poner ejemplos, os invito a que veáis este vídeo del Metal Slug X para Android. Premio para el que vea más fallos por segundo.
Un ejemplo de bug que demuestra que en realidad no hacen falta tantos campos podría ser este:
Title:
[MSX] [ES] “Lenguaje” should be “Idioma” in options menu (con esta descripción casi que no hace falta mucho más; MSX es Metal Slug X y ES es el idioma)
Description:
When you go to the options menu from the main menu, the third option reads “LENGUAJE”. This is a mistranslation, since the correct translation is “IDIOMA” in this context for Spanish. Please see screenshot.
Steps to reproduce:
Go to the main menu.
Tap the gear icon at the left of “SCORELOOP”.
Screenshot
¡Y ya está! Si el programa de informes de bugs es suficientemente bueno y “listo”, los campos de Found by, Assignee, Build y otros se rellenarán automáticamente. Por supuesto, dependiendo de la complejidad del bug, tendremos que poner más o menos cosas. Por ejemplo, puede que sea necesario poner algo como Expected result y Actual result o algo así.
Opinión:
Sobre este tema no tengo nada que objetar porque me encanta y algunos bug son muy graciosos sobre todo los de Zelda twilight o Majoras Mask, pero muchas veces llegan a molestar e incluso puede borrarte una partida entera.
Bibliografía:
http://algomasquetraducir.com/testing-de-videojuegos-y-software-los-informes-de-bugs/
La división de búsquedas en internet de Alphabet Inc. acordó comprar Fabric, un negocio de Twitter que ofrece un conjunto de herramientas de software para aplicaciones móviles. Las compañías no revelaron los términos financieros.
