Ingresa o regístrate acá para seguir este blog.

¿Así que quieres ser un Tester de Video juegos? O tal vez ya eres uno, pero quieres compartir tus experiencias con otros. Game Testing es una manera perfecta de entrar en la industria de los video juegos, y que «nos paguen para jugar juegos» es el sueño de muchos niños.

Esta es mi segunda publicación de #TestingTuesday, una continuación a Game Testing 101: Lo básico 

Un vistazo al pasado

Conclusiones del último Martes de Testing:

El Testing de videojuegos es atención metódica al detalle aplicada a encontrar errores e incoherencias en un juego.

Un video juego tiene muchas etapas de desarrollo, y el testing debe corresponder a la etapa del desarrollo en el que se hace. En la etapa Pre-Alpha la arquitectura básica es programa y generalmente no es necesario el testing orientado a la experiencia de usuario. En la etapa Alpha es común el testing orientado a experiencia de usuario en términos de mecánicas de juego y elementos básicos de juego. La fase Beta, en la que normalmente todas las características del juego ya están incluidas, es la etapa más intensa para los testers.

A pesar de que es cierto que cada video juego es distinto, darle un poco de estructura al testing maximiza los resultados independientemente del juego que se esté desarrollando, con este propósito, el testing se debe orientar hacia las siguientes categorías:

  • Jugabilidad y Mecánicas: Las reglas del juego.
  • Arte: Todos los componentes visuales del juego.
  • Interfaz: Todas las formas de comunicación en primer plano con el jugador.
  • Música y Efectos de Sonido: Todos los componentes relacionados con el audio.

    El artículo completo puede ser leído en este enlace.

Cómo Reportar

Existen muchos programas en los que los bugs pueden ser reportados y monitoreados, desde una hoja de Google hecha por uno mismo, hasta plataformas completas como Bugzilla o Mantis. La ventaja principal que he detectado al usar estas plataformas es que facilitan la comunicación con el resto del equipo enviando correos cuando un bug es asignado a ellos y cuando se hacen acciones específicas sobre ese bug.

Pero más importante que la herramienta que se usa para reportar es lo que se tiene que decir acerca de cada bug. A pesar de que los campos específicos a llenar varían dependiendo del estudio de video juegos que lo maneje o del proyecto en el que se trabaje, hay algunos campos que deben mantenerse constantes en nuestros reportes de manera que el equipo a quien el reporte está dirigido reciba la mayor cantidad de información posible, en el menor tiempo de lectura.

A manera de ejemplo, reportemos un crash en el menú de pausa del nivel 3 de un juego imaginario. Un crash significa que el juego se queda congelado o se cierra sin que cerrarlo sea la intención del jugador, de manera que se detiene la experiencia normal. Los campos que recomiendo reportar son:

  • Resumen: esta parte corresponde al titular de una noticia, es necesario dar la mayor cantidad de información posible en pocas palabras. Es distinto decir «Hubo un partido de Fútbol anoche» que decir «Colombia le ganó a Brasil 4 a 0 anoche» (Era gol de Yepes). En nuestro ejemplo, deberíamos reportar: «El juego se detuvo en el menú de pausa en el nivel 3 usando Internet Explorer».
  • Descripción: Es una descripción de un párrafo del bug. Solamente se debe describir qué está ocurriendo. Para nuestro bug imaginario: Al intentar jugar el nivel 3 en Internet Explorer 11.0.1 en Windows 8.1 el juego se detuvo al darle a pausa apróximadamente en la mitad del nivel. No sucede más nada, el explorador no se cierra abrúptamente.
  • Pasos para Reproducir: Una pequeña guía paso a paso en la que se especifica cómo reproducir el bug. Debemos ser cuidadosos con escribir pasos obvios, no queremos ser muy descuidados ni muy obvios.Si el programador necesita entrar en el menú de Pausa del nivel 3 y presionar 2 botones simultáneamente en el control para que el bug sucede, debemos hacer más hincapié en los pasos que corresponden a las acciones específicas dentro del menú de Pausa:
    • Paso 1: Abrir el juego normalmente.
    • Paso 2: Jugar normalmente hasta alcanzar el nivel 3.
    • Paso 3: Cuando se estime que se está alrededor de la mitad del nivel 3, presionar Pausa para pausar el juego.
    • Paso 4: Presionar los botones X y A al mismo tiempo y observar. El juego se congela.
  • Información Adicional: Cualquier información adicional debe ser comentada en este punto. Exploradores, controles, personajes específicos que se deben escoger para reproducir el bug, etc. Para nuestro bug en el que el juego se congela, podríamos escribir: Ver referencias (2 imágenes adjuntas correspondientes a los estados que ocurren antes y después de que el juego se congela). Sucede en Xbox One y PS4 con sus respectivos controles.
  • Comportamiento Esperado: Cuando se detecta un bug es porque hay algo que no se está comportando cómo debería, y si el tester detecta el error es porque ha, concientemente o no, comparado el juego con una versión mejorada del mismo juego que existe en su mente. Este campo debe ser llenado con el comportamiento de este juego que existe en la cabeza del tester. En nuestro error de ejemplo, este campo se podría llenar de la siguiente manera: «El juego no debe congerlarse en el menú de Pausa bajo ninguna combinación de botones, en ningún nivel».
  • Plataforma: Este campo debe ser llenado con la información acerca de las plataformas en las que sucede el bug, versiones del explorador, sistemas operativos, consolas, dispositivos, exploradores en dispositivos móviles, controles, marcas específicas de controles y dispositivos, etc.
  • Asignado: El nombre del miembro del equipo cuya responsabilidad directa es resolver este error en el momento de ser reportado. por ejemplo, si es un error relacionado con arte, el asignado inmediato es el artista del proyecto, sin embargo cuando el artista haya hecho su trabajo, el asignado debe cambiar del artista al programador cuya responsabilidad directa es integrar el arte realizada por dicho artista.
  • ID: Un número identificador único.
  • Archivos Adjuntos: Todas las imágenes, los videos, capturas de pantalla, sonidos, o cualquier archivo relacionado al bug que apoye al reporte, debe ser previamente citado en el campo de información adicional y tener un nombre lógico.
  • Frecuencia: Referida a la reproducibilidad del bug, un crash puede ocurrir todas las veces, algunas veces, el 50% de las veces, una sola vez, el tester puede no saber. En cualquier caso, en este campo se debe indicar la frecuencia con la que el bug es encontrado, para juegos pequeños, está bien probar unas 10 veces para entender los porcentajes de reproducibilidad, para juegos más grandes, se recomienda que sean 100 veces.
  • Severidad: Este campo se refiere a la importancia del bug para el usuario final, por ejemplo un crash que sucede el 50% de las veces tiene severidad alta, pero un botón ligeramente pixelado tiene una severidad baja.
  • Prioridad: La prioridad representa la importancia inmediata para el arreglo del bug dentro de la realidad de producción en cada momento, es importante no confundirlo con la severidad, un error gramatical tiene una alta severidad siempre, pero no tiene generalmente una prioridad alta en las etapas pre-Alpha y Alpha, en las que los textos finales están por definirse y la funcionalidad del juego se está implementando.

