Alternativas a Selenium: qué cambia en la práctica

Los equipos que buscan una alternativa a Selenium suelen necesitar algo más que una lista de nombres. Necesitan saber qué cambiará en su suite actual: cómo se crea una sesión del navegador, quién administra el binario, cómo espera una acción y qué evidencia queda cuando falla una prueba. Esos contratos difieren aunque dos herramientas puedan pulsar el mismo botón. BotBrowser admite rutas de automatización documentadas, pero no traduce suites ni elige un framework. La respuesta práctica es migrar una prueba representativa y mapear esas cuatro superficies antes de estimar el resto.

Para elegir el protocolo dentro del mismo framework, compara la compatibilidad de operaciones de WebDriver, BiDi y CDP; el nombre de la biblioteca no determina qué conexión expone el comando o evento necesario.

TL;DR

• Selenium WebDriver usa un protocolo estandarizado de control remoto y suele enviar comandos mediante un driver o Selenium Grid. Otros frameworks pueden usar otro protocolo cliente-servidor o conectarse a una interfaz de depuración del navegador.
• La instalación y la propiedad del proceso del navegador cambian con el framework. Selenium Manager puede administrar drivers y navegadores; Playwright administra sus binarios compatibles; la ejecución remota introduce otro responsable en ambos casos.
• Playwright espera condiciones de accionabilidad documentadas antes de muchas acciones sobre locators. Las pruebas Selenium suelen expresar la sincronización con esperas explícitas y condiciones esperadas. Ninguno de los modelos elimina la necesidad de entender el estado de la aplicación.
• La intención de la prueba, los datos y las aserciones de negocio suelen poder conservarse. La configuración de sesión, los selectores, las esperas, los fixtures, la cobertura de navegadores y los artefactos de fallo requieren una correspondencia explícita.

Contenido

• Protocolo y propiedad de la sesión
• Ciclo del navegador y del driver
• Semántica de esperas y condiciones de interacción
• Evidencia para depurar
• Qué suele conservarse
• Una hoja de migración
• Evalúa una prueba antes de la suite
• Conclusión práctica

Protocolo y propiedad de la sesión

Una alternativa no sustituye a Selenium directamente solo porque ofrezca click(), navegación y selección del navegador. La diferencia importante es el contrato que hay detrás: qué proceso posee el navegador, qué protocolo transporta un comando, qué estado puede inspeccionar el cliente y cómo determina la prueba que un elemento está listo. Esas diferencias determinan qué hay que reescribir y qué puede seguir en la suite.

Conviene poner en contexto la consulta. “Alternativa a Selenium” puede significar que un equipo quiere otro binding de lenguaje, una configuración local más sencilla, una matriz nueva de navegadores o un flujo de depuración distinto. Las variantes de autocomplete incluyen Python, Playwright, web scraping, código abierto y Java. No identifican un motivo universal para cambiar. Un plan debe empezar por la limitación que falla hoy, no por suponer que un framework popular encaja mejor. La comparación útil es un inventario de migración: dependencia actual, contrato de reemplazo, código que cambia y evidencia del mismo resultado.

BotBrowser permite usar rutas de automatización documentadas, pero no sustituye la migración del código de pruebas ni elige un framework.

Selenium WebDriver está definido por el estándar W3C WebDriver. Un cliente WebDriver envía comandos a un extremo remoto que controla una sesión del navegador. En una configuración local, el driver suele ofrecer ese puente; en una distribuida, Selenium Grid dirige las sesiones a nodos remotos. Esta separación resulta útil cuando se necesita un protocolo común entre navegadores compatibles y se quiere mantener la ejecución lejos del proceso de pruebas.

Playwright distingue la conexión a su servidor del navegador de una conexión CDP a Chromium; su referencia CDP indica que esta última tiene menor fidelidad que la conexión con el protocolo Playwright. Puppeteer documenta tanto CDP como WebDriver BiDi. La documentación BiDi de Selenium describe una conexión WebSocket para eventos bidireccionales del navegador, además del modelo de comandos WebDriver. Estos protocolos y endpoints no son simples sustituciones de URL. Para migrar, registra navegador, cliente, método de conexión, versión y operaciones necesarias; después confirma la cobertura antes de cambiar la sesión.

Anota la propiedad de la sesión antes de cambiar código. ¿El proceso de pruebas inicia el navegador? ¿Lo inicia un Grid remoto, un servicio de navegador o un proceso persistente? ¿Qué componente crea contextos o sesiones y cuál los cierra tras un fallo? Una migración que cambia el framework pero conserva una suposición antigua sobre sesiones remotas puede fallar antes de ejecutar el primer locator.

