Mostrando entradas con la etiqueta testeo. Mostrar todas las entradas
Mostrando entradas con la etiqueta testeo. Mostrar todas las entradas

jueves, 19 de junio de 2014

Curso en Localización de videojuegos (4.ª convocatoria, julio de 2014)

Eh, tú. Sí, tú, que estás leyendo esto. Ya, ya sé que hace mucho que no me paso por aquí, pero en el último año la vida me ha cambiado mucho y no me deja mucho tiempo libre. Pero pasaba por aquí para hacerte unas cuantas preguntas:
¿Quieres que tu verano sea emocionante y aprovechar las vacaciones para mejorar tu futuro? ¿Te gustan los videojuegos? ¿Te gustan los idiomas y te obsesiona la perfección lingüística? ¿Quieres conocer un poco más sobre el increíble mundo de los videojuegos y aprender las bases para embarcarte en la profesión del traductor de videojuegos? Vale, ya paro de preguntar. Si has contestado que sí a cualquiera de las preguntas anteriores, no te lo pienses más y apúntate al curso que imparto en AulaSic sobre localización de videojuegos este julio.

En el curso, aprenderás un poquito sobre el recorrido de la industria, conocerás el proceso de traducción de un videojuego y todo lo que conlleva, aprenderás trucos y entresijos para que te sea más fácil meter un pie en la industria. Por supuesto, también hay turno de preguntas y podrás preguntar todas tus dudas a alguien con experiencia en la industria (sí, esa soy yo :)).

¿A qué estamos esperando? ¡Participa ya en la cuarta convocatoria del curso!

Para más información, haz clic aquí. 

¿Quieres saber lo que opinan los que ya han hecho el curso? Aquí te lo explican:




¡Nos vemos en los foros!

miércoles, 10 de abril de 2013

Mis presentaciones sobre localización de videojuegos y testeo


Tras el aluvión de peticiones de publicar mi presentación del ETIM, llevaba con una idea rondándome la cabeza: ofreceros todas las presentaciones que he hecho desde que empecé, con la esperanza de que os ayuden a muchos, sobre todo a la hora de crear vuestros trabajos de clase o tesinas. Eso sí, solo pido que mencionéis y me añadáis a la bibliografía, como bien os han enseñado en clase. Por lo demás, disfrutad y si tenéis alguna pregunta, ya sabéis dónde encontrarme.

QA, Localisation & Experience: The Perfect Combination for the Best Localisation

Mi presentación en el I International Conference on Translation and Accessibility in Video Games and Virtual Worlds. Barcelona, diciembre de 2010



QA, Localisation & Experience: The Perfect Combination for the Best Localisation

Mi presentación en el 4th Intentational Media 4 All Conference - Audiovisual Translation: Taking Stock. Londres, junio de 2011



Video game Localisation and Testing

Presentación ante los alumnos de Traducción e Intepretación de la Universitat de Vic. Vic, Barcelona, diciembre de 2011




Theory and Practice of Games Localisation: Academic Training vs Professional Reality in Spain and the United Kingdom

Mi presentación, junto con Jennifer Vela, en el II International Conference on Translation and Accessibility in Video Games and Virtual Worlds. Barcelona, marzo de 2012



Theory and Practice of Games Localisation: Academic Training vs Professional Reality in Spain and the United Kingdom

Mi presentación, junto a Jennifer Vela, en el I Media Across Borders Conference. Roehampton, Londres, junio de 2012



La localización y el control de calidad de videojuegos: visión general 

Mi presentación en el Encuentro de Traductores e Intérpretes de Málaga de 2012 sobre la localización y el control de calidad de videojuegos. Málaga, 30 de noviembre de 2012.



La industria de los videojuegos: personajes, PNJ y plataformas de lanzamiento

Mi presentación en el ENETI 2013 sobre la industria de los videojuegos, su evolución desde su nacimiento, su situación actual y las posibles salidas laborales que un traductor pueda tener en esta industria. Granada, 22 de marzo de 2013




También podéis seguir mi perfil para enteraros siempre que suba una nueva. :)


***************************************************
Nota: agradezco infinitamente a Ismael Pardo, de «Diario de un futuro traductor» por ayudarme a incrustar las presentaciones. El problema era tan estúpido, que me merezco un #facepalm con toda regla. ;)

lunes, 17 de diciembre de 2012

Tester de videojuegos: mitos, leyendas y otras hierbas


Tras la primera entrega de «Lo que siempre quisiste saber sobre la industria de los videojuegos (y nunca nadie se atrevió a contarte)», en la que explicaba un poco la entrevista del tester de videojuegos, aquí os dejo esta segunda entrega sobre esta interesante profesión.

Desde que empecé a trabajar en Eidos, allá por el 2005, cuando comentaba a alguien a qué me dedicaba en mis quehaceres laborales, muchas eran las veces que, de su boca, salían alegremente expresiones varias sobre el papel del probador de videojuegos o a qué dedicaba su jornada laboral que diferían bastante de la realidad. Esta asignación aleatoria de tareas aún sigue hoy en día, y dado que parece que el trabajo de tester es tan desconocido como el de traductor (sobre el que muchos piensan que es un escritor frustrado que dedica sus días traduciendo una novela negra en un apartamento oscuro, sin ducharse ni apenas comer), he decidido desmitificar algunos mitos y contestar a algunas preguntas que muchos me habéis dirigido.


Nota: utilizaré ‘tester’ y ‘testeo’ en redonda (tomando la acepción chilena y argentina) porque, para mí, deberían extenderse como normativos en el resto de países de habla hispana, pero solo cuando se refiera a la definición de «someter algo a un control o prueba». Aunque tenemos la palabra «probador» y «pruebas», los que nos hemos pasado años testeando, sabemos muy bien que no es lo mismo testear que, simplemente, probar.

Empecemos...


Mito n.º 1: «El tester se pasa el día «jugando» (y cobra una pasta por ello)»
Respuesta: Sí y no. Si bien es verdad que para llevar a cabo la tarea de encontrar errores en el videojuego o software, el tester tiene que pasarse el día jugándolo o utilizándolo, no se trata de un uso placentero ni tampoco como lo haría un usuario per se (aunque, muchas veces, haya que enfocar el testeo desde el punto de vista del usuario), sino de un uso «obligado», por así decirlo. Es como cualquier tarea, que te encanta hacer cuando nadie te obliga, pero en el momento en que alguien te obliga a hacerla, es como que jode un poco más.

