Automatización del navegador: Playwright + QA

Módulo: 9. Funciones avanzadas | Tiempo: ~25 min de teoría + 60 min de práctica

Lo esencial

Imagina que contrataste a un tester que trabaja a la velocidad de una computadora: en 30 segundos revisa 50 formularios, hace clic en cada botón, llena los campos, comprueba que aparezca el mensaje correcto, y lo hace igual cada vez. Playwright (una biblioteca de Microsoft para automatizar el navegador) + Claude Code es ese tester. Tú lo ves trabajar, notas los problemas, le pides que los corrija, y mejora frente a tus ojos.

Términos de la lección: API (interfaz de programación), headless (sin interfaz gráfica), CI/CD (Continuous Integration/Delivery, compilación y entrega automáticas), deploy (despliegue), workflow (flujo de trabajo).

Conceptos clave

Claude Code controla el navegador: clics, escritura, scraping, capturas de pantalla
Playwright: modo headed (navegador con ventana visible) frente a headless (navegador sin ventana, solo en segundo plano)
Ejemplo en vivo: prueba de QA (Quality Assurance, control de calidad) de un formulario de varias páginas, con iteraciones
Navegadores en paralelo para ir más rápido
Navegador con sesión iniciada a través de un perfil de Chrome

Teoría

Qué puede hacer Claude Code con el navegador

Con Playwright, Claude Code puede controlar el navegador desde código:

Navegación: abrir una URL, ir atrás/adelante, recargar la página
Interacción: hacer clic en un elemento, escribir texto, elegir de un menú desplegable, subir un archivo
Scraping: extraer texto, tablas, imágenes, metadatos
Capturas de pantalla: de la página completa o de un elemento concreto
Esperas: esperar a que un elemento aparezca, desaparezca o cambie
Intercepción de solicitudes: interceptar y modificar solicitudes a la API (interfaz de programación)

Playwright es control total del navegador desde código. Hay también un segundo camino, sin escribir tu propio script: la extensión Claude in Chrome (más abajo).

El segundo camino: Claude in Chrome

Claude Code puede trabajar con tu navegador a través de la extensión Claude in Chrome. No hace falta escribir un script: describes la tarea con palabras y Claude abre pestañas, hace clic, lee la consola y las capturas de pantalla.

bash

claude --chrome

El comando /chrome dentro de la sesión muestra el estado de la conexión y la configuración de permisos. Qué necesitas: Google Chrome o Microsoft Edge (también se detectan otros navegadores basados en Chromium), una versión actual de la extensión Claude in Chrome, un plan de pago de Anthropic (Pro, Max, Team o Enterprise) e iniciar sesión con /login. La integración no funciona solo con una clave de API. No es compatible con WSL.

Detalles finos:

Claude usa tu sesión iniciada en el navegador, así que puede abrir cualquier sitio donde ya entraste. Es práctico y peligroso a la vez: ver la lección Permisos y seguridad.
Si aparece una página de inicio de sesión o un captcha, Claude se detiene y te pide que lo hagas tú a mano. No hace falta saltarse el captcha con automatización, y tampoco se puede.
Cuando necesitas una prueba repetible que corra en un servidor sin pantalla, escribe un script de Playwright: es más rápido y no depende de tu navegador.
La extensión Claude in Chrome salió de beta; consulta los requisitos vigentes en la documentación y en la página Lo vigente.

Headed frente a headless

🎨 Imagínalo así: el modo headed es como aprender a manejar con instructor: ves el volante, ves el camino, puedes frenar. El headless es como el piloto automático de un avión: todo pasa por dentro, afuera hay silencio, pero vuela.

Modo headed (el navegador se ve en pantalla):

python

browser = playwright.chromium.launch(headless=False)

Ves cada acción en tiempo real
Puedes intervenir si algo sale mal
Ideal para desarrollar y depurar
Más lento (dibuja la interfaz)

Modo headless (el navegador corre en segundo plano):

python

browser = playwright.chromium.launch(headless=True)

El navegador no se ve: trabaja en segundo plano
Más rápido (no dibuja nada)
Ideal para producción y CI/CD
Se puede ejecutar en un servidor sin pantalla

La regla de oro:

Desarrollo → headed (ves qué pasa, depuras)
Despliegue → headless (velocidad; en el servidor no hay pantalla)

Escenarios de uso