Suposición actual de Selenium	Pregunta de migración	Evidencia que recopilar
Un driver local o Grid crea una sesión WebDriver	¿Qué proceso inicia el navegador en el framework de destino?	Comando de inicio, endpoint, ID de sesión y responsable del cierre
Las capabilities configuran una sesión remota	¿Qué opciones de destino corresponden a inicio, contexto o conexión?	Nombres de opciones aceptados y navegador/versión efectivos
Los comandos siguen la semántica WebDriver	¿El destino usa WebDriver, CDP o un canal propio?	Documentación del protocolo y método de conexión exacto

Ciclo del navegador y del driver

Sustituir Selenium cambia más que una importación. Una configuración local puede depender de Selenium Manager para localizar, descargar y guardar en caché un driver o navegador compatible. Selenium Grid puede aprovisionar el navegador en un nodo remoto. Playwright instala versiones de navegador para sus canales compatibles y las inicia desde su runtime. Una conexión remota de Playwright traslada la propiedad del proceso al servicio remoto. Puppeteer también necesita un ejecutable compatible o un endpoint remoto configurado explícitamente.

Estas opciones desplazan la responsabilidad de mantenimiento; no la eliminan. Antes de migrar, registra de dónde sale el binario, cómo se fija la versión, cuándo se actualiza, cómo lo encuentra el runner y qué proceso limpia tras un timeout. Mantén la versión del navegador separada de la versión del paquete de automatización. Actualizar el framework y actualizar el navegador son cambios distintos aunque un instalador los acople por defecto.

La matriz de navegadores también puede cambiar. El protocolo Selenium busca interoperabilidad entre implementaciones, mientras que las funciones de cada framework pueden variar por motor o modo de conexión. Un endpoint CDP de Chromium no demuestra que el mismo flujo tenga soporte equivalente en Firefox o WebKit. Si la cobertura entre navegadores es un requisito, enumera motores, versiones y funciones exactas de la suite actual y verifica cada ruta de destino en su documentación oficial.

Punto del ciclo	Registra antes de migrar	Confirma después
Instalación	Paquete, origen del navegador y del driver	Instalación reproducible en un runner limpio
Inicio	Proceso local, nodo Grid o endpoint remoto	Proceso propietario y sus registros
Versiones	Versiones de framework y navegador	Ambas aparecen explícitamente en la salida de CI
Cierre	Borrado de sesión y limpieza de procesos	Navegador y contexto se cierran tras éxito, fallo y timeout

Semántica de esperas y condiciones de interacción

La sincronización es una fuente habitual de regresiones porque llamadas parecidas pueden esperar en momentos distintos. Selenium expone esperas explícitas como WebDriverWait con condiciones esperadas. El autor elige una condición y un timeout, por ejemplo esperar visibilidad o un cambio de URL. Las esperas implícitas afectan a las búsquedas de elementos y pueden interactuar de forma confusa con las explícitas; la migración es una oportunidad para encontrar y retirar supuestos de tiempo mezclados.

Playwright hace que los locators esperen las condiciones de accionabilidad documentadas antes de acciones como un clic. En ese caso se comprueban, entre otras, visibilidad, estabilidad, recepción de eventos y habilitación. Esto reduce esperas manuales para interacciones comunes, pero no hace que toda transición propia de una aplicación sea automática. Aún puede ser necesario esperar una respuesta, una URL, un estado de dominio o el fin de un trabajo asíncrono.

Puppeteer ofrece sus propias APIs de espera y locator; no traduzcas una espera Selenium por coincidencia de nombres de métodos. Primero expresa la condición requerida. “Esperar hasta que el botón admita entrada” no es lo mismo que “esperar a que termine el guardado” ni que “esperar a ver el valor después de navegar”. Traduce la condición, no solo la línea antigua.

Considera una página con un botón Guardar y un mensaje de estado. La versión Selenium hace explícita la transición esperada; una versión Playwright puede usar una acción sobre un locator y después comprobar el estado resultante:

# Selenium Python: the page has already been opened.
from selenium.webdriver.common.by import By
from selenium.webdriver.support import expected_conditions as EC
from selenium.webdriver.support.ui import WebDriverWait

save = (By.CSS_SELECTOR, "button#save")
WebDriverWait(driver, 5).until(EC.element_to_be_clickable(save)).click()
WebDriverWait(driver, 5).until(
    EC.text_to_be_present_in_element((By.ID, "status"), "Saved")
)

