Playwright vs Selenium: qué elegir y cuándo migrar en 2026

Al comparar Playwright vs Selenium en 2026, la recomendación es elegir Playwright para un nuevo conjunto de pruebas de navegador y Selenium cuando lo exijan los navegadores que debes cubrir o la infraestructura existente. Playwright admite 3 motores de navegador, pero su compilación de WebKit no es Safari. Esa diferencia puede resolver la elección antes de que un agente de IA escriba una sola prueba. Navegadores compatibles con Playwright.

Playwright vs Selenium: ¿cuál conviene elegir?

Elige Playwright para una aplicación web nueva si cubre los navegadores que necesitas. Su propuesta encaja especialmente bien en proyectos JavaScript o TypeScript que buscan un flujo común para el ejecutor de pruebas, las aserciones, el aislamiento del navegador y el análisis de fallos. Por eso también es la recomendación inicial cuando un agente de programación va a generar buena parte del código de pruebas: tendrás que definir y enseñarle menos convenciones por separado.

Elige Selenium si necesitas el navegador Safari, quieres usar Ruby o ya dependes de un conjunto de pruebas con WebDriver y Grid bien mantenido. WebDriver es la interfaz de control del navegador sobre la que se apoya Selenium. Los fixtures, los informes de fallos, las configuraciones de navegador y la experiencia operativa que ya tienes aportan valor. Sustituirlos exige una mejora concreta que puedas demostrar en tu aplicación.

Mantén una solución mixta si los requisitos lo justifican. Un área nueva del producto puede usar Playwright mientras Selenium conserva una prueba de regresión específica de un navegador. Asigna a cada prueba un responsable y una razón de ser; evita mantener indefinidamente los mismos recorridos en ambos sistemas.

El orden para decidir es sencillo: primero, los navegadores que debes cubrir; después, la compatibilidad con tu lenguaje y tu ejecutor de pruebas; por último, el esfuerzo de diagnóstico y mantenimiento ante los fallos. La integración con agentes resulta útil una vez satisfechos esos requisitos.

Las capacidades de los frameworks se verificaron en la documentación vigente de Playwright y Selenium el 19 de octubre de 2026. Esta comparativa se basa en documentación; no es una prueba práctica de rendimiento.

Los servicios de grid alojados se contratan como infraestructura aparte. Consulta la comparativa actual de alternativas a BrowserStack para evaluar esa decisión.

Arquitectura: ¿un flujo de pruebas integrado o una biblioteca que encaja en tu sistema?

Playwright lleva ventaja al crear un flujo de pruebas desde cero; Selenium, cuando la prioridad es integrar la automatización del navegador en un sistema de pruebas existente. La diferencia está en lo que rodea a los comandos del navegador, no en una ventaja garantizada de velocidad de ejecución.

Playwright: todo el ciclo de pruebas en un mismo entorno

Playwright es un framework de automatización de navegadores cuyo paquete para Node.js incluye Playwright Test, su ejecutor de pruebas. Un ejecutor descubre las pruebas, prepara su entorno, programa la ejecución y presenta los resultados. La documentación de lenguajes de Playwright distingue esta experiencia integrada de las integraciones disponibles en otros lenguajes. Integraciones de Playwright por lenguaje.

Una pieza clave de su arquitectura es el contexto de navegador: un perfil aislado con sus propias cookies y su propio almacenamiento. Playwright Test proporciona un contexto nuevo para cada prueba. Así, un escenario de inicio de sesión puede comenzar sin heredar la sesión de otro. Aislamiento mediante contextos de navegador.

Este enfoque encaja cuando quieres que el proyecto comparta una forma de escribir y analizar pruebas de navegador. Sus límites están en la cobertura y la integración: el ejecutor de Node.js no se utiliza en todos los lenguajes, y las compilaciones de navegador no sustituyen cualquier requisito de probar el navegador oficial de una marca.

Selenium: construir el sistema de pruebas alrededor de WebDriver

Selenium es un conjunto de herramientas de automatización de navegadores basado en WebDriver. Su biblioteca está pensada para formar parte de una aplicación de pruebas más amplia. Tú eliges el ejecutor y la biblioteca de aserciones, y decides cómo preparar el entorno, liberar los recursos al terminar y generar los informes. Diseño de Selenium, organización de las pruebas.

