La automatización del navegador ha pasado por tres generaciones. Cada una resolvió el cuello de botella de la anterior y desplazó el siguiente a otro punto. Entender qué problemas deja abiertos cada etapa es más útil que memorizar nombres de herramientas.
La automatización del navegador existe desde hace más de veinte años y ha cambiado de rumbo tres veces. Lo interesante es que cada generación resuelve una clase distinta de problemas y, cuando lo consigue, el cuello de botella vuelve a desplazarse a otro lugar.
Primera generación: fingir a nivel del sistema operativo que alguien mueve el ratón
La automatización más antigua ni siquiera se hacía dentro del navegador, sino en el sistema operativo. El script movía el ratón y pulsaba teclas, mientras el navegador se limitaba a recibir esas entradas.
La ventaja era su carácter general: podía tocar cualquier cosa visible en la pantalla, ya fuera una página web, una aplicación cliente o software de escritorio antiguo, sin que el navegador tuviera que ofrecer ninguna interfaz. El coste también era muy directo. El script reconocía coordenadas de pantalla, de modo que un cambio de resolución, un ajuste de escala del sistema o un desplazamiento de la ventana bastaban para que la misma acción hiciera clic en el lugar equivocado. Tampoco sabía si la página había terminado de cargar y tenía que apoyarse en esperas fijas. El paralelismo era aún más problemático: una máquina solo tiene un ratón y un teclado, así que diez entornos exigían diez máquinas.
El problema que dejó esta generación era, en pocas palabras, que no podía ver la página.
Segunda generación: evitar la pantalla y hablar directamente con el navegador
La aparición de WebDriver elevó la automatización del nivel de píxeles al nivel de elementos: se buscaba un elemento concreto de la página en vez de la posición correspondiente al píxel 800 de la pantalla. El mismo código podía controlar distintos navegadores y escribirse en diferentes lenguajes, una de las razones por las que terminó convirtiéndose en un estándar en pruebas.
Más adelante, las soluciones basadas en protocolos de depuración del navegador llevaron este enfoque mucho más lejos. La familia de Puppeteer y Playwright se comunica directamente con el motor y puede obtener el estado interno de la página: esperar automáticamente a que los elementos estén listos, interceptar y reescribir solicitudes, conectarse a una instancia del navegador ya abierta, ejecutarse sin interfaz y abrir varios contextos en paralelo. Gran parte de las capacidades que hoy se dan por sentadas se completaron en esta etapa.
Esto resolvió el control y la estabilidad, pero dejó otros dos problemas. El primero es que los scripts seguían estando fijados por personas. Cuando cambiaba la estructura de una página o dejaba de funcionar un selector, había que volver al código, y el coste de mantenimiento crecía con el tamaño del proyecto. El segundo es más fundamental: esta generación controla cómo operar, no cómo parece el actor. La conexión directa por protocolo hace el control más preciso, pero las huellas de la automatización no desaparecen por cambiar el medio de comunicación. Incluso un script muy estable puede seguir pareciendo un script para otros.
Tercera generación: ya no se escriben todos los pasos y el problema vuelve a cambiar de sitio
El cambio de la tercera generación no está en la forma de controlar, sino en la forma de decidir. Las dos primeras exigían escribir cada paso con claridad: qué botón pulsar, qué campo rellenar y en qué orden. En la generación guiada por modelos, se proporciona un objetivo, el modelo planifica la ruta y puede volver a encontrar una entrada cuando cambia el diseño de la página.
Así, problemas antes minuciosos como cómo escribir un selector o cuánto esperar van perdiendo importancia. Sin embargo, aparecen enseguida dificultades nuevas.
La clave es que el modelo no accede por sí mismo a la página web. Quien abre la página, carga los recursos y mantiene la sesión sigue siendo el navegador. Por eso, cuando una tarea empieza a ser inestable, la causa suele estar menos en una decisión equivocada del modelo que en el entorno de ejecución que tiene debajo: varias tareas comparten un navegador y contaminan entre sí cookies y caché; las características de huella son muy parecidas y la plataforma interpreta que todas esas tareas proceden de la misma máquina; las cuentas se mezclan entre tareas y una anomalía afecta a muchas; los entornos tienen que crearse de forma temporal y recuperarse al terminar, pero no existe una programación unificada. El modelo resuelve cómo hacer el trabajo y convierte dónde hacerlo en el nuevo cuello de botella.
La capa adicional de la arquitectura
Si se observan juntas las tres generaciones, la diferencia no consiste en decidir cuál es más avanzada, sino en que cada una debe hacerse cargo de lo que la anterior no resolvió. En las dos primeras, el entorno no era un problema porque se utilizaba el navegador de la propia máquina. En la etapa de los Agents, las tareas son masivas, concurrentes y desatendidas, por lo que el entorno debe gestionarse de forma explícita: cada tarea se ejecuta en un entorno independiente, sin mezclar huellas ni sesiones; el estado de inicio de sesión se conserva entre tareas para no tener que autenticarse cada vez; IP, zona horaria e idioma se combinan de forma coherente; y los entornos se crean y recuperan bajo demanda como recursos informáticos.
PurpleMark trabaja precisamente en esta capa: convierte los entornos del navegador en recursos que pueden programarse, para que el Agent se concentre en la lógica de la tarea.
Así también resulta más fácil encuadrar la elección. Las pilas de pruebas empresariales y los scripts existentes pueden seguir en su ruta actual; las aplicaciones web complejas que necesitan control a nivel de solicitudes encajan en la generación guiada por protocolo; y para tareas planificadas por un modelo que además deben ejecutarse de forma estable a largo plazo, las tecnologías de las dos primeras generaciones siguen siendo válidas, pero la capa del entorno debe resolverse por separado. Si el escenario exige que la operación parezca realizada por un usuario real, eso no es algo que un framework de automatización pueda aportar por sí solo, sea cual sea la generación.
Fuera de la ruta técnica hay otro límite: la automatización debe cumplir las reglas de la plataforma de destino y las leyes locales. Que algo sea técnicamente viable no significa que sea adecuado para el negocio.