¡Qué viciada me estoy pegandooooo!
Además de que te «fuerzan» a hacer algo durante 8 horas, el trabajo no consiste solo en jugar, sino en encontrar problemas mientras juegas. Para ello, no solo hay que prestar mucha atención (durante 8 horas seguidas, con sus descansos de 5 minutos), mirar en varios sitios mientras vas jugando, leer bien todo el texto, escuchar los efectos de sonido y las voces (todo esto, mientras evitas que 50 zombis te chupen la sangre, claro), sino que, en muchos casos, también hay que «forzar» el juego para ver si consigues encontrar algún otro bug que no te sale «jugando normal». Sí, forzar, es decir, en algunos casos, tu jefe de proyectos te pedirá que realices tal o cual acción, que juegues tal o cual parte del mismo nivel, que utilices tal o cual arma o personaje para que, a base de repetir y repetir lo mismo una y otra vez, se compruebe que no hay errores. Si, a todo esto, le añades que, en el mismo trozo de nivel, tienes que superar el mismo bug una y otra vez (por ejemplo, hay un zombi que solo muere si le clavas el puñal, con lo que tendrás que cambiar el arma cada vez), las ocho horas de supuesta diversión «jugando a videojuegos» se convierten en una auténtica tortura.

Y, sobre lo de «cobrar una pasta»... Muha-ha-ha-ha... ha-ha-ha... ha-ha... ha... ha...
Otro mito falso. Un tester con mucha suerte no es más que mileurista, a pesar de hacer el trabajo sucio y recibir siempre las culpas si un juego no vende o no es de calidad. Hay mucha gente involucrada en el proceso que toma las decisiones importantes y, seamos sinceros, los testers somos los últimos monos de la industria.
;-)

Mito n.º 2: «Cualquiera puede ser tester».
Respuesta: Sí y no. Como ya expliqué hace un tiempo, hay ciertas capacidades que todo tester debería tener. Una de las características más notables de este trabajo es tener que hacer tareas mecánicas y repetitivas, y es precisamente con el trabajo repetitivo cuando se cometen más errores, ya que causan una disminución de la atención. Por tanto, es importante que el tester tenga capacidad para hacer tareas repetitivas sin perder mucho la atención (o ser capaz de tomarse un descanso cuando vea que la atención le disminuye).

Buah, yo llevo currando de esto hace años.
¡Eso de recoger pipas y maíz ya no se lleva!
También es importante haber jugado a (bastantes) videojuegos. Vale, esto también se aprende, pero cuando entras en una empresa, te ponen ante un videojuego y necesitan que des lo mejor de ti en un par de semanas. Si jamás has cogido un mando de Xbox 360, por ejemplo, esta tarea te hará sentir como en el purgatorio: si no la superas con la velocidad deseada, te mandarán directamente al infierno o, en este caso, a la calle. Bueno, no suelen ser tan malos, pero sí que sufrirás con las recriminaciones y los constantes «tienes que darte más prisa en acabar el juego/nivel», y cosas por el estilo.

Además, a pesar de que también se cree que el testeo no es creativo (porque, al fin y al cabo, te pasas 8 horas «jugando», ¿verdad?), los que hemos trabajado en esto, sabemos que no es así. En muchas ocasiones necesitas pensar en múltiples alternativas para recorrer los diferentes escenarios o niveles para encontrar posibles errores o conseguir que el juego «se rompa».

Mito n.º 3: «Para ser tester de localización, basta con haber jugado mucho y hablar otro idioma».
Respuesta: Sí y no. Para testear y poder encontrar los errores, ayuda mucho haberte pasado muchas tardes jugando a la consola y todo eso. Pero no es lo único, como bien comenté en el punto anterior.

Por otro lado, para ser tester de localización, hay que tener, además, destrezas lingüísticas impecables, como ya expliqué en esta entrada, el proceso de testeo requiere gente con ciertas destrezas y ciertos conocimientos. Si bien muchas de estas destrezas se pueden aprender (o, más bien, se acaban aprendiendo con la práctica), no es posible aprender a escribir un idioma correctamente de la noche a la mañana. Un idioma es algo que se adquiere con el tiempo, algo que hay que adquirir a base de repetir, de observar, de recordar y, sobre todo, de leer (mucho) para que las cadenas de palabras que componen un idioma se te queden grabadas (correctamente) y puedas repetirlas (también de forma correcta).

Además, tampoco basta con: «yo hablo muy bien mi idioma, aunque lo de la gramática y poner comas se me da fatal». Ser tester de localización requiere jugar a un videojuego traducido a otro idioma y encontrar los fallos lingüísticos de la localización de ese juego. Si no sabes colocar bien una coma, un punto o un punto y coma, si no sabes que una palabra se escribe con tilde, ¿cómo vas a darte cuenta cuando el traductor se haya equivocado y te aparezca esa frase con la falta de coma (o punto o punto y coma) o con esa palabra sin tilde? Y no solo eso, ¿qué ocurriría si ves algo que está bien, pero como no conoces bien las reglas, piensas que está mal y lo cambias? Pues eso.

Mito n.º 4: «Un betatester y un tester son la misma cosa».
Respuesta: No. Casi diría que el trabajo de un tester no tiene nada que ver con el «trabajo» de un betatester. Para empezar, los betatester suelen testear de forma gratuita, casi como una afición, mientras que los testers, bueno, para ellos es el trabajo que les paga las facturas, aunque tampoco paguen una maravilla.

Whaa'? Haven't you seen a cat beta-testing?
Las tareas que tiene que llevar a cabo un tester son mucho más amplias, además de más exhaustivas. Los betatesters suelen jugar el juego (o probar el programa) más desde el punto de vista de los usuarios, como jugaría al juego si ya estuviese en la tienda y se lo acabase de comprar. El tester, aunque también hay momentos en los que realiza la tarea de esta forma, siempre suele llevarlo a cabo de forma más mecánica, más planificada y, en muchos casos, también de forma más repetitiva.


