QA automático con IA: cómo probamos cada pantalla antes de publicar
Capturas en diez formas de pantalla, texto que se mide al píxel, partidas sin internet y una prueba de memoria. Y el límite: lo que solo encuentra una persona con su teléfono.
En el estudio de juegos de Kynora Labs, una sola persona dirige a siete agentes de IA. Uno de ellos es el de QA, y su trabajo es el menos vistoso y el que más nos ahorra: comprobar que lo que se va a publicar funciona y se ve bien, en cualquier pantalla, antes de que lo vea un jugador.
Esta nota cuenta cómo está armado ese control, qué revisa, qué no puede revisar y por qué la idea central sirve para cualquier empresa que entregue algo a clientes, sea un juego, una web, un catálogo o un formulario.
El punto de partida: compilar no es funcionar
Un juego puede pasar todas las pruebas de lógica y verse roto. Un botón tapado por otro, un texto cortado, una franja vacía al costado de la pantalla. Nada de eso lo detecta una prueba que solo mira si los cálculos dan bien.
Por eso, en las reglas del estudio, la definición de "terminado" tiene tres partes: que compile y pasen las pruebas, que el comando de QA genere sus capturas y que alguien las haya mirado, y que los números nuevos estén en el archivo de configuración. Sin la segunda, una tarea no está cerrada aunque el agente diga que sí.
Capturas automáticas en muchas pantallas
El comando de QA abre el juego en el Chrome instalado en la computadora, controlado por una herramienta de automatización (playwright-core). No lo abre una vez: lo abre muchas, con tamaños y condiciones distintas, y en cada una lo recorre solo y saca capturas en los momentos clave.
Las pasadas principales:
| Pasada | Pantalla | Qué recorre |
|---|---|---|
| Celular | 390×844, táctil | Inicio, campaña, partida, un arrastre real con el dedo, pista, victoria |
| Celular chico | 360×640 | Inicio, partida, resultado |
| Escritorio | 1280×720, con mouse | Inicio, partida, arrastre con el mouse, resultado |
| Inglés | 390×844 | Las mismas pantallas en el otro idioma |
| Jugador nuevo | 390×844 y 1280×720 | La primera partida guiada, sin ayuda externa |
| Encuadre | Diez formas, de 360×640 a 1720×720 | Inicio y el tablero más grande |
Para que una prueba pueda "jugar", el juego expone en modo depuración un panel de control con su estado y algunas acciones: ir al nivel 30, saber cuál es la jugada correcta, terminar el tutorial. Así la prueba llega a un caso borde en segundos, sin jugar media hora.
Los toques son toques de verdad. En las pasadas de celular, la prueba arrastra fichas con eventos táctiles reales, no simulando un mouse, porque hay errores que solo aparecen con el dedo.
Y cualquier error en la consola del navegador hace fallar la corrida entera. No hay errores "aceptables".
Lo que se mide, no se opina
Una captura sirve si alguien la mira. Pero hay cosas que una persona, o un agente que lee imágenes, ve mal o se cansa de mirar. Esas las convertimos en mediciones.
Texto demasiado chico. La regla del estudio es que ningún texto de la interfaz mida menos de 10 píxeles en pantalla, también en un iPhone acostado. La prueba recorre cada texto visible fuera del tablero, calcula su tamaño real e imprime el más chico de cada pantalla. Si alguno queda por debajo, falla y dice cuál.
Que el juego llene el cuadro. En monitores anchos, un juego vertical tiende a dejar franjas de color plano a los costados. La prueba saca capturas en diez formas de pantalla y cuenta, píxel por píxel, cuántas filas y columnas de cada borde son de un solo color. Tolera hasta 2. Además, otra prueba verifica que la proporción del escenario coincida con la del cuadro.
Guardado. La prueba hace una jugada, termina el turno, recarga la página y verifica que aparezca "Continuar" con exactamente la misma partida. También cuenta cuántas veces se escribe el guardado en una partida entera: la regla es guardar en el cambio de turno, no en cada movimiento, y si alguien la rompe, el número lo muestra.
Sin conexión. Una pasada corta la red en medio de la sesión. El juego tiene que darse cuenta, esconder todo lo que depende de internet y dejar jugar una partida completa hasta el resultado. Otra pasada recarga el juego instalado sin conexión y verifica que arranque y se pueda jugar.
Pérdidas de memoria. Esta merece contarse aparte.
La prueba que no existía
Tile Clash, uno de nuestros juegos publicados, tenía, según el tablero de calidad de la plataforma donde está publicado, un 2,77% de partidas que se rompían jugando: una de cada 36. Nuestro QA daba cero errores.
La causa era que, cada vez que cambiaba el alto de la pantalla, el juego redibujaba el tablero sin destruir el anterior. En una ventana de prueba de tamaño fijo eso no pasa nunca. En un celular pasa todo el tiempo: la barra de direcciones aparece y desaparece, se abre el teclado, alguien gira el teléfono. Medido después en Chrome, 20 cambios de alto llevaban las texturas en memoria de 88 a 826, y 300 cambios, a casi 97 MB de imágenes que nadie veía. Cuando un teléfono modesto se queda sin memoria gráfica, la pantalla queda en blanco: para el jugador, el juego murió.
Se arregló, y la tasa de caídas bajó a 0,71%. Pero lo valioso fue lo que quedó: una pasada nueva que cambia el alto de la pantalla 20 veces con una partida abierta y falla si al terminar quedan texturas u objetos interactivos de más. Con el error reintroducido a propósito, la prueba lo detecta con los mismos números. Además, el juego ahora registra sus propias caídas con contexto (en qué pantalla, cuántos minutos de juego, cuántos objetos vivos), para no depender solo de un porcentaje sin causa.
Pruebas que no mienten
Una regla que nos costó cara: nunca una verificación detrás de una espera fija. Una prueba esperaba 160 milisegundos entre dos toques; con la computadora cargada no alcanzaba, el primer toque se perdía y la falla aparecía tres pasos después, apuntando a otra cosa. Hoy las pruebas esperan a que el estado cambie, no al reloj. Y antes de cambiar el juego por una prueba roja, primero se comprueba si el problema es el juego o la prueba.
El límite: lo que solo ve una persona con su teléfono
Todo lo anterior corre en una computadora. Y hay cosas que una computadora no reproduce.
El director del estudio prueba cada juego publicado en su iPhone, instalado en la pantalla de inicio, como lo usaría cualquiera. Así apareció un problema que ningún QA había marcado: con el interruptor de silencio del iPhone activado, Safari silencia el audio del juego por completo. En la computadora el sonido andaba perfecto; las pruebas medían el volumen y daban bien. En el teléfono, con el interruptor como lo tiene mucha gente, no se oía nada. La solución fue declarar que la página reproduce contenido multimedia (lo mismo que hace un video), y ahora va incluida en los juegos nuevos desde el primer día.
No es el único caso. El gusto tampoco se automatiza: la primera música de fondo de un juego pasaba todas las pruebas y el director la escuchó y dijo que parecía un motor cambiando de nota. Tenía razón.
Por eso la lista de publicación tiene una sección que se llama "filas que decide una persona": Safari y un celular real, si el contenido es apropiado y si el juego se entiende sin explicación. Ningún script las firma.
Cada queja, una verificación automática
El mecanismo de fondo es simple: cada vez que algo falla afuera, se agrega una prueba adentro. Si un texto resulta ilegible en un iPhone acostado, se suma la medición de tamaño en esa pantalla. Si la plataforma muestra caídas, aparece la prueba de memoria. Si alguien pide guardar con menos frecuencia, aparece el contador de escrituras. La corrección se hace una vez; la verificación corre siempre.
Cualquier empresa puede aplicar esto sin hacer juegos:
- Anotá cada queja con fecha y textual, venga de un cliente, de un empleado o de una auditoría.
- Preguntate si se puede medir. "La web se ve mal en el celular" se traduce en "ningún texto menor a cierto tamaño en una pantalla de 390 de ancho".
- Automatizá la medición y hacé que corra antes de cada cambio. Hoy un agente de IA puede escribir esa prueba en una tarde.
- Que la prueba falle con un mensaje que explique la causa, no solo un "error".
- Reservá para personas lo que no se mide: el gusto, el dispositivo real, el criterio de negocio.
- Mirá los datos de afuera. Las pruebas internas dicen si hiciste lo que pensabas; los números reales dicen si era lo correcto. Lo contamos con más detalle en lo que aprendimos publicando juegos en CrazyGames.
Si querés medir así un proceso de tu empresa que ya usa IA, la guía cómo medir si la IA está funcionando en tu empresa baja estas ideas a indicadores concretos.