Automatización

Reduzca el Costo de Automatización de Pruebas con IA en 300 Veces: Adiós a los Modelos de Visión

| Guillermo Mateo

# Reduzca el Costo de Automatización de Pruebas con IA en 300 Veces: Adiós a los Modelos de Visión

Imagina que cada vez que ejecutas una prueba automatizada, escuchas el sonido de monedas cayendo. No es una metáfora. Es la realidad de muchos ingenieros de QA que, como yo, han confiado en modelos de visión para automatizar pruebas web. Pero todo cambió cuando descubrí que estaba pagando por algo que ya tenía gratis.

El problema: Una factura de API de 400 dólares al mes

Todo empezó con una factura mensual de 400 dólares en llamadas a la API de Qwen-VL, un modelo de visión multimodal. Estaba ejecutando una plataforma de automatización de pruebas con IA basada en Midscene.js y Qwen-VL. Cada paso de prueba significaba enviar una captura de pantalla completa a un modelo de lenguaje multimodal (LLM) y pagar aproximadamente $0.011 por paso.

Un caso de prueba de 50 pasos costaba unos $0.55. Si lo ejecutaba a diario, eran $16.50 al mes. Añadía algunos escenarios más, y de repente estaba gastando más en llamadas a la API que en café. Y lo peor es que la mayoría de esas capturas de pantalla contenían información que ya tenía de forma gratuita.

La revelación: El DOM ya tiene toda la información

Una tarde, mientras observaba una ejecución de prueba, me di cuenta de algo crucial. El modelo de visión analizaba una captura de pantalla de una página web y veía 45 elementos interactivos. Pero Playwright ya había extraído esos mismos 45 elementos como texto estructurado limpio. Estaba pagando para procesar píxeles cuando los datos ya estaban perfectamente organizados en el árbol DOM.

Aquí tienes lo que ve un modelo de visión en una página: una imagen con datos de píxeles, detalles de renderizado, colores, sombras... Y aquí lo que ve en el DOM: una lista ordenada de elementos como ``, ``, `Add new doctor`. La IA no necesita "ver" la página. Necesita entender la estructura y decidir qué hacer. Y el texto estructurado hace eso perfectamente.

La solución: deep-test, un framework de pruebas basado en texto

Construí deep-test, un framework de pruebas con IA puramente textual. La arquitectura es sorprendentemente simple: extraemos elementos interactivos del árbol DOM (sin capturas de pantalla, sin modelos de visión), luego DeepSeek V4 analiza la estructura y decide la próxima acción, ejecutamos la acción con Playwright, y repetimos hasta completar la tarea.

La comparación de costes es ridícula. Con Midscene.js + Qwen-VL-Plus, cada paso costaba $0.011; un test de 50 pasos costaba $0.55. Con browser-use + Claude, cada paso costaba $0.10; el mismo test costaba $5.00. Pero con deep-test + DeepSeek V4, cada paso cuesta $0.00004, y el test de 50 pasos cuesta solo $0.002. Es decir, entre 200 y 300 veces más barato.

Probé un flujo completo de gestión hospitalaria: inicio de sesión, navegación por menús, añadir un nuevo médico con 12 campos y verificar el resultado. 29 pasos en total. Resultado: 81,8 segundos y un coste total de aproximadamente $0.001. Para que te hagas una idea, eso es menos que el precio de un solo paso en el enfoque basado en visión.

Extensión a Android: Un enfoque híbrido inteligente

Pero la cosa se pone aún más interesante. Las aplicaciones Android no pueden darte un árbol DOM limpio como una página web. Así que añadí un enfoque híbrido: uso uiautomator2 para extraer el árbol de interfaz de usuario nativo (es texto, igual que el DOM), y uso ADB screencap + OCR solo cuando el árbol de UI no tiene suficiente información. El mismo motor de decisión DeepSeek V4, solo que con diferentes fuentes de entrada.

Esto significa que un solo agente de IA maneja tanto aplicaciones web como Android con la misma arquitectura. Y también resolví el notorio problema de entrada en WebView de aplicaciones híbridas, donde las vistas web dentro de la app ignoran los comandos de automatización estándar. La solución: usar `uiautomator2.send_keys()` en lugar de `set_text()`. Me llevó días descubrirlo, pero fue una línea de código para implementarlo.

Conclusión: Menos píxeles, más estructura

Los modelos de visión son excesivos para la mayoría de las pruebas web. Son geniales para pruebas de regresión visual (¿se rompió el diseño?), resolución de CAPTCHA o aplicaciones con mucho Canvas/SVG. Pero para operaciones CRUD estándar —rellenar formularios, hacer clic en botones, navegar por menús— el DOM ya tiene toda la información que necesitas.

La optimización real no está en mejores indicaciones o IA más inteligente. Está en elegir el formato de datos adecuado para el trabajo. Si estás gastando una fortuna en pruebas automatizadas con IA, quizás sea hora de preguntarte: ¿realmente necesitas que la IA vea la página, o solo necesita entenderla?

¿Quieres saber más?

Si te ha resonado esta historia y quieres explorar cómo aplicar estas técnicas en tus proyectos, no dudes en contactarme. Estoy abierto a compartir más detalles y ayudar a otros profesionales a reducir sus costes de automatización. Y si te interesa la automatización de procesos en general, visita [nuestras soluciones de automatización](https://guillermomateo.es/automatizacion-procesos) para descubrir cómo podemos ayudarte a optimizar tus flujos de trabajo.

Recuerda: en el mundo de la automatización con IA, a veces menos es más. Menos píxeles, más estructura, y un ahorro que se nota en la factura.

desarrolloprogramaciónautomatizacióndevopsautomatización de pruebasinteligencia artificialahorro de costes