Mito n.º 5: «La única tarea que hacen los testers es buscar bugs».
Respuesta: No. No es la única. Para que os hagáis una idea, aquí tenéis una lista de cosas que un tester tiene que hacer en cualquier día de trabajo:
- Preparar planes de pruebas (si eres lead tester) o seguirlos (casi) a rajatabla.
- Introducir todos los errores (bugs) encontrados en una base de datos (además de encontrarlos, claro).
- Repasar todos los errores de la base de datos para ver cuáles se han arreglado y cuáles no. Aquellos que aparecen como «arreglado», hay que verificar que están arreglados, para lo que hay que volver a jugar el juego (pero en la versión nueva).
- Ser capaz de encontrar todos los mensajes de aviso internos del juego (por ejemplo: «La partida guardada está dañada»). Y eso no es tarea fácil. Sobre todo cuando buscas uno que, en verdad, no existe porque al desarrollador se le olvidó añadirlo.

Y, si tienes mucha suerte y consigues que el productor o el dueño del juego te escuchen, también podrías:
- Participar en el desarrollo de requisitos y características del videojuego.
- Contribuir directamente a la mejora del juego (poder sugerir cosas que funcionan y cosas que no, y todo eso que nos encantaría a todos hacer).

Y mucho más.

Hay montones de mitos, a cada cual más gracioso (por lo menos, para los que sabemos que son solo eso: mitos). ¿Habéis oído alguno que no haya mencionado y que queréis que os explique? Ahí os dejo la casilla de comentarios para que os explayéis.

Radio Macuto se despide ya hasta la próxima entrega. Gracias por leer.

jueves, 15 de marzo de 2012

Tester de videojuegos: consejos para la entrevista


¡Hola, chicos y chicas!

No quería que pasase más tiempo sin contaros nada nuevo, sobre todo después de la cantidad de correos y mensajes que he recibido de algunos de vosotros, contándome lo mucho que os gusta mi blog y, lo que aún me anima más, cuánto os gustaría hacer lo que yo he hecho. De todo corazón: gracias, y que no os dé miedo de escribirme, que me emociona mucho leeros. *sobs* *sobs*

Algunos de vosotros habéis acudido a mí preocupados porque teníais una entrevista para un puesto como tester, y emocionada he recordado y os he contado cómo fue la mía, intentando que os sirva de ayuda. Sabéis que me encanta hablar y que no callo ni bajo el agua, pero después de haber tenido que explicar unas cuantas veces el proceso, creo que sería importante que lo explicase en el blog, y no porque me moleste tener que explicarlo (mejor para mí: una oportunidad para ejercitar la lengua o, bueno, en este caso, los dedos), sino porque creo que hay más gente ahí fuera que quieren saber cómo es o que, esperemos, necesiten saberlo muy pronto. A unos cuantos les fue bien (ya sabéis quienes sois), así que espero que os vaya bien a los futuros testers.

Os contaré cómo fue mi prueba/entrevista para el puesto de técnico de control de calidad de localización de español (o sea, tester de español, para que nos entendamos), pero eso no quiere decir que vaya a ser igual en todas las empresas, ni mucho menos.

¿Estáis a punto? Empecemos.

Mi prueba/entrevista consistió primero en un cuestionario que tuve que rellenar un mes antes de la entrevista, con preguntas sobre videojuegos y ejemplos de bugs. Una vez pasabas esa prueba, te llamaban para una entrevista y para hacerte un par de pruebas más. La entrevista/prueba duró tres horas, en las que me hicieron una prueba de traducción, una prueba de búsqueda de bugs (fallos/errores) y una entrevista.

1. Primera prueba, o prueba de preselección.
Recuerdo que había bastantes preguntas (unas diez) y que tuve que recurrir a mis amigos friquis de la universidad varias veces. Como creo que ya os he contado, tuve una época (los cuatro años de universidad) en la que apenas jugué a nada porque no tenía ni consola ni un ordenador decente. Mis momentos de ocio videojueguil se limitaban a algunas horas muertas con el solitario en el ordenador de la universidad, o en el mío, cuando conseguí un portátil que iba con manivela (pero que, oigan, para escribir los trabajos, me bastaba). Por ello, había algunos juegos de los que me hablaban que no conocía. También fue el momento en el que conocí esa palabra con la que los testers tenemos una relación de amor-odio: bug. Sí, señores, hasta entonces no había oído en mi vida esta palabra relacionada con «error informático», y justo una de esas preguntas era explicar un poco lo que era, para mí, un bug (si sabía lo que era) y explicar algunos ejemplos. Así que, desde aquí, quiero agradecer a Iván toda la ayuda (¿o crees que me había olvidado?).
Consejo: no tengáis miedo en preguntar si no sabéis algo. Nadie nace sabiéndolo todo y tampoco necesitas ser un experto en una materia para poder aprender cosas nuevas.


2. Prueba de traducción.
En la primera hora me pidieron que tradujese un texto, sin usar internet, aunque me dieron una de esas cosas de papel, con letras escritas que llaman «diccionario» y que solo ves en las bibliotecas. El texto en cuestión era un trozo del famoso «Léeme» que nadie se lee, en el que hablaba del DirectX 6 (o 7, no me acuerdo. Una versión muy antigua J). A pesar de haber estudiado una carrera de traducción, había muchos términos que se me escapaban porque en mi vida me había leído un «Léeme» de estos (¡maldito el día en que no abrí ninguno para leerlo!). Pero el diccionario, que era bastante gordito, me ayudó bastante. Al final, acabé en 45 minutos (gracias a la práctica que conseguí en la universidad) y se quedaron sorprendidos («Oh, that was quick», me dijo el encargado).
Consejo: como nunca se sabe qué tipo de traducción os puede caer, y teniendo en cuenta de que el género de los videojuegos incluye todo tipo de temas, preparaos traducciones no solo creativas (vamos, las típicas de los videojuegos: «Pulsa X para saltar» o «Your base are belong to us»), sino también textos más técnicos (Léeme, EULA, informes de errores, etc.).