Entre el código de Selenium y el navegador interviene un controlador específico de ese navegador. Si no se ha proporcionado uno, Selenium Manager puede localizar, descargar y guardar en caché el controlador necesario, lo que elimina el paso habitual de descargarlo a mano. Selenium Manager.

Elige Selenium cuando el sistema que lo rodea ya aporte valor. Su exigencia es contar con un responsable: alguien debe mantener la coherencia de las esperas, el ciclo de vida de las sesiones y los archivos de diagnóstico. Para evaluarlo, un responsable de ingeniería debe examinar toda esa infraestructura de pruebas, además de comprobar que un comando de clic funciona.

Lenguajes y navegadores: la cobertura puede pesar más que la comodidad

Selenium gana cuando hay requisitos que Playwright no puede satisfacer directamente, en especial Ruby y el navegador Safari. Para un conjunto de pruebas nuevo en JavaScript o TypeScript, el ejecutor integrado de Playwright sigue siendo la mejor opción por defecto.

Playwright admite JavaScript/TypeScript, Python, Java y .NET. La automatización básica del navegador comparte una implementación subyacente, pero la integración con las pruebas cambia: JavaScript/TypeScript dispone de Playwright Test; Python utiliza el plugin recomendado para pytest; Java puede usar JUnit o TestNG; y .NET cuenta con clases base para frameworks de pruebas. Lenguajes compatibles.

Selenium documenta bibliotecas para Java, Python, C#/.NET, Ruby y JavaScript. Kotlin utiliza las de Java. Por tanto, disponer de un conjunto de pruebas en Ruby es una razón concreta para conservar Selenium: migrar implica algo más que cambiar el nombre de una biblioteca. Instalación de Selenium por lenguaje.

Playwright vs Selenium en Python

Elige Playwright para Python si su API de navegador y sus fixtures basados en contextos resuelven un problema de mantenimiento que tienes ahora. Conserva Selenium para Python si tus fixtures de pytest, los navegadores cubiertos y los informes existentes ya cumplen su función. Ambas opciones requieren configurar expresamente el entorno de pruebas de Python.

No decidas una migración en Python a partir de una demostración del ejecutor de Node.js. La documentación de Playwright para Python utiliza pytest-xdist para ejecutar pruebas en paralelo. Las capacidades de automatización del navegador se trasladan entre las bibliotecas de los distintos lenguajes; la configuración del ejecutor, no. Ejecutor de pruebas de Playwright para Python.

Selenium vs Playwright: probar el navegador oficial cambia la respuesta

Playwright automatiza Chromium, Firefox y WebKit, y puede utilizar los canales de Google Chrome y Microsoft Edge. Sus integraciones de Firefox y WebKit dependen de parches; la documentación excluye expresamente las versiones oficiales de Firefox y Safari. Selenium incluye Chrome, Edge, Firefox, Safari y un controlador de Internet Explorer. Navegadores de Playwright, navegadores de Selenium.

Por eso, «hay que reproducirlo en Safari» y «hay que detectar problemas de renderizado en WebKit» son requisitos distintos. Para el primero, Selenium documenta sesiones en Safari mediante SafariDriver. Para el segundo, la cobertura de WebKit de Playwright puede ser adecuada. Del mismo modo, un área de visualización móvil o un perfil de dispositivo sigue siendo una emulación, no una comprobación en un teléfono físico. Compatibilidad de Selenium con Safari.

Antes de convertir ninguna prueba, deja por escrito las combinaciones de navegador y sistema operativo que debe cubrir la evaluación. Ningún framework compensa haber probado el entorno equivocado.

Esperas automáticas: Playwright facilita la escritura de pruebas desde el inicio

Playwright lleva ventaja porque sus acciones habituales incorporan comprobaciones útiles para saber si se pueden ejecutar. Una prueba inestable es aquella cuyo resultado cambia sin que haya un cambio relevante en el producto, a menudo porque la prueba y la aplicación avanzan a ritmos distintos.

