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.
Índice de contenido
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í.
En conclusión…
¿A que esto de escribir un informe de bugs no era tan complicado como parecía? Lo malo es tener la atención al detalle necesaria para trabajar de tester, claro. Recuerda la importancia del testeo en localización de videojuegos. Y si tienes ganas de aprender más, puedes echarle un vistazo a mi curso online sobre localización de videojuegos en el que explico esto y mucho más. ;);)
Una entrada la mar de interesante, Pablo… Yo ya he hecho algún informe de fallos o bugs para software, todavía no he tenido la suerte o la ocasión de hacerlo para un videojuego. La entrada me ha servido para ver cómo funciona el testing de videojuegos, del cual no conocía prácticamente nada. ¡Gracias por la entrada!
¡Hola, Sergio!
Je, je, me alegro de que te haya sido útil la entrada. Estas cosas se suelen aprender en unos días de formación dentro de una empresa, pero nunca está de más saber lo que te vas a encontrar. 😀
Un saludo,
Pablo
¡Hola, Pablo!
Una entrada muy completa (poco más se puede añadir al respecto). Es cierto que cada empresa es un mundo y que la terminología de los informes puede variar, pero la esencia es la misma. Algo que me llamó la atención al principio es, como tester, tener acceso al texto del juego y poder modificarlo a medida que detectábamos errores. Si te digo la verdad, daba un poquito de pudor al principio, pero al final, creo que se ahorra bastante tiempo para los desarrolladores así. Al fin y al cabo, solo envías los errores que no puedes solucionar mediante un cambio de texto. Por otra parte, más de una vez me he visto en la situación de tener que masacrar el texto por tal de ahorrar tiempo y posibles bugs, pero ese es otro tema. 🙂
Como respuesta adicional al informe de errores, también añadiría la posibilidad de que arreglen cierto bug en una versión posterior del juego (ay, esos famosos y enormérrimos parches…)
Un saludo y, ¡gracias por la mención!
Ana
¡Hola, Ana!
Sí, lo de que el tester tenga acceso al texto puede ser un arma de doble filo, pero siempre que haya buenos trabajadores, no debería haber problema. 😛 En otras empresas sin embargo es otra persona la que debe hacer los cambios (como en Nintendo), pero vaya, que no me extraña que al principio tengas algo de pudor para hacer cambios a un texto que no es tuyo. 😛
No me ha tocado testear nada que luego saque un parche, pero sí, desde luego, es una alegría que más adelante se puedan arreglar cosas. 😀
Un saludo,
Pablo
Entiendo que, desde la perspectiva del traductor, haya un poco de recelo a la hora de dejar un texto en las manos del tester. Ahora estoy en la situación contraria y me sigue resultando más práctico dar acceso al texto para corregir errores de inmediato (de longitud del texto, de contexto, etc.) que pasar por la aprobación del traductor. En fin, cada flujo de trabajo tiene sus ventajas e inconvenientes, como todo. 🙂
Ahora, si nos metiéramos a discutir bugs de “estilo”, ya sería otro tema…
Ahí te tengo que dar la razón. En Nintendo había dos fases de testeo: una en la que podías cambiar libremente lo que quisieras y otra en la que había que reportarlo todo. La clave estaba en ver todo el texto posible antes de que fuera necesario informar de los bugs. 😉
Los bugs de estilo he preferido no mencionarlos… xDDD
Pablo
Lo bueno es que en las empresas grandes ni los traductores ni los testers deciden cómo es el proceso ni quién tiene que cambiar qué. Teniendo ya todo definido, nadie se pelea. 😛
Si los traductores tienen acceso al juego de la misma forma que los testers, me parece perfecto que sean los traductores los que cambien las cosas. Igual que en la versión original hay una persona encargada de actualizar el texto. Es la mejor forma de que el producto final sea más o menos coherente. Y nadie mejor que el traductor para saber por qué ha puesto X o Y. A veces también hay bugs que no son bugs. Por ejemplo, ¿se escribe paparazzi o paparazi? Hay que buscar en el DRAE y en el DPD. 😛
Sin embargo, si el traductor no ha visto el juego ni tiene acceso a él, serán los testers los responsables de asegurarse de que el “borrador” de traducción encaje con lo que se ve en pantalla. También está la figura del lead tester, que da un poco las directrices cuando hay dudas.
Y sobre los bugs de estilo, siempre que se haga con cabeza y estén bien argumentados, creo que son bienvenidos. Aunque para ahorrar tiempo lo mejor es consultar con la persona que va a aceptar el bug. Si a dos días de acabar el proyecto metes un bug para cambiar un “estuviera” por un “estuviese”… Apaga y vámonos.
El texto cambia tanto desde que sale del teclado del traductor hasta que llega a las estanterías que hay que olvidarse un poco del proceso tradicional y verlo más como un texto que se va construyendo en equipo, con las opiniones de cada uno.
¡Hola, Eli!
Sí, yo también creo que lo mejor es que el texto lo cambie el traductor si está disponible, aunque lo ideal es revisar el máximo de texto posible antes de que sea obligatorio tener que enviar un bug. Es en ese momento cuando hay que aprovechar para sentarse con los testers si hace falta e ir cambiando cosas sobre la marcha. Y así se evitan cosas como lo de paparazi. 😛
Yo con los bugs de estilo soy bastante permisivo siempre y cuando el texto mejore un poco: todos los que hemos estado en proyectos largos sabemos que, después de tropecientas horas, vemos cosas mejorables donde no hay ningún problema… Pero hay de todo, claro. 😛
Y totalmente de acuerdo: desde luego, antes del testing, creo que se debería hablar más bien de borrador.
Pablo
¡Hola Pablo!
Una entrada muy completa e interesante 🙂
Al hilo de lo que estáis comentando, yo diría que en la fase de testeo es el propio tester el que debería tener la última palabra, y no el traductor. La razón por la que digo esto es que el tester se conoce el juego de arriba abajo, tiene el contexto del que carece el traductor y, por lo tanto, está en situación de tomar decisiones más informadas. También es cierto que testers hay de todos tipos, pero, al menos en mi empresa, los testers de localización somos casi todos traductores o filólogos 🙂
Entiendo que a los traductores les duela un poco en el orgullo cuando ven que se cambia su versión, pero a la larga, todo se hace por mejorar la calidad del producto.
Un saludo,
Andrea
Esta entrada me ha venido como caída del cielo con lo que estoy haciendo estos días. ¡Muchas gracias, muy instructiva! 😉
¡Gracias, Paula! Me alegro de que te haya servido. A ver qué tal la siguiente entrada. 😀
Muy buena entrada, Pablo y ¡muchas gracias por la mención!
Poco más se puede añadir, solo que a mí me encantaba la respuesta “As designed” cuando me cerraban un bug porque sí 🙂
El trabajo del tester es indispensable en el proceso de localización y es una buena forma de entrar en el mercado de los videojuegos. Creo que a más de uno le va a venir muy bien tu entrada para las pruebas que hacen las empresas de testing.
Como dicen por ahí: “It’s not a bug, it’s a feature.” 😀
¡Gracias por pasarte por aquí, Yedra! Desde luego, el It’s not a bug, it’s a feature es un clásico que todo tester ha visto alguna vez en su vida. xD
A ver si la segunda parte es útil también. 🙂
Pablo
Me alegro de que no suene tanto a chino entonces. 😀
Gracias Pablo por tan interesante articulo. Estoy en Panamá y en la actualidad laboro como Software Quality Analyst, que no es otra cosa que un Tester de aplicaciones y software para una empresa canadiense. Sin embargo, como traductora y amante de los videojuegos, apasionada de la tecnología, este tipo de labor seria un sueño hecho realidad! No hay nada mas gratificante que laborar en lo que nos apasiona. Como puedo contactar a estas empresas y ofrecer mis servicios de Tester, y por que no de localizador, traductor? Agardecidad por tu interesante articulo y pro compartir siempre temas de relevancia con la comunidad que te sigue.
¡Hola!
Vaya, entonces tu trabajo es bastante parecido a lo que menciono en la entrada, solo que yo hablaba más del apartado lingüístico. 🙂
Realmente, si ya tienes esa experiencia, es cuestión de ponerte en contacto con las empresas dedicadas a la localización (no me extrañaría que tu propia empresa tuviera un departamento sobre eso), aunque recuerda que en este caso te van a pedir formación lingüística. Como siempre digo, en Google está todo. 😛
Un saludo,
Pablo
¡Hola, Andrea! (no me deja anidar más respuestas)
Bueno, yo creo que lo ideal es que tanto el traductor como el tester hayan jugado al juego (como sucede en Nintendo) y, por tanto, sea el traductor quien decida porque sabe por qué ha puesto X y no Y teniendo en cuenta el contexto también. Cierto es que hace mucho que el tester tenga formación en traducción, ya que así se evitan los problemas que mencionaba Elizabeth sobre cuando te cambian algo que en realidad estaba bien desde el punto de vista ortográfico.
En definitiva, más que quién es la persona adecuada para cambiar el texto, lo ideal es que pueda haber un trabajo en equipo. 😛 Pero claro, por desgracia, no siempre el traductor tiene acceso al juego. En ese sentido, desde luego el tester puede considerar mucho mejor los cambios que se deben hacer, y nada mejor que tenga formación lingüística. Vamos, que por lo que dices, tu empresa se toma el testing lingüístico con seriedad. 😉
Un saludo,
Pablo
Totalmente de acuerdo. Si el traductor está en igualdad de condiciones que el tester, el traductor sirve como un control de calidad adicional que incluso se corrige a sí mismo si hace falta. Y, en estos sistemas de trabajo, nada le impide al traductor cambiar su propio texto cuando ve que no encaja porque conoce el juego al mismo nivel que el tester. Es más, lo hace sin despeinarse. Aunque también es cierto que tal nivel de cooperación solo es posible si los traductores y los testers trabajan bajo el mismo techo.
Quizá esto sea complicado de entender si no se ha trabajado en un entorno que facilita a ambos el acceso al producto, pero es el sistema de control de calidad más refinado que se me ocurre y es lo que más se acerca a cómo se crea el producto original.
Yo soy uno de esos tipos que suelen estar al otro lado del informe de bugs. ¡¡¡No, aún no me tiréis tomates!!!
Aunque los «informes de bugs» que suelo recibir yo son del tipo: «¡Oye, tú, que esto no va! Antes iba, ¿qué has tocado?» ¬.¬
El mayor problema es que el cliente (o betatester) no sabe hablar el idioma del programador y viceversa. Así que el cliente dice una cosa —que normalmente carece de sentido para el programador—, el programador entiende otra, y no es capaz de reproducir el error. Y si no puede reproducirlo, no puede repararlo.
Ahora sí, ya podéis tirar tomates.
Saludos.
¡Hola!
Je, je, no te preocupes, que no te vamos a tirar tomates. 😀 Desde luego, por experiencia propia, no hay nada como que los bugs estén bien escritos. No me extraña que a veces oiga que es preferible que el tester tenga una gran capacidad de redactar antes que saber jugar… Tiene que haber de tó. 😀
Un saludo,
Pablo
¡Buenas, Pablo!
Una entrada genial, útil y completísima. Refleja muy bien la labor del tester lingüístico, un trabajo que, sin duda, enriquece sobremanera las competencias del traductor en la industria de los videojuegos. En mi caso, no tenía total libertad para modificar el texto del juego, pero sí debía informar sobre los errores, ofrecer soluciones a los desarrolladores y traducir algún que otro segmento que se añadía a última hora.
Una de las cosas que más valoro en esta labor es el trabajo en equipo y la comunicación, como siempre se ha dicho, cuatro ojos ven más que dos, y si el juego es FIGS y hay dos ojos por cada idioma, pues excelente; normalmente suele aparecer más de un bug global.
Un saludo,
Juanma
¡Muchas gracias, Juanma! 🙂
Efectivamente, la comunicación entre los diferentes equipos es clave en este caso. Como bien dices, raro es que no haya bugs que no afecten a más idiomas… Qué seríamos los traductores sin los testers. 😉
Un saludo,
Pablo
Efectivamente, ya había fichado esta entrada y me la había leído. No me iré de aquí sin darte la enhorabuena y las gracias, porque me ha aportado bastantes conceptos que desconocía. Espero poder lucirlos en mi entrevista 😉
¡Saludos!
Hola buenas tardes, soy nuevo en esto, asi que pido disculpas de antemano si ya lo habeis hablado XD
Como podria dirigirme a una empresa de videojuegos para ser un tester, o que estudios tienes que cursar para llegar a serlo, gracias.
¡Hola, Xavi!
Pues estudios formales no es que existan, aunque lo que te van a valorar sobre todo, más que tu capacidad para jugar, es tu dominio del español. Haber hecho filología, traducción e interpretación o periodismo ayuda mucho, desde luego. No obstante, no es estrictamente necesario porque conozco a gente que estudió otras cosas y acabó de tester lingüístico.
Sobre cómo dirigirte, pues es cuestión de buscar ofertas que surjan (sobre todo en el extranjero, en España no hay mucho). Normalmente son agencias intermediarias las que ofrecen los trabajos.
Un saludo,
Pablo