3. Prueba de búsqueda de bugs
Esta parte fue, sin duda, la que más disfruté, ya que te permite hacerte una (pequeñísima) idea de lo que el trabajo será (ya os contaré en otra entrada qué es exactamente lo que un tester hace cada día). A mí me tocó el juego Praetorians, un juego que ya había visto y toqueteado un poquitín hacía muchos años (mi cuñado era «superfans») pero que tampoco era una gran experta.
Me propusieron que mirase primero los textos del menú y que, después, jugase un poquito y apuntase en un folio (sí, sí, ¡escribiendo con un boli en un folio en blanco y todo! ¿A que mola?) todos los fallos que fuese encontrando. Tenía una hora (¿o era media? Buff, siete años pesan). Por supuesto, me hinché a apuntar faltas gramaticales y ortotipográficas. Afortunadamente, encontré un par de fallos de funcionalidad (algún icono que no funcionaba o algún texto cortado y una de las instrucciones ya en el juego que no furulaba muy bien), con lo cual, algo demostré que no era solo correctora sino que, además, también me fijaba en otras cosas. Cuando ya me dieron el trabajo, aprendí que había algo que a todos los entrevistados se les pasaba por alto y era la palabra Loading, que no estaba traducida. En cuanto me lo dijeron, me obsesioné, y ahora es algo que siempre busco.
Consejo: ¡que no se os olvide aseguraros de que «Loading» aparece traducido («Cargando»)! Si de verdad queréis trabajar como testers (y como localizadores), prestad mucha atención a los videojuegos que jugáis; mirad qué funciona y qué no, qué podría mejorar; fijaos en el texto, en su corrección gramatical y ortotipográfica, en si se podría expresar mejor (Álvaro escribió un par de entradas analizando uno de los videojuegos que jugó, así que os aconsejo que le echéis un vistazo: aquí y aquí.). Vuestra capacidad de prestar atención y fijaros en los detalles será la herramienta de trabajo más importante y valiosa. Sin ella, un tester es solo medio tester.


4. Entrevista
Esta parte es la que tienen en común todas las entrevistas de trabajo. ¿Qué os voy a contar? Que me costó horrores entender a uno de los entrevistadores porque no hacía ni cuatro meses que había aterrizado por estas tierras perdidas por los mundos de la reina Elizabeth. Durante la entrevista, inspeccionaron mi currículo punto por punto. Recordad que yo había acabado la carrera seis meses antes, y había cogido las maletas y me había plantado en Londres sin trabajo, acogida solo durante una semana por unos conocidos. La única experiencia laboral que tenía era como camarera, como azafata de tierra y como promocionadora de Polaroid, así que me tuvieron ahí justificándoles todo lo que había escrito.

Después, pasaron a las preguntas sobre mí y sobre lo que sabía. No las recuerdo todas, pero sí que recuerdo que me preguntaron que si conocía la consola Xbox (la entrevista fue a principios de 2005). Mi cara debió ser un cuadro, puesto que me sonaba (había visto anuncios en la tele y esas cosas, pero nunca había tenido ninguna en mis manos), pero se me escapó un «I have heard of it, but I have never seen one» (he oído hablar de ella pero nunca he visto una), así que ambos entrevistadores se giraron hacia una televisión que allí había y me señalaron a una «caja de plástico verde» y dijeron: «It’s that one» (es esa). Después de reírnos, les di las gracias y les dije que sí, que la conocía, y volvimos a la entrevista. Otra pregunta que me hicieron fue cuál era mi videojuego favorito. Yo me había estudiado el sitio web de la empresa, y me había alegrado al ver que esa empresa era la dueña de uno de mis juegos preferidos, Tomb Raider, así que aproveché y les dije que, sin duda, era una fan incondicional de Tomb Raider, y que había jugado a los tres primeros (cosa que era verdad, pero luego descubrí que lo de fan incondicional sería porque no había jugado a los siguientes, que al parecer habían sido un truño). Parece que mi respuesta les gustó, porque me pidieron detalles del juego, que tuve que recuperar de algún lugar perdido por mi cerebelo. También me preguntaron por más juegos de la empresa, y les nombré unos cuantos que había visto en el sitio web, y otros que conocía de oídas (como Hitman o Commandos). Luego vino el turno de una pregunta que suelen hacer en muchas entrevistas y que parece que fue la que hizo que se les encendiese la chispa del «She is good».

La pregunta fue: «¿Dónde te ves en cinco años?». «Buff, cinco años», pensé; vete tú a saber ande andaré dentro de cinco años. Mi intención era volver a España después de uno o dos años (¡ja, ja, ja, ja!), pero no podía decirles eso por si no me cogían, así que, ni corta ni perezosa, miré a uno de ellos (el que me parecía que tenía un puesto más elevado) y le solté: «I see myself in your job, I hope» (me veo con tu trabajo, o eso espero). Nos reímos mientras le explicaba que, por supuesto, él también habría subido de nivel, que no es que le quite su trabajo, sino que yo llegaría a su nivel. Siete años más tarde, no estoy en su puesto, pero sí que he avanzado mucho. Una semana y pico después de aquella anécdota, empezaba mi primer trabajo «como dios manda».  



Otras preguntas fueron las típicas de «Puntos fuertes y puntos débiles» o «Un momento en el que te encontraste con un problema gordo y cómo lo arreglaste», «Cómo me resuelvo con el trabajo en equipo» o «qué puedo aportar a la empresa».



Consejos: como en cualquier entrevista para cualquier puesto de trabajo, es muy importante que conozcáis la empresa para la que queréis trabajar, además del puesto de trabajo. Ahora tenemos la suerte de que prácticamente todas las empresas tienen sitio web, así que no hay excusa para no memorizársela y tener toda la información posible para poder no solo contestar a las preguntas, sino también para poder impresionar con vuestros conocimientos sobre la empresa.
Lo más importante para cualquier entrevista es ser uno mismo. Seguramente, los que os hagan la entrevista han hecho muchísimas, han visto todo tipo de personas y tendrán experiencia sabiendo quién miente y quién no. Por supuesto, también hay gente experta en hacer entrevistas y que ni el más experto entrevistador sabría si lo que dice es verdad o no, pero, al fin y al cabo, se coge antes a un mentiroso que a un cojo, y si habéis mentido en vuestro currículo y en la entrevista, os pillarán cuando empecéis a trabajar. Yo siempre hago las entrevistas como si me fuese al bar a hablar con amigos, y me ha venido muy bien varias veces, así que creo que es el mejor consejo que os puedo dar.