Antes de hacer un clic normal con un localizador, Playwright comprueba que este identifique un único elemento y que el elemento sea visible, estable, esté habilitado y pueda recibir eventos. Sus aserciones pueden reintentarse hasta que se cumpla la condición esperada. Esto evita repetir en muchas pruebas el código que comprueba si se puede continuar. Comprobaciones de interacción de Playwright.

Selenium también espera. La navegación sigue una estrategia de carga de página; las esperas implícitas se aplican a la búsqueda de elementos; y las explícitas consultan periódicamente una condición que tú defines. La diferencia decisiva es que haber cargado el documento o encontrado un elemento no demuestra que una aplicación dinámica esté lista para la siguiente acción. Selenium advierte que no deben mezclarse esperas implícitas y explícitas. Estrategias de espera de Selenium.

Piensa en un proceso de compra donde el botón de pago aparece antes de que termine la validación del envío. Con Selenium, expresa la condición que necesita la siguiente acción en lugar de introducir una pausa de duración fija. Con Playwright, las comprobaciones previas al clic ayudan si la aplicación expone correctamente el estado deshabilitado del botón.

En ambos frameworks sigue haciendo falta una aserción que compruebe que el pedido alcanzó el estado esperado. Que un clic se ejecute bien no demuestra que el pago se haya completado. Esto cobra especial relevancia en las pruebas escritas por agentes: revisa el resultado esperado con tanto cuidado como el localizador.

Ejecución en paralelo: Playwright para empezar, Grid para gestionar navegadores remotos

Playwright gana por la sencillez de la ejecución en paralelo en un nuevo conjunto de pruebas de Node.js. Selenium Grid gana cuando necesitas gestionar una infraestructura remota de navegadores WebDriver. Resuelven problemas relacionados, pero en capas diferentes.

Playwright Test ejecuta los archivos de pruebas en paralelo por defecto, mientras que las pruebas de un mismo archivo se ejecutan en orden salvo que se configure otra cosa. Puedes controlar los workers, activar el paralelismo completo y repartir la suite entre máquinas mediante shards. Un shard es una parte del conjunto de pruebas asignada a un trabajo de ejecución separado. Ejecución en paralelo de Playwright.

Selenium Grid dirige los comandos a instancias remotas de navegador distribuidas entre máquinas, versiones de navegador y sistemas operativos. El ejecutor de pruebas sigue decidiendo qué pruebas empiezan al mismo tiempo. Por tanto, la capacidad de Grid y la concurrencia de las pruebas se configuran por separado: añadir máquinas con navegadores no transforma por sí solo una programación secuencial. Selenium Grid, responsabilidades del ejecutor.

En ambos sistemas, una fuente importante de fallos son los datos compartidos de la aplicación. Dos perfiles de navegador separados pueden seguir modificando el mismo registro de cliente. Si una prueba cambia una contraseña mientras otra intenta iniciar sesión con el valor anterior, el conflicto procede de tus fixtures, no del framework de navegador. La guía de paralelismo de Playwright distingue expresamente el aislamiento del navegador del estado externo. Recomendaciones sobre estado compartido.

Antes de aumentar los workers, asigna registros independientes a las pruebas concurrentes y deja claro quién se encarga de limpiarlos. Para un responsable que debe elegir un framework, un piloto útil mide la fiabilidad de la cobertura y la facilidad para investigar fallos, además de cuántos navegadores pueden arrancar.

Herramientas: Playwright facilita el diagnóstico de fallos desde el inicio

Playwright gana en herramientas integradas para crear y depurar pruebas. La ventaja práctica está en la rapidez con la que quien revisa una prueba fallida puede entender qué intentó hacer y qué mostró la aplicación.

La herramienta codegen de Playwright registra interacciones con el navegador, ayuda a elegir localizadores y permite añadir aserciones de visibilidad, texto y valores. Usa la grabación como borrador. En un flujo de configuración de cuenta, revisa si la prueba generada comprueba que los cambios persisten después de guardarlos, en lugar de limitarse a recorrer los controles. Generador de pruebas de Playwright.

