Testear y jugar son cosas bastante diferentes. Testear es, básicamente: detectar los errores de un juego, reportarlos de forma adecuada (con pasos exactos para reproducirlos) y después verificar que el error ha sido tratado correctamente.Aunque parece ser que hay un sueño entre los “gamers” de que “te paguen por jugar”, esta profesión es muy diferente a como los aficionados se imaginan. Una de esas diferencias fundamentales es la profesionalidad. Voy a guiarme por el estupendo libro de Luis Levy y Jeannie Novak, “Game QA and Testing“ durante el resto del artículo, porque me parece genial para introducirse, como me pasa a mí, en este mundo del testing de la mano de profesionales.

¿De dónde viene el Testing?

Al principio, el testing se hacía mientras se creaba el juego. Eran juegos poco complicados, y comprobar la mayoría de posibilidades era una cosa accesible: programar por la mañana, testear por la tarde. Todo era mucho más artesanal.

Conforme los juegos se fueron volviendo complejos, el testing seguía siendo una tarea dependiente de los cada vez más estresados programadores. Esto dio lugar a que, sencillamente, se testeara poco y mal. Fue uno de los factores precipitantes del Crash del Videojuego de 1983, donde el mercado estaba tan sobresaturado de títulos tan malos (y a los buenos les costaba destacar), que la gente perdió interés en el entretenimiento electrónico.

Fue Nintendo con su NES y su Seal of Quality la que comenzó a introducir en el videojuego los estándares de calidad. Si alguna vez os habéis preguntado en qué consiste exactamente (o si creíais que esto no servía para nada, porque total, con la m**** de juegos que salen a veces…) era una serie de “puntos clave” (conocidos en Nintendo como Lot Check, nombre que tienen aún hoy día) que todo juego tenía que pasar para asegurarse de que el juego no se sobrepasaba de la raya en ciertos aspectos críticos.

Las compañías que querían producir para NES (prácticamente todas porque Nintendo tuvo el monopolio absoluto del mercado de consolas doméstico) tenían que pasar este Lot Check, por lo cual ellas mismas empezaron a crear departamentos de calidad internos que evolucionaron a lo que hoy conocemos como Quality Assurance, o QA para abreviar. Que es donde trabajan los testers.

 

Clasificación de los bugs

La mitad de lo que vale un tester queda definido por lo bien que sea capaz de introducir bugs en el software de bug-tracking, una base de datos que todo el equipo comparte y que está especialmente diseñada para gestionar bugs y llevar un control del estado de cada uno. Los testers, bajo la supervisión de su jefe de departamento, abren nuevos informes de bugs, que deberán rellenar de forma concisa, sin ambigüedades, sin repetirse y todo lo breve que sea posible para facilitar la eficacia. Por esto el tester debe ser capaz de reproducir el bug y redactar los pasos necesarios para que el desarrollador lo pueda hacer después en su puesto con la máxima eficiencia.

Por todo esto, un tester debe ser buen comunicador. Pienso que es un contraste bastante interesante respecto a la imagen del típico tipo incapaz de comunicarse que piensa que va a cobrar por jugar a videojuegos. Ser “gamer”, de paso, es un plus bastante interesante.

Como comentábamos al principio, un error (mejor llamarlo “bug”, para evitar los matices de la palabra “error” que son más imprecisos ) es algo que no va como debería. Puede ser de carácter positivo si hay algo que no está bien o negativo si falta algo que debería estar. Esta clasificación es también ambigua, así que los testers han desarrollado una taxonomía más útil para su trabajo. No obstante, ¡recordemos que cada compañía tiene su propia idiosincrasia para el testing!

Gravedad del bug

Un bug puede ser clasificado en función de lo grave que sea para el buen desarrollo del juego.

• Low Priority: Un bug que es una inconveniencia pero no afecta el desarrollo del juego, como una distorsión casi inapreciable en el sonido o un texto en un color levemente más oscuro de lo que debería. Estos bugs son de baja prioridad, hay bugs mucho más importantes a los que prestar atención.
• Medium Priority: Un bug que es una inconveniencia o molestia, pero no llega al extremo de afectar la jugabilidad. Pueden ser glitches gráficos, textos que se salen de pantalla o tienen errores tipográficos…
• High Priority:Bugs mucho más severos. Estos sí afectan al juego y deben ser arreglados lo antes posible. Pueden ser cosas como que falte un sonido, algún punto en el mapa en el que el jugador se queda atascado, un diálogo que no se abre…
• Critical Priority: Estos bugs no deberían de existir en el producto final. Interrumpen el juego directamente. Un cuelgue, reinicio de la consola, congelación de la pantalla, corrupción de las partidas guardadas… Son lo primero que se intenta arreglar cuando se detectan.

 