Y aquí acabo, no sin antes pedir a todos aquellos que hayan pasado por el mismo proceso para llegar a ser tester que nos cuenten su experiencia. Como ya he dicho varias veces, cada empresa es un mundo, y cada trabajador es un mundo distinto intentando ser compatible con el primero.



sábado, 12 de marzo de 2011

Control de Calidad, Localización y Experiencia: la Combinación Perfecta para la Mejor Localización (y V)

Como ya expliqué en mi anterior entrada, lo que a todos nos parece que es el trabajo ideal para los amantes de los videojuegos, no es tan bonito como nos puedan hacer creer algunos. Además, para poder llegar a ser un buen experto en control de calidad, se necesita mucho más que simples habilidades «videojueguiles» o conocerse de pe a pa la lista de los juegos más vendidos de la historia.
Pero nos siguen surgiendo dudas en esto de «la localización de calidad», sobre todo en cuanto a qué profesionales escoger, cómo deberían trabajar o si es mejor contratarlos de forma interna o dejarles que trabajen en casa. Eso es lo que pasaré a explicar.
4.- Interno vs Externo
Muchas compañías podrían pensar que tener un equipo de traductores internos es demasiado caro, ya que la compañía tiene que pagar todos esos gastos adicionales que no tendría si fuesen externos. Sin embargo, no tiene por qué ser así.
Las traducciones pueden hacerse de forma externa bien por traductores independientes o por agencias. Es verdad que la opción cómoda sería subcontratarlas a agencias, ya que solo necesitas enviar el texto, sin preocuparte del volumen, y se pueden preocupar de un gran volumen de traducciones en un período corto de tiempo. Sin embargo, es aquí donde puede perjudicarse la calidad del producto final. No diré que es el caso de todas las agencias pero, en general, guando una agencia puede llevar a cabo grandes volúmenes de palabras es porque el texto no lo traduce completamente la misma persona, sino varias, y es ahí donde puede haber contradicciones, falta de coherencia y errores. Claro que, si la traducción la corrige una misma persona, muchos de los problemas pueden solucionarse. Sin embargo, ¿no creéis que sería mucho más seguro si solo hubiese un traductor y un corrector?
Además de todo esto, hay que tener en cuenta la diferencia entre trabajar con varios intermediarios o trabajar directamente con el traductor y el corrector. La principal diferencia es que, con tanta gente de por medio (por razones obvias), no todo lo que se paga a la agencia acabará en manos del traductor (muchas veces, ni siquiera una cuarta parte), con lo cual, se corre el riesgo de que el encargado de tu traducción y/o corrección tenga que trabajar bajo presión, muchas horas y sin apenas recibir dinero a cambio, lo que, a la larga, podría frustrar al traductor o hacerle sentirse «poco apreciado», y esto podría repercutir en la labor final. No hace falta echarse las manos a la cabeza aún, ya que esto tiene más lógica de la que parece. Cualquier trabajador que tenga que trabajar horas extra para poder llegar a fin de mes, trabajará más de la cuenta y, por lo tanto, estará más cansado. De esta forma, el rendimiento se verá reducido y los errores pueden ser mayores. Si a esta persona se le sube el sueldo y, por ello, puede dejar de trabajar horas extra, estará más descansado, más concentrado y, en definitiva, más feliz. Incluso si sigue trabajando esas horas extra, pero el sueldo «extra» es muy bueno, cuando acabe el proyecto, podrá pagarse unas vacaciones para relajarse (y premiarse) por todo el trabajo realizado.
Pero volvamos con nuestros traductores y correctores y con nuestra calidad. ¿Qué tal si pudiésemos tener al traductor justo al lado del programador? Si tenemos estos traductores trabajando en la propia empresa podría ser la forma más rápida de conseguir la traducción más rápida y de mayor calidad. Podría parecer que es más caro, pero si piensas en todo el control que un desarrollador o distribuidor puede tener sobre las traducciones, al final, acaba siendo más barato que enviar las traducciones a una agencia (que acaba siendo la opción con más intermediarios y que puede suponer también mucho dinero en gastos administrativos). Otra alternativa igualmente buena, sobre todo si la empresa no tiene sitio en la oficina para uno o dos traductores por idioma, podría ser enviar estas traducciones a traductores y correctores independientes.
De esta forma, la empresa de software puede trabajar directamente con los traductores, resolver cualquier duda que estos tengan, escuchar sus sugerencias, etc., y todo esto, sin que haya gente de por medio. Es una forma muy cómoda: siempre se puede enviar una copia protegida del juego, o una muestra del mismo, o incluso enviar capturas de pantallas de forma instantánea usando programas de mensajería instantánea (skype, msn) o, incluso, usando algo como DropBox. Por supuesto, todo esto podría mejorarse aún más si se le ofrece la oportunidad al traductor de trabajar en la oficina, donde el juego se está creando y donde puede hablar con los programadores, diseñadores y el resto del equipo, y expresar cualquier cosa que necesite sin tener que menear correos electrónicos de un lado a otro.
¿Y qué hacemos con las pruebas de control de calidad? Con esto puede hacerse algo muy parecido. Si bien es cierto que hay muchas empresas que ofrecen servicios de testeo, y hasta servicios de traducción, para saber si realmente estás usando bien tu dinero, hay que saber cómo funcionan por dentro. [Peligro: si trabajas en una de ellas, no leas, o puede que hiera tus sentimientos ;)] Mientras trabajaba como jefe de proyectos de control de calidad de localización (o, en su versión corta, Lead tester), tuve que trabajar con dos de las compañías de testeo más importantes del Reino Unido y, creedme, fue duro. Podría contar montones de historias y anécdotas que tuve con ellas, pero prefiero limitarme a explicaros los hechos, y ya sacaréis conclusiones.
Las compañías con las que trabajé mientras estaba en Eidos, trabajan en turnos, de forma que, muchas veces, la tarea que ha empezado un probador, la finalizará otro. Hay casos en los que las instrucciones dadas en un momento determinado se dan únicamente al probador que esta testeando en ese turno, con lo cual, si es algo importante que hay que cumplir, o alguna parte del juego que hay que evitar, puede que el probador del turno de después no se entere, de forma que pierda el tiempo testeando algo que no debería, o testeando algo sin seguir las instrucciones del cliente. Otro de los problemas con los que me encontré en otro proyecto donde los que hacían el control de calidad de funcionalidad se encontraban en Canadá fueron las diferencias horarias (y ya no solo con compañías en diferentes husos horarios sino también, una en el mismo país pero que trabaje durante un turno diferente al tuyo), de manera que, si había algún problema durante el proceso de testeo, no te enteras de nada hasta que llegabas al trabajo al día siguiente.
Por supuesto, lo bueno de estas empresas es que pueden trabajar durante más tiempo (según qué compañías, hasta 24 horas al día). Sin embargo, ¿no creéis que sería mejor que tu juego lo mirase siempre la misma persona o personas, con el mismo horario que tú y que siempre tenga la última información que le encargue el jefe de proyectos? ¿Y qué me decís de tenerlo cerca, para poder consultar cualquier duda? O incluso poder tener contacto rápidamente por medio de videoconferencia, o que pueda acudir al cliente (desarrollador/distribuidor) de vez en cuando. Yo creo que sí es mejor.
Por otro lado, teniendo en cuenta de que, en algunos casos, hay compañías que no llevan a cabo el control de calidad de los productos localizados, sí que deberíamos asegurarnos de que la localización de los productos sea de la mejor calidad y, sobre todo, esté realizada por gente experta en la materia, que conoce bien cómo son los videojuegos por dentro… Más que nada, para evitar sorpresas. Aún así, sigo recomendando a todas las empresas de videojuegos que se gasten un poco de dinero en el testeo… Porque su juego lo vale :)