Trace Viewer permite examinar, después de la ejecución, las acciones registradas junto con las instantáneas de la página, el código fuente, la salida de la consola y la actividad de red. Así, una ejecución fallida en CI deja un historial que se puede revisar. Decide expresamente cómo recopilar las trazas: la documentación describe opciones para conservarlas cuando hay un fallo o registrarlas durante un reintento. La traza de un reintento muestra ese reintento; al investigar comportamientos intermitentes, considera conservar también el intento original que falló. Trace Viewer y opciones de recopilación.

La documentación vigente describe Selenium IDE, su herramienta de grabación y reproducción, como una aplicación independiente para Windows, macOS y Linux. Esa página de presentación se actualizó el 9 de octubre de 2026. Sirve para registrar los pasos con los que reproducir un problema o aprender una secuencia de comandos. Trata el flujo grabado como material de partida para una prueba mantenible, al que debes añadir las aserciones y la preparación de datos necesarias. Documentación actual de Selenium IDE.

Un conjunto de pruebas de Selenium puede ofrecer información de diagnóstico útil mediante su ejecutor, capturas de pantalla y registros, tal como recomienda su guía para agentes. Al elegir, comprueba si tu infraestructura de pruebas ya facilita la consulta de esas evidencias. Si es así, las herramientas integradas de Playwright aportan menos valor a una migración que en un sistema cuya única evidencia es una tarea fallida.

WebDriver BiDi: Selenium va más allá de la petición y la respuesta

Selenium gana cuando la interoperabilidad del protocolo WebDriver es un requisito. Descartarlo como un controlador de navegador incapaz de observar eventos pasa por alto su arquitectura actual.

WebDriver BiDi es el protocolo bidireccional que describe la documentación de Selenium. Junto con la automatización tradicional de comandos y respuestas, una conexión WebSocket permite que los eventos del navegador lleguen al programa que lo controla. Esto resulta útil para los mensajes de consola, los errores de JavaScript y la actividad de red: la prueba puede recibir los eventos a medida que ocurren. Selenium presenta BiDi como su dirección para trabajar entre navegadores y describe su compatibilidad con Chrome DevTools Protocol como temporal. WebDriver BiDi.

Por ejemplo, quien investiga fallos intermitentes en un proceso de compra puede necesitar evidencias de los errores del navegador además de una captura de pantalla final. BiDi ofrece una vía documentada para acceder a esas capacidades basadas en eventos sin convertir el protocolo de depuración de Chromium en una dependencia de la arquitectura.

Comprueba la operación concreta en el navegador y la biblioteca de lenguaje que necesitas. La documentación de la API de Selenium indica que la cobertura crece a medida que avanzan el protocolo y las implementaciones de los navegadores. Que exista un estándar común no garantiza que todas las operaciones tengan hoy el mismo soporte en todos los entornos. Alcance de la implementación de BiDi.

BiDi es un protocolo de navegador. Por sí solo, no convierte Selenium en un servidor de herramientas para agentes de IA ni proporciona un ejecutor de pruebas completo.

Agentes de IA: Playwright ofrece una vía más integrada

Playwright gana al crear un flujo nuevo de pruebas con ayuda de agentes. Selenium sigue siendo una opción válida cuando el agente debe trabajar con las herramientas que ya utilizas. Distingue el acceso al navegador, la generación de código y la aprobación de la prueba resultante.

Playwright MCP, CLI y Test Agents cumplen funciones distintas

Playwright MCP es un servidor de Model Context Protocol, un adaptador que expone herramientas que puede invocar un agente de IA. Presenta instantáneas estructuradas de accesibilidad con referencias a elementos, lo que permite al agente examinar una página y seleccionar los controles con los que interactuar. Esto proporciona interacción con el navegador; no demuestra que la prueba resultante compruebe el comportamiento correcto. Playwright MCP.

MCP tampoco es la única opción documentada. Playwright recomienda su interfaz de línea de comandos y sus skills instalables para los flujos de agentes de programación que se benefician de comandos concisos, mientras que MCP encaja en ciclos de exploración persistentes. Elige la interfaz que se ajuste a la forma de trabajar de tu agente. Recomendaciones sobre la CLI de Playwright.

Playwright Test Agents incorpora un planificador, un generador y un reparador. El planificador explora y elabora un plan; el generador lo convierte en pruebas; el reparador investiga fallos y propone correcciones. Revisa las pruebas omitidas: según la documentación, el reparador puede dejar una prueba omitida si considera que la funcionalidad está rota. Una ejecución en verde después de omitir una prueba no significa que se haya recuperado la cobertura. Playwright Test Agents.

