La ejecución de QA impulsada por IA en una herramienta de diseño basada en la web informó: “Todas las funciones funcionan, aprobado”, pero el lienzo no mostraba nada. El falso aprobado no fue un error en el razonamiento del modelo; fue un efecto secundario de cómo el navegador gestiona las pestañas ocultas y de cómo el script de prueba medía la “salud” en lugar de la salida visual.

Por qué los agentes de QA con IA pueden pasar por alto un lienzo en blanco

Ejecutan JavaScript, capturan capturas de pantalla y permiten que el modelo infiera si una función se comportó correctamente. En la práctica, dos puntos ciegos técnicos producen aprobados repetidamente cuando la interfaz de usuario (UI) está realmente vacía.

Explicación del estrangulamiento (throttling) de pestañas ocultas

Chrome MCP a menudo ejecuta pruebas en pestañas en segundo plano para mantener la ventana principal libre para otros trabajos. Cuando el document.visibilityState de una pestaña está en estado hidden (oculto), el navegador limita el flujo de renderizado (rendering pipeline):

  • JavaScript sigue ejecutándose, por lo que no aparecen errores de tiempo de ejecución.
  • Los callbacks de requestAnimationFrame dejan de ejecutarse, dejando el recuento de fotogramas de animación en cero.
  • Los temporizadores se activan con mucha menos frecuencia; una prueba que esperaba intervalos de 33 ms solo observó cuatro.

El agente de IA ve resultados de JS limpios y una captura de pantalla, y asume que la animación funcionó. Debido a que el bucle de renderizado nunca produjo píxeles, el defecto visual permanece oculto.

Soluciones para problemas de pestañas ocultas

  • Mantenga la pestaña de prueba visible para cualquier verificación de lienzo, animación o gráficos.
  • Active las interacciones solo después de que la pestaña esté en primer plano.
  • Inserte una breve espera (unos pocos segundos) antes de capturar la captura de pantalla, asegurándose de que el búfer de fotogramas se haya completado.
  • Si debe utilizarse una pestaña oculta, anteponga al informe un descargo de responsabilidad como “renderizado no observado visualmente”.

Salud del código frente al comportamiento de las funciones

La mayoría de los scripts de QA con IA evalúan la “salud del código”: confirman que los manejadores de clics (click handlers) están conectados, que no se lanzaron excepciones de JavaScript y que se cargaron las librerías necesarias. Esas señales demuestran que el código se ejecutó, no que la UI cambió según lo previsto. Un elemento canvas puede crearse, una rutina de dibujo puede llamarse y, aun así, no renderizar nada si los comandos de dibujo se dirigen a un búfer de tamaño cero o a un recurso vacío.

La distinción es importante porque una ruta de código saludable puede enmascarar la ausencia de un artefacto visual.

Añadir comprobaciones de comportamiento

  1. Identificar elementos dinámicos – Escanee el código fuente en busca de etiquetas canvas, campos file-input, botones de descarga y bucles de animación.
  2. Definir resultados observables – Para un canvas, requiera una comprobación a nivel de píxel de que el mapa de bits no esté vacío. Para un input de archivo, verifique que aparezca una imagen de vista previa. Para una descarga, confirme que se cree un archivo en el sistema de archivos. Para las animaciones, asegure que una propiedad rastreada cambie con el tiempo.
  3. Informar la cobertura – Adjunte una tabla a la salida de QA que enumere cada función, el estado de salud del código y el resultado de la verificación del comportamiento. Cualquier cosa que carezca de una comprobación de comportamiento permanecerá como “no verificado” en lugar de “aprobado”.

Aplicar esta regla redujo drásticamente los falsos positivos en la suite de pruebas del autor y también expuso discrepancias de CSS donde la hoja de estilos declaraba un color pero el píxel renderizado era diferente.

Pasos prácticos para pruebas visuales fiables

  • Ejecute las pruebas en una pestaña visible siempre que la función implique renderizado.
  • Espere a que la UI se estabilice; un retraso fijo de unos pocos segundos suele ser suficiente, pero un enfoque más robusto es realizar consultas (polling) para detectar un canvas que no esté en blanco usando getImageData.
  • Separe las aserciones de salud del código de las aserciones visuales en el script de prueba; permita que el modelo de IA evalúe cada una de forma independiente.
  • Registre el estado de visibilidad y los contadores de fotogramas (llamadas a requestAnimationFrame) como parte de la salida de diagnóstico.
  • Documente cualquier ejecución inevitable en pestañas ocultas con advertencias explícitas para que los revisores posteriores comprendan la limitación.

Qué observar a continuación

A medida que proliferan las herramientas de QA asistidas por IA, los desarrolladores deben tratarlas como asistentes, no como árbitros. Las métricas de salud del código siempre serán un sustituto incompleto del comportamiento orientado al usuario. La conclusión es sencilla: un modelo de IA solo puede informar de lo que ve. Si el navegador nunca pinta porque la pestaña está oculta, o si el script de prueba nunca pregunta “¿apareció algo en la pantalla?”, el modelo declarará el éxito con gusto. Añadir un requisito de visibilidad y un paso de verificación de comportamiento convierte un aprobado superficial en un resultado fiable.