Métodos de Pruebas

Ahora que sabemos qué debemos probar y cómo lo debemos reportar, es hora de aprender un poco acerca de cómo se debe probar. Un testing limpio generará más resultados en menos tiempos. Es muy fácil perder visibilidad de los bugs en juegos grandes, o cuando se prueba horas seguidas, y una sola persona puede ver errores hasta su limite. Los siguientes métodos pueden servir como guías para probar cada una de las categorías.

Prueba de Humo

Es la primera prueba que se debe hacer y es la primera prueba que se hace normalmente, Las pruebas de humo están, en muchos casos, automatizadas, pero pruebas de humo manuales siempre son necesarias.

Cuando se hace una prueba de humo, el tester necesita verificar que el juego no se esté congelando, el flujo de las pantallas sea correcto y que la velocidad del juego sea adecuada, y es por esto que debe suceder de primero, así sea una corrida rápida del juego. Si las pruebas de humo no se ejecutan correctamente el tester podría encontrarse, por ejemplo, un juego que se detiene o hace crash en el nivel 1, bloqueando las pruebas en el resto del juego.

Aún si se ha probado el juego 100 veces y está casi listo para ser entregado, siempre se deben hacer pruebas de humo para asegurarse de que esté corriendo como debería estar.

Pruebas de Remojo

La prueba de remojo es muy simple de ejecutar y puede detectar problemas en persistencia de datos y goteras de memoria. Para hacer una prueba de remojo, se debe dejar el juego corriendo en un dispositivo específico por largos períodos de tiempo en una pantalla crítica, por ejemplo, dejarlo en la pantalla de pausa por unas 8 horas, y regresar para observar el comportamiento del juego. Se debe observar si el juego está lento, si el nivel continua donde se pausó, con la misma cantidad de monedas, vidas, municiones, si los enemigos están apareciendo correctamente, y en fin, todo lo que suponga estados de persistencia de datos en el juego que se prueba.

Específicamente, si la velocidad del juego ha sido afectada, es una señal de que existe una gotera de memoria, una gotera en memoria significa que algunos datos basura no se están destruyendo correctamente y están siendo almacenados constantemente en el dispositivo, mientras más tiempo se deje el juego corriendo, más cantidad de datos basura se guardan en el dispositivo.

Jugar Bien

Jugar bien significa jugar el juego tal cual los desarrolladores lo pensaron y ejecutaron, si el juego es un juego de plataforma que debe de jugarse de izquierda a derecha, entonces lo jugamos de izquierda a derecha, si el jugador debe presionar solamente un botón a la vez, entonces el tester presiona solamente un botón a la vez.

Jugar Mal

Al jugar mal, el tester juega el juego completamente opuesto a cómo debería, si fue diseñado para que el personaje se moviera de izquierda a derecha, el tester debe moverlo de derecha a izquierda, o presionar todos los botones al tiempo, tratar de atravesar paredes o saltar 100 veces seguidas. Se trata de romper todos los esquemas de diseño en búsqueda de errores.

A veces me gusta pensar que soy un niño pequeño jugando con los controles para jugar los juegos mal, esto me ha dado resultados muy buenos, me ha sido útil para conseguir bugs comunes que se reproducirían en gameplay, en eventos muy específicos.

En el siguiente #Martes de #Testing

Ahora que sabemos cómo reportar y que probar, es hora de profundizar en cada una de las categorías.

En el próximo #Martes de #Testing hablaremos del significado de jugabilidad, qué significa jugabilidad y cómo se relaciona con la psicología del jugador.

http://the9bitgame.blogspot.com/

Compartir post

Etiquetas