Sigue la guía de pruebas de navegador con Playwright MCP para configurarlo y somete después las pruebas generadas a la revisión habitual de código.

Las opciones para agentes que documenta Selenium

La propia guía de Selenium para agentes de IA describe una vía sencilla: dejar que el agente de programación escriba y ejecute un script temporal de Selenium para examinar la aplicación y verificar los localizadores. También describe servidores MCP mantenidos por la comunidad y los identifica expresamente como proyectos de terceros, no como componentes de Selenium. Guía de Selenium para agentes.

La misma guía recomienda usar documentación actual, reglas de proyecto por escrito y evidencias de los fallos. Entre sus pautas prácticas figuran las esperas explícitas, las sesiones nuevas, la liberación correcta de recursos y la verificación de localizadores en la aplicación en ejecución. Con ello, un conjunto de pruebas consolidado en Selenium puede incorporar agentes sin migrar de framework.

En cualquiera de las dos opciones, pide al agente que explique la aserción, ejecute la prueba y adjunte evidencias. Revisa los cambios en los resultados esperados, las pruebas que se añadan a la lista de omitidas y las comprobaciones que pierdan rigor. Lo útil es entregar una prueba que proteja un requisito, no una transcripción donde un agente haya recorrido la aplicación haciendo clic correctamente.

Migrar de Selenium a Playwright: incluye la infraestructura de pruebas en el presupuesto

El coste de migrar está en reconstruir las convenciones de prueba que rodean a la API del navegador. Plantea el cambio de Selenium a Playwright como un proyecto de cobertura por etapas, no como una conversión masiva de sintaxis.

A menudo puedes conservar la intención de una prueba: un cliente autorizado cambia una dirección de entrega y la ve en el siguiente pedido. Las llamadas a elementos de Selenium, las esperas, los objetos de página y la preparación de sesiones necesitan revisión o reescritura. Un objeto de página es una abstracción que oculta los controles de una pantalla detrás de operaciones como «guardar dirección». Conserva el vocabulario de negocio útil y sustituye de forma deliberada los mecanismos específicos del navegador.

El coste operativo incluye un periodo de convivencia de ambos conjuntos de pruebas, una nueva configuración de CI y enseñar a quienes revisan el código cómo investigar los fallos. La dependencia de cada herramienta reside sobre todo en tu código y tus convenciones de trabajo: un localizador, un fixture o un flujo de trazas de Playwright no sustituye directamente a una utilidad de WebDriver y sus informes. Que ninguno cobre una licencia elimina ese gasto, pero no el trabajo de ingeniería.

1. 1

   Haz un inventario de requisitos antes de convertir las pruebas

   Enumera los navegadores que debes cubrir, el lenguaje, el ejecutor, los objetos de página, la preparación de la autenticación, la creación de datos, las descargas o cargas de archivos, los informes y las dependencias de Grid. Señala qué pruebas requieren el navegador Safari u otro entorno que la configuración propuesta de Playwright no cubra. Conserva esas pruebas en el sistema actual hasta disponer de una alternativa que satisfaga el requisito.

2. 2

   Prueba un recorrido representativo en un piloto

   Elige un flujo con autenticación, una interfaz que cambie de estado y una aserción sobre un resultado de negocio persistente. Añade un escenario que resulte difícil para tu conjunto de pruebas actual. Conserva el comportamiento esperado mientras reescribes localizadores y esperas; no permitas que una conversión generada elimine comprobaciones sin avisar para conseguir que la prueba pase.

3. 3

   Reconstruye el aislamiento y la recogida de evidencias de fallos

   Traslada la preparación del navegador a los fixtures del lenguaje elegido. Asigna registros independientes de la aplicación a las pruebas, define cómo gestionar el estado de autenticación y recopila archivos útiles para diagnosticar fallos. Confirma que el piloto funciona tanto solo como junto a otras pruebas. El aislamiento de contextos de navegador no crea datos independientes en el backend.