# Playwright Python: page is an async Playwright Page.
from playwright.async_api import expect

await page.get_by_role("button", name="Save").click()
await expect(page.locator("#status")).to_have_text("Saved")

El segundo ejemplo no promete que Playwright nunca necesite esperas. La acción del locator espera su contrato de accionabilidad y la aserción reintenta hasta cumplir la condición o vencer el timeout. La prueba sigue declarando el resultado importante. Al migrar, conserva esa aserción aunque el framework permita quitar una espera separada de “se puede pulsar”.

Evidencia para depurar

Los artefactos de fallo forman parte del contrato de automatización. Los equipos Selenium pueden depender de registros del driver o navegador, capturas, metadatos de sesión Grid, video generado por el servicio de ejecución o informes del runner. Los artefactos disponibles dependen de la infraestructura; Selenium no hace que cada despliegue genere el mismo paquete.

El trace viewer de Playwright puede mostrar una secuencia grabada con acciones, snapshots e información de red relacionada cuando se configura y conserva el tracing. Puppeteer tiene sus propias formas de depuración, como DevTools del navegador e inspección del protocolo. No son formatos equivalentes. Un archivo de trace no sustituye por defecto los registros de un nodo Grid, y una captura no explica por sí sola si el fallo fue un locator incorrecto, timeout, respuesta de red o cierre del navegador.

Antes de migrar, enumera las preguntas que responde quién está de guardia ante un fallo de CI: qué acción se ejecutó, qué aspecto tenía la página, qué solicitud falló, qué versión del navegador se usó y si terminó el proceso. Para cada pregunta, identifica el artefacto y dónde se conserva en ambos sistemas. Si el framework nuevo captura más datos pero CI los descarta, la capacidad práctica de depuración no ha mejorado.

Trata los datos sensibles por separado. Las trazas, capturas y registros pueden contener URL, cuerpos de respuesta, identificadores de cuenta o contenido de la página. Decide qué se almacena, quién tiene acceso y durante cuánto tiempo antes de activar una captura más amplia para todas las pruebas.

Qué suele conservarse

La intención de una prueba suele ser más estable que su código de automatización. Un requisito como “el usuario puede guardar un borrador y verlo guardado tras recargar” puede mantenerse aunque cambien API de sesión, selectores y esperas. También pueden conservarse los datos de prueba, las aserciones del dominio y la decisión sobre qué comportamiento del navegador importa. Hay que revisarlos, no copiarlos sin comprobar los supuestos ocultos del framework.

Lo que más probablemente requiera cambios incluye el inicio y cierre del driver, wrappers de page objects, selectores, helpers de espera propios, capabilities, configuración de workers paralelos, y captura de artefactos en CI. Un page object Selenium puede ocultar esperas implícitas o comportamiento específico del driver; traducir los nombres de sus métodos conservando esos supuestos puede dificultar más el diagnóstico en la suite nueva.

La cobertura de navegadores debe ser un requisito, no un efecto secundario de elegir un framework. Si la suite ejecuta Chrome, Firefox y Safari en endpoints WebDriver distintos, comprueba cómo llega el framework propuesto a esos motores y qué capacidades ofrece en el modo elegido. El éxito solo en Chromium no demuestra que se haya mantenido la cobertura anterior.

Una hoja de migración

Elige una prueba representativa y completa esta tabla antes de estimar toda la suite. “Conservar” significa mantener el requisito o los datos; no significa que el código de automatización siga siendo compatible byte a byte.

Superficie	Registro Selenium actual	Registro de destino	Decisión de migración
Intención	Acción y estado de negocio esperado	El mismo estado esperado	Conserva la aserción; compara tras recarga o navegación si forma parte del requisito
Sesión/protocolo	Endpoint y capabilities WebDriver	Protocolo y modo de conexión	Reescribe el inicio; confirma propiedad remota y motores compatibles
Ciclo	Aprovisionamiento y cierre del driver/navegador	Paquete, ejecutable, servicio y contexto	Reescribe instalación y limpieza; fija versiones de framework y navegador
Sincronización	Esperas y condiciones explícitas/implícitas	Accionabilidad, reintento de locator o condición explícita	Traduce cada condición por significado; quita esperas mezcladas o redundantes
Depuración	Capturas, registros, metadatos Grid y video	Trace, registros, capturas e informe de runner	Asigna cada pregunta del incidente a un artefacto retenido y a una política de acceso
CI	Workers, capacidad de sesiones y reintentos	Modelo de procesos/contextos y hooks de artefactos	Vuelve a medir concurrencia y limpieza; no reutilices supuestos de capacidad

