QA Tester

Hace mucho que por aquello del trabajo a jornada completa, otros proyectos y la vida de la gran ciudad no saco tiempo para hablar de alguna cosilla en el Blog, y hoy me he decidido a hablar de mi nuevo… (bueno, de hace 6 meses) trabajo de QA Tester en una empresa donde probamos aplicaciones que… bueno, no son videojuegos, pero estoy aprendiendo cosas que me pueden ser útiles y, por supuesto, sigo aplicando en la parte del desarrollo y colaboraciones.

¿Cómo funciona?

Herramientas de tester, lo que se dice herramientas en si no estamos usando, ya que para testear se hace en la propia aplicación, juego o lo que sea, pero necesitas documentar, documentarte y comunicarte con los desarrolladores, y para eso si hay herramientas.

En mi empresa usamos software para colgar pantallazos en informes de los fallos que vemos. Los desarrolladores los van corrigiendo dependiendo de si son más o menos graves (los más graves se arreglan primero) y luego cuando suben una nueva versión con los fallos corregidos, volvemos a probar para verificar que ya no sigue ocurriendo el mismo problema.

Para documentar tiramos del clásico paquete de ofimática y también capturas de pantalla y videos. También tablas para traducciones. con un dialogo, o texto de menú o lo que sea para tener a mano y que todos los tester puedan comprobar con esos datos que la traducción está ok en el juego.

Usamos tablas también para generar pruebas, describiendo los pasos a seguir, con qué tipo de usuario, donde hay que pulsar y con qué datos. En el caso de videojuegos no sé si eso será aplicable y si lo es, tal vez solo vale para menús y cosas que siempre se hagan igual.

Para documentarnos tenemos otro software. Ahí tenemos documentos funcionales (de cómo debe funcionar nuestra aplicación) y de diseño (que en videojuegos seguramente también existan). En los de diseño tienes imágenes y descripciones de cómo debe ser la pantalla que hay que comprobar. Si el botón tiene que ser verde y volverse gris si está desactivado, por ejemplo, si está centrado, si el texto debe está en negrita... Así, si ves algo raro puedes comprobar que el diseño esta correcto o no. Como todo eso está en la nube, se supone que los desarrolladores actualizan y así nunca dudas de si tus pruebas están bien o te has dado cuenta de un cambio de color pero luego te enteras de que ha sido una decisión de diseño y nadie te ha comunicado nada.

Por fin tenemos herramientas para casos de prueba. Y es que hay pruebas diseñadas para cubrir todo el software. Por ejemplo, si hablásemos de juegos te podrían decir que te dediques a chocarte con todas las paredes para comprobar que las colisiones están funcionando o te vas a acabar cayendo por el escenario. Así, después de echar la tarde probando eso, te irías a la herramienta en cuestión y marcarías que has hecho esa prueba y está superada o que no, y entonces abres un reporte de un bug indicando por ejemplo que has atravesado cierta pared en un punto concreto. Así los desarrolladores pueden reproducir el fallo, ver por qué pasa y corregirlo.

Y pasando por encima la idea es esta. Diseño de pruebas, documentación y pruebas en sí mismas. Lo que pruebas y fallas se corrige y vuelves a probar que ya no pasa. Así poco a poco se van solucionando los bugs y vigilándolos para que no vuelvan a aparecer en versiones posteriores. (Porque a veces arreglan una cosa y rompen cien que ya se corrigieron en tiempo atrás).

En el tiempo libre que me queda y cuando no estoy demasiado cansado o tengo otras cosas, estoy de nuevo colaborando con el Testeo del juego Pangea, para el que aplico en lo posible esta metodología. Así, poco a poco el creador avanza en su desarrollo y corrige todos los errores posibles, para que el día del lanzamiento todo funcione como debe y nadie se quede sin poder avanzar en la historia remasterizada y revisada del viejo buscador de antigüedades, Frank Frantic.