4. 4

   Compara la cobertura antes de cambiar las pruebas que autorizan una entrega

   Ejecuta el piloto en los navegadores y las condiciones de CI que pretendes admitir. Registra las carencias de cobertura, los fallos intermitentes, el esfuerzo de investigación y los cambios en las aserciones. Da por válida la migración cuando el piloto cumpla tus requisitos y mejore un problema de mantenimiento identificado. Conserva Selenium donde siga satisfaciendo mejor un requisito.

No migres un sistema de Selenium que funciona bien solo porque un agente pueda generar código de Playwright. No traslades un conjunto de pruebas en Ruby sin tener en cuenta el cambio de lenguaje, ni sustituyas comprobaciones en Safari por WebKit dando por equivalente la cobertura. En cambio, un sistema dominado por utilidades frágiles e informes de fallos ilegibles sí es un candidato razonable para un piloto con Playwright.

Para empezar el lunes: elige el recorrido crítico para las entregas que tenga los criterios de aceptación más claros, anota los navegadores que debe cubrir y compara el trabajo de mantenimiento de ese recorrido. Amplía el alcance solo cuando las evidencias respalden el cambio.

Preguntas frecuentes

¿Qué es más fácil de aprender, Selenium o Playwright?

Playwright es el punto de partida más sencillo para un nuevo conjunto de pruebas en JavaScript o TypeScript porque integra el ejecutor y las herramientas de pruebas. Selenium puede ser más fácil de adoptar si ya conoces el lenguaje y el ejecutor en los que va a integrarse. La experiencia previa y los navegadores requeridos pueden pesar más que la ventaja de configuración inicial.

¿Qué alternativas hay a Playwright?

Selenium es la alternativa directa de esta comparativa, sobre todo para probar en Safari, trabajar con Ruby o aprovechar una infraestructura WebDriver existente. Evalúa cualquier alternativa según los navegadores que debes cubrir y el problema de mantenimiento que necesitas resolver.

¿Playwright está obsoleto?

No. La documentación vigente que se verificó para esta comparativa describe flujos actuales de pruebas de navegador, MCP, CLI y agentes de pruebas. Lo relevante es si esas herramientas cubren los requisitos de tu aplicación.

¿Hay demanda de Selenium con Java?

Java es uno de los lenguajes compatibles con Selenium. La documentación del proyecto no acredita la demanda de contratación, por lo que no permite hacer afirmaciones sobre el mercado laboral actual. Para elegir un framework, evalúa los conocimientos de Java y la infraestructura de pruebas que ya tienes.

¿Playwright va a sustituir a Selenium?

Esta comparativa no ofrece una base para predecir una sustitución universal. Playwright es la opción recomendada por defecto para un conjunto de pruebas nuevo cuyos entornos sean compatibles; Selenium sigue cubriendo requisitos de navegador, lenguaje e infraestructura que pueden decidir la elección.

¿Cuánto gana un tester de Selenium?

La documentación de ninguno de los proyectos aporta datos salariales. Para ofrecer una estimación creíble harían falta una ubicación, un nivel de experiencia y datos actuales de remuneración; la elección de framework no basta para determinarla.

¿Basta con saber Selenium para conseguir trabajo?

Conocer Selenium por sí solo no demuestra todas las capacidades que puede exigir un puesto de pruebas. Aporta evidencias de que sabes diseñar aserciones útiles, gestionar datos de prueba, investigar fallos y mantener pruebas en CI.

¿Qué especialidad de pruebas paga mejor?

Las fuentes utilizadas aquí no permiten establecer una clasificación salarial entre especialidades de pruebas. Para un responsable de ingeniería, la elección del framework debe basarse en la cobertura necesaria y la facilidad de mantenimiento, no en una comparación de sueldos sin respaldo.

¿Puedo aprender automatización en 2 meses?

Tómalo como un plan de aprendizaje con un plazo definido, no como una garantía de preparación. Limita el alcance a una aplicación pequeña y demuestra que puedes crear pruebas independientes, escribir aserciones relevantes, diagnosticar fallos y ejecutar las pruebas en CI antes de ampliar el trabajo.

Consigue la AI Business Workflow Audit Checklist a través de la newsletter para identificar qué tareas de pruebas merece la pena automatizar antes de ampliar el conjunto.