🎨 Imagínalo así: un tester con Playwright es como el inspector de calidad de una fábrica. En lugar de revisar cada pieza a mano, usa un banco de pruebas automático: la pieza entra, el sistema revisa 50 parámetros en un segundo y dice OK o DEFECTUOSA.

Automatización de QA: Probar cada formulario, cada botón, cada recorrido del usuario. Escribes la prueba una vez y la ejecutas cientos de veces. Encuentras una regresión (que vuelva un error viejo) antes que tus usuarios.

Web scraping: Recolectar datos de sitios que usan JavaScript (el lenguaje de programación de las páginas web, contenido dinámico). Una simple solicitud HTTP (HyperText Transfer Protocol, el protocolo de transferencia de datos) no basta: hay que esperar a que cargue el DOM (Document Object Model, la estructura de la página). Playwright espera automáticamente.

Automatizar acciones: Llenar formularios, publicar contenido, usar aplicaciones web como lo haría una persona. Por ejemplo: publicar artículos en una plataforma de blog con un horario automático (cron, el programador de tareas).

Pruebas visuales: Tomar capturas de cada página y compararlas con una referencia. Si cambiaron los píxeles, algo se rompió visualmente.

Ejemplo en vivo: prueba de QA de un formulario de varias páginas

Imagina que tienes un formulario de solicitud de préstamo de 5 páginas. Hay que asegurarse de que:

Cada página carga sin errores
La validación funciona bien (no se puede avanzar con un campo vacío)
La barra de progreso muestra el porcentaje correcto
La página final muestra el resumen correcto

Paso 1: Claude Code escribe el script de Playwright

python

from playwright.sync_api import sync_playwright

def test_loan_application_form():
    with sync_playwright() as p:
        # Modo headed para desarrollar
        browser = p.chromium.launch(headless=False)
        page = browser.new_page()
        
        # Página 1: datos personales
        page.goto("https://myapp.com/apply")
        page.fill("#first-name", "Juan")
        page.fill("#last-name", "Pérez")
        page.fill("#email", "juan@example.com")
        page.click("#next-button")
        
        # Comprobamos que pasamos a la página 2
        page.wait_for_url("**/apply/step-2")
        assert page.locator(".progress-bar").get_attribute("value") == "40"
        
        # Página 2: finanzas
        page.fill("#monthly-income", "3000")
        page.fill("#loan-amount", "10000")
        page.click("#next-button")
        
        # ... etcétera

Paso 2: ejecutar y observar

Se abre Chrome. Ves cómo, de forma automática:

Se escribe texto en los campos
Se hace clic en el botón "Siguiente"
Pasa a la página siguiente

Paso 3: aparece un problema

Observas que el botón "Siguiente" recibe dos clics cuando todo corre rápido. Eso provoca un doble envío.

Escribe esto en el chat

Error en la prueba:
Expected URL: /apply/step-2
Actual URL: /apply/step-3  # ¡Se saltó una página!

Paso 4: detenemos y corregimos

Escribe esto en el chat

Le dices a Claude Code:
"El clic del botón se ejecuta dos veces y se salta la página 2.
Corrígelo: agrega wait_for_load_state después del clic,
asegúrate de que la página siguiente cargó antes de la siguiente acción."

Claude Code corrige el script:

python

page.click("#next-button")
page.wait_for_load_state("networkidle")  # Esperamos a que cargue por completo
page.wait_for_url("**/apply/step-2")    # Comprobamos que la URL es la correcta

Paso 5: ejecutamos otra vez

Ahora funciona bien. La prueba recorre las 5 páginas.

El ciclo de desarrollo:

Código

Construimos la prueba → La ejecutamos → Vemos el problema → Corregimos → Ejecutamos otra vez

Este ciclo se repite 5-10 veces hasta que la prueba pasa de forma confiable.

Navegadores en paralelo

Un navegador prueba un escenario. Si los ejecutas en paralelo, pruebas varios escenarios al mismo tiempo:

python

from playwright.sync_api import sync_playwright
import concurrent.futures

test_cases = [
    {"user": "juan_perez", "loan": "10000"},
    {"user": "maria_lopez", "loan": "20000"},
    {"user": "carlos_ramirez", "loan": "5000"},
]

def run_test(test_case):
    with sync_playwright() as p:
        browser = p.chromium.launch(headless=True)
        # ... la prueba para el caso concreto