5.- El traductor y el tester, ¿deberían ser la misma persona?
Con toda la información que he ido dando en estas cinco entradas, seguro que ya podéis iros contestando a esta pregunta, aunque cabe decir que no hay una única respuesta «válida» (el osito de peluche de la feria habrá que repartirlo). Eso sí, la última decisión dependerá siempre de las circunstancias de la compañía, de sus decisiones de marketing o, incluso, si tienen alguna limitación legal.
La mayoría de los distribuidores grandes tienen su propio equipo de control de calidad interno (aunque con la crisis, muchos han preferido prescindir de ellos). Los desarrolladores también tienen uno. La decisión sobre si contratar los servicios de traducción a traductores independientes o a una agencia recae en el desarrollador o distribuidor. Si se decide optar por la agencia y el equipo de control de calidad interno es bueno, la localización del producto será seguramente buena, pero no sin un gran esfuerzo por parte de los pobres probadores. Sin embargo, si la empresa decide prescindir del testeo y decide optar por enviar la traducción a una agencia, donde puede haber 4-5 traductores y 2-3 correctores (que, tal vez, no tengan experiencia en videojuegos)… Bueno, eso ya es otro tema.
Teniendo en cuenta la experiencia que he tenido trabajando como probadora de videojuegos, trabajando también para algunas de las agencias de traducción que nos hacían las traducciones a nosotros, y trabajando como localizadora independiente, experta en videojuegos, creo que la mejor opción para conseguir la mejor localización es que el traductor esté también involucrado dentro del proceso de testeo, bien sea de forma interna (con testers que tengan experiencia traduciendo o que tengan una carrera en traducción) o de forma externa, por traductores independientes con experiencia en control de calidad. En este último caso, también se podría pedir al traductor que acudiese a las oficinas una temporada para llevar a cabo el testeo, aunque también podría alternarse que trabaje desde casa y que, de vez en cuando, vaya a la empresa a ultimar algunas cosas, preguntar o, simplemente, participar de forma activa en el diseño del producto.
De esta forma, el creador del videojuego puede asegurarse en todo momento que su producto está en las mejores manos y conseguir la mejor calidad en el producto localizado. Además, a largo plazo, también será la que supondrá un gasto menor a la empresa. Ya sabéis, lo barato acaba siendo caro.

miércoles, 23 de febrero de 2011

Control de Calidad, Localización y Experiencia: la Combinación Perfecta para la Mejor Localización (Parte IV)

Como estuve explicando antes, para conseguir un buen producto localizado, hay dos cosas que son básicas:

a) Una buena localización

b) Un buen control de calidad

El proceso para obtener una buena localización ya lo expliqué en mi anterior entrada, así que, ahora pasaremos al siguiente punto:


B) CONTROL DE CALIDAD

Esta es la parte que todos los friquis adoran, y también la razón por la que mis amigos friquis españoles solían odiarme cuando trabajaba como tester J

Existe la creencia (falsa) de que el control de calidad es pasarse horas jugando un videojuego hasta que lo acabes… Veinte veces. No, no deberíamos considerarlo a la ligera. Un probador de juegos, o técnico de control de calidad, más conocido como tester, necesita mucho más que saber jugar a un juego para considerarse un buen tester.


¿Qué necesita un técnico de control de calidad (o tester)?

1. Capacidad para llevar a cabo tareas repetitivas

El proceso de testeo es una tarea repetitiva que puede durar desde un solo día a varias semanas, o incluso meses. Funciona de forma diferente dependiendo de si eres un técnico de control de calidad de funcionalidad, que trabaja con el juego en la lengua original, o uno de localización, que trabaja con el juego localizado, aunque las cualidades básicas necesarias sean las mismas.

El proceso empieza cuando el tester recibe una versión del juego, llena de errores. Si eres un tester de funcionalidad, tu jefe de proyectos te pedirá que te concentres en un solo nivel, por ejemplo, el nivel 1. Sin embargo, el nivel 1 se queda bloqueado justo al principio, cuando intentas matar al enemigo número 2 con una metralleta. No te das cuenta de la relación hasta que la consola se ha bloqueado, al menos, 10 veces. Por ello, decides escribir un bug en la base de datos de errores y usar el cuchillo para matarlo y, así, poder continuar con el nivel.

Ah, ¿que no sabéis lo que es un bug?