Categoría del bug

Esta forma de clasificar un bug define su naturaleza, y por eso será mucho más fácil dirigirla al equipo que puede más probablemente arreglarlo.Un bug puede pertenecer a la categoría de…

• Visual (clipping, z-fighting…)
• Audio (mala sincronización, sonidos que se omiten…)
• Diseño de niveles (puntos en los que te quedas parado, puntos muertos del mapa, puntos inaccesibles…)
• Inteligencia artificial (puntos por los que no pasa la IA, o no puede hacer cosas que debiera como abrir puertas…)
• Física (objetos que flotan cuando no deberían, colisiones extrañas o inexistentes…)
• Estabilidad (crashes, cuelgues…)
• Rendimiento (los FPS bajan muchísimo en ciertos puntos del juego, los vídeos van a trompicones…)
• Red (lag, no puedes conectar con amigos, el servidor se cae…)
• Compatibilidad (algunos periféricos que deberían ser compatibles no lo son, tarjetas de vídeo que crashean…)

Una de las cosas que me confundían a mí al principio era el tema del diseño. En su libro, Levy y Novak hablan bastante sobre un tipo de testing cuya responsabilidad se hibrida con el departamento de diseño: es el testing de jugabilidad: comprobar si los personajes están equilibrados, si no hay combinaciones abusivas, opciones de juego extrañas… Sin embargo, parece que este tipo de testing pertenece a otra familia de testeo (o yo no lo estoy comprendiendo bien) y normalmente cuando uno trabaja como tester, no le tocan este tipo de cosas.

Si que he visto este tipo de testing en algunas betas cerradas y betas abiertas en las que he podido participar (por ejemplo Neverwinter), donde se les pide a los usuarios que reporten todo tipo de feedback y, sobre todo, aspectos del juego que pudieran romper la experiencia, como armas demasiado potentes o misiones demasiado largas o complicadas. Pero participar en una beta de este tipo, donde se juega para disfrutar además del interés adicional de ayudar; no es lo mismo que ser un tester, donde hay que trabajar y se recibirá una remuneración económica. Es bastante diferente. Es un trabajo con todo lo que ello implica.

¿Cómo se reporta un bug?

Los testers hacen pruebas siguiendo las indicaciones de su jefe de departamento (QA Lead) y van generando para cada bug un reporte. Entonces los desarrolladores cogerán esos bugs y tratarán de arreglarlos. Después, el tester correspondiente verificará que el bug ha sido correctamente arreglado y “cerrarán” el bug.

Un bug puede estar en estado…

• Abierto: El bug ha sido reportado, pero está en espera de que el QA Lead lo asigne al departamento de desarrollo correspondiente (un bug de programación irá para los programadores, un bug de arte irá para los de Arte).
• Asignado: El bug ha sido asignado ahora y está en la cola de ser arreglado.
• Resuelto: El bug ha sido arreglado, o eso dice el desarrollador correspondiente.
• Verificado: Es tarea del tester coger los bugs “resueltos” y verificar que lo han sido satisfactoriamente. De ser así, el bug pasa a estar “Cerrado”.
• Cerrado: El bug ha sido arreglado y verificado.

Lo ideal sería que antes de introducir un bug en el sistema, el tester compruebe (o lleve la cuenta de algún modo) de que no esté previamente introducido. Esto es importante, porquesi hay muchos duplicados del mismo error, además de la pérdida de productividad de todo el equipo, es posible que se introduzcan errores adicionales por tratar de arreglar un problema que ya no existe.

También es importante que el tester indique claramente la versión del juego en la que ha descubierto un error: Es muy posible que cada semana o cierto periodo salga una nueva versión para ser probada y si no se tiene esto en cuenta, puede liarse un caos tremendo.

Es posible que un bug también sea devuelto como:

• Will Not Fix: El bug no será arreglado por ser considerado de poca gravedad por el desarrollador.
• Duplicate: El bug está duplicado. Hay que intentar minimizar esto lo máximo posible, y es en buena parte responsabilidad del tester.
• Not A Bug : Cuando el bug “no es un bug” sino que es un comportamiento pretendido del juego. Si un tester tiene muchos NAB en los bugs que reporta, quiere decir que no está entendiendo bien el juego o no está haciendo bien su trabajo.

 

Posiblemente, el de tester sea un trabajo duro en cuanto a lo repetitivo y mecánico que puede volverse. No obstante, por esto mismo, el QA Lead suele alternarles tareas y asignar diferentes listas de “cosas a comprobar”. Sin embargo, y pese a todo, el de tester es un gran puesto y un escalón dentro de la industria que exige nuestra atención, seriedad y tiempo. Un trabajo, nada de juegos. ¡Lo que no quita en absoluto que en los buenos momentos podamos disfrutarlo!