with concurrent.futures.ThreadPoolExecutor(max_workers=3) as executor:
    results = executor.map(run_test, test_cases)

Tres navegadores trabajan en paralelo: las pruebas van 3 veces más rápido.

Navegador con sesión iniciada

🎨 Imagínalo así: abrir Chrome con tu perfil es como darle al robot tu credencial de acceso. Entra al edificio como si fueras tú: con todos tus gafetes, cookies y contraseñas ya adentro.

El problema: quieres automatizar Gmail o cualquier sitio que pida iniciar sesión. Playwright en modo headless no tiene sesión iniciada.

La solución: usar un perfil de Chrome con las sesiones guardadas. Es mejor crear para esto un perfil aparte (no el principal): así el robot solo tiene acceso a lo que abriste en ese perfil:

python

browser = playwright.chromium.launch_persistent_context(
    user_data_dir="/Users/yourname/Library/Application Support/Google/Chrome/Default",
    headless=False,
    channel="chrome"
)

Playwright abre Chrome con las sesiones y cookies guardadas en el perfil: la automatización trabaja con un navegador con sesión iniciada. Las versiones actuales de Chrome pueden negarse por defecto a correr automatización sobre el perfil principal, así que un perfil aparte funciona de forma más confiable.

Usos:

Revisar tu propio panel o el administrador de tu sitio
Descargar datos de tus propias secciones en otros sitios
Automatizar herramientas SaaS que no tienen API

Importante: úsalo solo con tus propias cuentas. Automatizar cuentas ajenas viola los términos de servicio. Muchas plataformas (redes sociales, LinkedIn y otras) prohíben automatizar acciones incluso en tu propia cuenta: lee sus condiciones, o te arriesgas a un bloqueo. No le des a la automatización más acceso del que la tarea necesita: una sesión donde tienes todo abierto es un blanco jugoso para un prompt injection (ver defensa contra prompt injection).

Iteración en vivo: cómo funciona el proceso

🎨 Imagínalo así: cada iteración es como afilar un sable. Después de cada pasada por la piedra, compruebas: ¿corta? ¿No? Otra vez. En 5-10 iteraciones, el script corta limpio.

Ejemplo del proceso: revisar tu propia tienda en línea.

Código

Iteración 1:
Tarea: cada mañana revisar que en 50 fichas de producto funcione el botón "Agregar al carrito"
Ejecutamos → se abre el navegador → abrimos la ficha → presionamos el botón

Problema: "el clic en el botón se ejecuta dos veces"
(al carrito llegan dos productos)

Corrección: esperar a que el botón esté activo y hacer clic una sola vez

---

Iteración 2:
Ejecutamos → los clics funcionan → recorremos las fichas una por una

Problema: "después de 20 fichas el servidor responde con el error 429 (demasiadas solicitudes)"

Corrección: agregar pausas entre fichas (1-3 segundos),
no revisar las 50 seguidas, sino de 10 en 10 con descanso,
tratar con cortesía a tu propio servidor

---

Iteración 3:
Ejecutamos → funciona estable → 50 fichas por corrida sin errores

Lo programamos: una vez al día, con un reporte por correo como resultado

Cada iteración resuelve un problema concreto que apareció en la corrida anterior.

⚠️ No se vale automatizar servicios ajenos para saltarse sus protecciones (captcha, límites de solicitudes): viola sus condiciones y puede terminar en el bloqueo de la cuenta. Practica con tus propios sitios y con entornos de prueba.

Qué evitar al automatizar el navegador

🎨 Imagínalo así: un buen automatizador se porta con cortesía: hace pausas, no martillea el servidor. Uno malo va como máquina de línea de ensamblaje: 100 clics por segundo, y de inmediato viene el límite y el bloqueo.

Agresividad: acciones demasiado rápidas → el servidor limita las solicitudes o te bloquea. Agrega pausas, respeta robots.txt y las condiciones del servicio.

No esperar: click() sin wait_for_element() → clic en un elemento que todavía no carga → error. Espera siempre al elemento antes de interactuar.

Selectores fijos (hardcoded): #submit-btn-v2 → el sitio se actualizó → el selector se rompió. Usa selectores semánticos: button[type="submit"], role=button name="Enviar".

Sin reintentos: la red es inestable → falla una solicitud → falla toda la prueba. Agrega reintentos (retry) a las operaciones inestables.

Práctica