Un bug es «un error o defecto en un programa que puede hace que no funcione correctamente o cuyo resultado sea incorrecto o inesperado». Así que, el tester introduce todos estos errores en una base de datos que comparte con todos aquellos involucrados en la creación del juego, de forma que los programadores pueden ver la lista cosas fallan en el código del juego arreglarlas (cuando puedan o quieran). Simplificando, esta base de datos es la forma en que los probadores y los desarrolladores se comunican, aunque, a veces, la «comunicación» pueda ser difícil.


Pero volvamos al testeo... Hemos quedado que te pasas 8 horas al día jugando al mismo nivel, cambiando la metralleta por el cuchillo cuando ves el enemigo número 2 (vas por detrás, sin que te vea, para degollarlo), vuelves a equiparte con la metralleta y sigues jugando hasta que terminas el nivel. Y vuelta a empezar. Al principio parecerá muy emocionante y divertido; sin embargo, tras tres o cuatro meses empiezas a plantearte si no sería mejor trabajar en McDonalds J

2. Atención por los detalles

Esto podría parecer fácil: observación pura y dura. Pero no es así. Cuando has jugado al mismo juego (o el mismo nivel) 20 veces, la parte mecánica del cerebro empieza a acostumbrarse y, por ello, empiezas a jugar como una máquina, sin fijarte en apenas nada. Seguramente pueda explicaros la secuencia de movimientos y enemigos del primer nivel de Tomb Raider: Legend, el cual habré jugado como 30 veces por plataforma, es decir, 7 plataformas. Así que, creedme cuando os digo que no es ni fácil ni divertido (al cabo de varias repeticiones) J

Imagino que la parte más importante de esta atención por los detalles necesaria se basa en tener una buena memoria visual de forma que el tester pueda darse cuenta de todo aquello que no es como era antes o como debiera ser y, así , poderse asegurar de que todo está bien.

3. Conocimiento de idiomas

Incluso si eres tester de funcionalidad y solo hablas un idioma, es importante tener un buen conocimiento escrito del dicho idioma. Y, ¿por qué?, os preguntaréis. Pues por el simple hecho de que, puede que aquellos que escriben los textos originales no es que sean los más diestros en el mundo literario (son programadores e informáticos; no les das trabajo para que te escriban una novela sino para que te programen), de manera que el tester tendrá que asegurarse de que el texto original del juego es preciso y no confunde al jugador.

Si eres un tester de localización, el buen conocimiento escrito de tu idioma materno es aún más necesario, ya que serás el último paso dentro de la cadena de localización y deberás asegurarte de que el texto traducido sea correcto, exacto y, bueno, todo en el mismo idioma.

4. Experiencia con videojuegos

Que te guste jugar a videojuegos y que, además, se te dé bien, sirve de mucho en esta profesión, porque de verdad te vas a pasar horas y horas jugando. Sin embargo, si tuviese que escoger entre alguien que no tiene ni idea de escribir correctamente ni deletrear pero que juega a videojuegos, o alguien con un gran dominio de su idioma materno pero que, sin embargo, no sepa mucho de videojuegos, sinceramente, me pillo al filólogo. Todos podemos aprender a jugar a un videojuego en cierto tiempo. Enseñar un idioma es mucho más difícil.

5. Dotes de comunicación

No es tan fácil como parece. Comunicarse no es hablar, sino asegurarse de que se envía el mensaje correcto y que llega a la persona adecuada. Como en cualquier empresa, la comunicación entre los trabajadores es importante. De la misma forma, una buena comunicación entre los probadores y el resto de personas involucradas en el proceso de creación del juego es imprescindible. En algunos casos, puede que el ingeniero en localización haya encontrado un error importante que haga que el juego entero se fastidie y, por ello, es mejor detener el proceso de testeo y pedir a los desarrolladores que envíen una nueva versión que trabajar sobre una versión con la que apenas se puede hacer nada. Si el proceso se detiene, evitaremos tener que hacer lo mismo dos veces. O, por ejemplo, como me ha pasado varias veces, necesitas que el juego esté en tu idioma, pero la versión que te han dado está entera en otro idioma, así que, no tiene sentido seguir testeando. En estos casos es mejor, más rápido y más eficiente comentárselo a tu supervisor o al jefe del proyecto para que llame a los desarrolladores y les pida una versión nueva. Si no eres buen comunicador, podrías no darle importancia y tardar en comunicarlo, lo que retrasaría el proceso de testeo.

6. Saber qué quiere el cliente

Esto suelen ignorarlos tanto los distribuidores como los desarrolladores y, aún más, si los testers no forman parte de la compañía. En el caso de los videojuegos, ¿quién conoce a la perfección qué es lo que el jugador (o gamer) quiere? Aquel que pasa 8 horas jugando al juego, y ese es única y exclusivamente el tester. Muchas veces he trabajado con gente que me decía qué tenía que hacer pero que no habían cargado el juego ni una sola vez. ¿Cómo pueden entender el problema que hay o lo que debería cambiar si no conocen el juego por dentro? Eso sí, si el juego es una mierda, por supuesto, culpan al tester… Esto… ¿perdona?

7. Buen conocimiento de los estándares de los titulares del formato

Este punto es más específico para los videojuegos de consola y de PC, pero también pueden verse de otro modo en otros juegos como los juegos de apuestas, los de iPhone o, incluso, los juegos el línea en portales tipo Facebook. En el caso de los últimos, hay un poco de flexibilidad, pero aún necesitas conocer lo básico sobre sitios web. En el caso de las consolas y los juegos para PC, es decir, Sony, Nintendo y Microsoft, los estándares son, para ellos, lo más importante del juego. Si el juego se puede jugar y los estándares usados son correctos, las compañías aprobarán la publicación de los juegos. Sin embargo, si tienes el juego más impresionante pero los estándares no están a la altura de lo que te piden, no aprobarán el juego y el desarrollador o distribuidor dueño del juego podrá pasarse mucho tiempo y gastarse mucho dinero para conseguir solucionar el problema.

Lo gracioso es que, mientras trabajaba no solo como tester sino también como jefe de proyectos, me vi obligada, en más de una ocasión, a dar lecciones sobre estándares a algunos desarrolladores. Creedme, no es divertido, en especial porque casi nunca te creen.