La hoja separa la decisión sobre el framework de la estimación de migración. Si el equipo no puede identificar el endpoint de protocolo o el artefacto necesario para depurar una prueba, debe resolver esas dudas antes de convertir cientos de pruebas. Si solo cambia una fila en su caso, una reescritura más amplia puede no justificarse. Para diagnósticos centrados en esperas Selenium, consulta Selenium: esperas y pruebas estables; para comparar dos alternativas orientadas a CDP, consulta Playwright frente a Puppeteer para automatización.

Evalúa una prueba antes de la suite

Elige una prueba que incluya una acción normal, una transición asíncrona y una aserción significativa. No empieces por la más frágil ni por una página estática trivial: ambas pueden dar una estimación engañosa. Ejecuta la prueba Selenium actual en un entorno parecido a CI y guarda versiones, tiempos, artefactos y resultado de limpieza. Después implementa el mismo requisito en el framework candidato sin cambiar el comportamiento de la página ni el resultado esperado.

Compara ambas ejecuciones mediante preguntas, no con una sola cifra de aprobado/fallo. ¿Iniciaron el navegador y la versión previstos? ¿Llegaron al mismo estado de página? ¿Un fallo forzado dejó evidencia suficiente para localizar el paso? ¿Se cerró el navegador tras un timeout? ¿Se conservaron todos los motores requeridos? Anota cada diferencia y su responsable: código de prueba, runner, proceso del navegador o aplicación.

No deduzcas que un framework nuevo hizo al navegador más consistente, menos detectable o más aceptado por un destino. La elección del framework controla interfaces de automatización y parte del ciclo de vida; no declara todo el entorno ni determina la respuesta de un sitio. BotBrowser documenta entradas de navegador seleccionables en rutas de automatización compatibles, pero no convierte suites Selenium ni armoniza sus protocolos. La referencia de consistencia de automatización describe ese límite de configuración del navegador.

Preguntas frecuentes

¿Playwright sustituye a Selenium directamente?

No. La intención de la prueba puede transferirse, pero la API de sesión, el protocolo, el ciclo del navegador, los selectores, las esperas y los artefactos de depuración pueden ser distintos. Migra una prueba representativa y mapea esas diferencias antes de estimar la suite.

¿Selenium Manager elimina el trabajo de configurar el navegador?

Puede administrar la instalación de drivers y navegadores en flujos Selenium compatibles, pero el equipo aún debe decidir fijación de versiones, caché, propiedad en CI, ejecución remota y limpieza. Cambia partes del aprovisionamiento; no elimina el contrato de ciclo de vida.

¿El auto-waiting significa que nunca hacen falta esperas explícitas?

No. El auto-waiting cubre condiciones de accionabilidad documentadas para operaciones compatibles. Las pruebas aún deben esperar resultados propios de la aplicación, como un guardado completado, una navegación o un trabajo en segundo plano.

¿Conviene empezar convirtiendo todos los page objects?

No. Empieza por una prueba representativa de extremo a extremo y conserva su aserción de resultado. Esa prueba revela si el coste real está en el protocolo, la propiedad del navegador, los tiempos o la evidencia del fallo.

¿Cambiar de framework hace que un sitio vea otra identidad de navegador?

Las elecciones de framework y conexión pueden cambiar el comportamiento de automatización, pero no especifican por sí solas todos los valores del navegador, red o dispositivo. Trátalos como preguntas separadas de configuración y medición; no deduzcas identidad por el nombre de la biblioteca.

Fuentes

• W3C WebDriver, segunda edición
• Selenium WebDriver
• Esperas de Selenium
• Selenium Manager
• Selenium WebDriver BiDi
• Accionabilidad de Playwright
• Conexiones BrowserType de Playwright
• Trace Viewer de Playwright
• WebDriver BiDi en Puppeteer
• Interacciones de página de Puppeteer
• Depuración de Puppeteer
• Consistencia de automatización de BotBrowser

Conclusión práctica

Una alternativa a Selenium implica migrar contratos de control, no solo cambiar de paquete. Compara protocolo y propiedad de sesión, aprovisionamiento del navegador, semántica de esperas y artefactos de fallo necesarios para el equipo. Conserva estable la intención de la prueba, reescribe los bordes específicos del framework y usa una prueba representativa para exponer el coste real antes de mover la suite.