Tarea: escribir una prueba de QA para un formulario público

Elige un sitio público con un formulario (por ejemplo: el formulario de registro de algún servicio, un formulario de contacto)
Pídele a Claude Code que instale Playwright: pip install playwright && playwright install chromium
Describe la prueba: "escribe una prueba de Playwright para el formulario de registro en [URL]. La prueba debe comprobar: todos los campos se llenan, la validación funciona (un campo vacío bloquea el envío), un registro exitoso muestra la confirmación"
Ejecútala en modo headed y observa el navegador
Encuentra al menos un problema (real, o mete datos incorrectos a propósito) y pide que lo corrija
Cuando pase bien: cambia a modo headless y comprueba que funciona
Extra: agrega la ejecución en paralelo de dos navegadores con distintos datos de prueba

Comparación de herramientas de automatización del navegador

Criterio	Playwright	Puppeteer	Selenium
Lenguajes	Python, JS, Java, C#	JavaScript/TypeScript	Python, JS, Java, C#, Ruby
Navegadores	Chromium, Firefox, WebKit	Chromium (Firefox beta)	Todos los principales
Velocidad	Rápido	Rápido	Más lento
Espera automática	Sí (integrada)	Parcial	No (hay que hacerla a mano)
Contextos en paralelo	Sí (browser contexts)	Sí (incógnito)	Con Grid
Codegen (grabar acciones)	Sí	No	Plugins para IDE
Soporte para móviles	Emulación	Emulación	Dispositivos reales
Lo mejor para	Proyectos modernos, QA	Scripts ligeros para Chrome	Proyectos legacy, Selenium Grid

Recomendación: para proyectos nuevos, empieza con Playwright: el mejor equilibrio entre velocidad, documentación y capacidades.

Errores comunes

1. No esperar al contenido dinámico

python

# ❌ Mal: puede que el elemento todavía no haya cargado
page.click("#dynamic-button")

# ✅ Bien: esperamos a que aparezca el elemento
page.wait_for_selector("#dynamic-button")
page.click("#dynamic-button")

2. No usar el modo headed al depurar Si la prueba falla, cambia a headless=False y OBSERVA qué pasa. La mayoría de los problemas se vuelven obvios a simple vista.

3. Usar XPath fijos en lugar de selectores semánticos

python

# ❌ Frágil: se rompe con cualquier cambio en el diseño
page.click("//div[3]/div[2]/button[1]")

# ✅ Robusto: no depende de la posición en el DOM
page.click("button:has-text('Enviar')")
page.get_by_role("button", name="Enviar").click()

4. No manejar los tiempos de espera La red puede ser lenta. Pon siempre un timeout razonable y manéjalo.

5. Ejecutar pruebas sin reintentos en elementos inestables Agrega expect(locator).to_be_visible(timeout=10000) antes de interactuar con elementos que cargan de forma asíncrona.

Herramientas y recursos

Claude in Chrome: extensión para que Claude Code trabaje con tu navegador: claude --chrome — documentación
Playwright: pip install playwright, biblioteca para automatizar el navegador: playwright.dev
Documentación de Playwright para Python: playwright.dev/python
Puppeteer (alternativa para Chrome): pptr.dev
Selenium (alternativa legacy): selenium.dev
playwright install: instala los navegadores: chromium, firefox, webkit
Playwright Inspector: PWDEBUG=1 python test.py, un depurador visual
Playwright Codegen: playwright codegen https://example.com, graba acciones y genera el código
Playwright Trace Viewer: ver la grabación de la ejecución de una prueba paso a paso

Conclusiones clave

Modo headed para desarrollar: ves qué pasa y puedes atrapar el error. Headless para producción: rápido y funciona en un servidor sin pantalla.

El ciclo "construir → probar → ver → corregir → probar otra vez" es lo normal. De 5 a 10 iteraciones para una prueba estable es un buen resultado.

Navegador con sesión iniciada a través de un perfil de Chrome = automatizar todo aquello a lo que tienes acceso, sin pelearte con OAuth ni con 2FA.

Lecciones relacionadas

Computer Use: controlar aplicaciones nativas (cuando Playwright no sirve y necesitas automatizar aplicaciones de escritorio)
Sitios y aplicaciones web: Playwright es ideal para probar los sitios que creaste con esa lección

Qué sigue

→ Permisos y seguridad: cómo darle acceso al agente de forma segura