Así que, a todos los traductores, testers, productores, programadores y desarrolladores del mundo: por favor, haced los deberes y aprender los estándares, que no cuesta nada y saldréis ganando.


En resumidas cuentas, para conseguir llevar a cabo un buen control de calidad, no basta con entretenerse con el juego durante horas sino que también hay que prestar atención, conocer muy bien tu propio idioma, saber qué quiere el cliente, conocer las exigencias de los creadores del formato y, además, saber comunicarse con aquellos que están metidos en el meollo contigo.

domingo, 13 de febrero de 2011

Control de Calidad, Localización y Experiencia: la Combinación Perfecta para la Mejor Localización (Parte III)

En mi anterior entrada, hablé sobre lo complicado y creativo que es, a veces, crear una buena localización que se adapte a las exigencias de la censura de un mercado en concreto, y lo bien que funciona dicho producto cuando está bien localizado. Pero os preguntaréis, ¿qué puedo hacer para que mi producto esté bien localizado?

3.- ¿Cómo conseguir un producto bien localizado?

Tras haber leído el punto anterior, seguramente os preguntaréis: ¿Qué tengo que hacer para conseguir una de estas localizaciones de calidad? Bueno, hay dos cosas que son básicas:

a) Una buena localización

b) Un buen control de calidad

Quizá pueda parecer algo simple y obvio, pero no siempre se realizan ambas, ni tampoco se realizan correctamente. Por ello, explicaré lo que, bajo mi experiencia, debería ser el proceso para conseguir un buen producto localizado.


A) BUENA LOCALIZACIÓN

1. Saber qué estás localizando.

Seguramente ya sabréis (por experiencia propia o porque os lo habrán contado) que una traducción sin contexto es mucho más difícil de hacer de lo que la gente suele pensar. Si te diesen una palabra sin ningún contexto, seguramente podrás encontrar 3-4 significados, o más, para dicha palabra. Lo mismo ocurre con los videojuegos. Aunque normalmente puedes encontrar contexto dentro del propio texto, también necesitas imágenes, o conocer qué hacen cada uno de los comandos, para entender de qué va la cosa. Por ello, el traductor debería familiarizarse con el juego, saber de qué va, quiénes son los personajes, etc. El cliente podría enviarte toda la información, capturas de pantalla, explicaciones… Todo esto es muy útil, pero, aún así, no se tiene la sensación de conocer el juego «al dedillo». Es por eso que creo que la mejor forma de conseguir este contexto es, simplemente, jugando al juego.

Familiarización con el producto → Jugar al juego/Usar el programa.


2. Asegurarse de que se tiene al traductor adecuado.

De la misma forma que usarás un traductor jurado para traducir un acta judicial o un contrato, o a un traductor científico para traducir un libro sobre Ciencia, ahora es el momento de conseguir el traductor especializado no solo en videojuegos pero también en el tipo de videojuego en concreto que vas a crear. Unos traductores se sentirán más cómodos traduciendo juegos de guerra, mientras que otros prefieren juegos más creativos. O a lo mejor necesitas un fanático de las armas o un experto en criminología para tu videojuego, o un friqui de Star Wars o una amante de la gimnasia. Podríamos compararlo con los gamers: algunos prefieren los juegos de tiros, otros se lo pasan mejor con juegos party o con puzles, mientras que otros prefieren juegos de deportes. Como localizador, podría aplicarse esta misma clasificación. Por poner un ejemplo un poco tópico: si le das un juego de Barbie sobre moda a un tío, seguramente sudará la gota gorda para conseguir una buena localización, mientras que si le das un juego de guerra a una tía, tal vez acabe agobiando a su novio con preguntas sobre términos bélicos. Por supuesto, también puedes investigar mucho y aprender a medida que haces este tipo de juegos, pero lo ideal es darle cada proyecto a la persona que podría hacerlo mejor y en el menor tiempo posible, ya que tiene la experiencia y el conocimiento adecuados.

Asegurarse de que es el adecuado → Asignar a cada traductor el proyecto que mejor se adapte a su conocimiento y experiencia.


3. Asegurarse de que el traductor lo entiende todo

Por desgracia, es bastante corriente encontrar textos originales (en mi caso, en inglés) que no están bien escritos (con errores y faltas de ortografía) o que tienen referencias culturales o que alguien de otra cultura o país no puede entenderlas. Por ello, los desarrolladores deberían asegurarse de que el texto original pasa por un revisor antes de enviarlo a los traductores para que lo localicen. Eso nos ayudará mucho a los expertos en localización. Por otro lado, si eres un experto en localización, asegúrate de centrarte solo en aquello que realmente conoces. Sin embargo, si ya estás traduciendo algo en lo que te especializas, no dudes en «molestar» al cliente, desarrollador o agencia, preguntándoles todo sobre el juego o pidiendo aclaraciones sobre cualquier problema que tengas durante la traducción. Si, aún así, sigues teniendo dudas, pregunta amigos expertos en el tema (todos tenemos un amigo informático, médico, policía, etc.).

Sí, amigos, esto es precisamente lo que una buena localización necesita: colaboración entre ambas partes.

Asegurarse de que el traductor lo entiende todo → Colaboración cliente-traductor.


4. Corrección

Aunque esto no es un punto obligatorio si has escogido al traductor adecuado, se recomienda hacerlo, sobre todo si se ha eliminado el proceso de control de calidad de la localización del juego. 4 ojos ven mejor que dos, y siempre es bueno tener una segunda opinión. Sin embargo, la corrección también podría incluirse en el siguiente paso que voy a explicar: el control de calidad.

Corrección → 4 ojos ven mejor que dos

~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~


Sí, ya sé que muchos de vosotros sabéis todo esto, pero creedme, no todo el mundo se da cuenta de que no basta con darle el texto a un traductor y olvidarse del tema, o que la corrección no es necesaria si se han entregado 35 000 palabras al traductor para traducir a toda leche y entregar en un tiempo récord.

Pero eso no es todo. No basta con hacer una buena traducción y añadirla al código y, hala, ya se puede poner a la venta. Incluso aunque se tenga al traductor más experimentado, es aconsejable que la traducción siempre pase por la segunda parte del proceso de un buen producto localizado: EL CONTROL DE CALIDAD

Pero de ello hablaré en mi próxima entrega J