Mi Ingeniero de QA es un LLM

Claude puede hacer clic en botones.

Suena trivial, pero cambia cómo construyo interfaces de usuario. Con Playwright MCP, Claude no solo escribe código—abre un navegador, navega a localhost y verifica que las cosas realmente funcionen. Detecta errores que pasaría por alto en revisiones de código.

La Configuración

Playwright MCP le da a Claude automatización de navegador. Lo ejecuto con Chromium sin interfaz gráfica:

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@anthropic-ai/mcp-server-playwright", "--headless"]
    }
  }
}

Ahora Claude puede navegar, hacer clic, escribir y tomar capturas de pantalla. Ve lo que los usuarios ven.

flowchart LR
    Claude([Claude Code]) -->|browser_snapshot| PW[Playwright MCP]
    PW --> Browser[Headless Chrome]
    Browser --> App[localhost:1313]
    Browser -.->|screenshot| Issue[(GitHub Issue)]
    Issue -.->|visual history| PR[Pull Request]

flowchart TB
    Claude([Claude Code]) -->|browser_snapshot| PW[Playwright MCP]
    PW --> Browser[Headless Chrome]
    Browser --> App[localhost:1313]
    Browser -.->|screenshot| Issue[(GitHub Issue)]
    Issue -.->|visual history| PR[Pull Request]

Flujo: Claude Code → Playwright MCP → Navegador → Capturas de pantalla → GitHub Issues → PR

La Matriz de Viewports

Cada cambio de UI se prueba en tres puntos de ruptura:

Claude redimensiona el navegador, toma una captura de pantalla y la sube al issue de GitHub. Tres capturas por cambio de estado. Si la navegación móvil está rota, lo veo inmediatamente—no después del despliegue.

Pruebas de Temas

El mismo patrón para modo claro y oscuro:

// Claude cambia el tema
await page.click('[data-testid="theme-toggle"]');
// Captura ambos estados

La consistencia de las variables CSS importa. Un componente que se ve bien en modo claro podría tener texto invisible en modo oscuro. Claude detecta esto al realmente mirar ambos.

Pruebas Interactivas

Aquí es donde se pone interesante. Claude no solo toma capturas—usa la UI:

• Hace clic en cada enlace de navegación, verifica el destino
• Abre el cajón móvil, verifica que se anime
• Llena formularios, los envía
• Pasa el cursor sobre elementos interactivos
• Cierra modales haciendo clic en el fondo

Cuando encuentra un error—digamos, el cajón no se cierra al tocar afuera—lo reporta, arregla el código y vuelve a probar. El ciclo de retroalimentación es ajustado.

El Issue de GitHub como Informe de Pruebas

Cada captura de pantalla se sube al issue de GitHub. El cuerpo del issue se reconstruye en cada hito:

## Estado Actual

### Desktop (1440×900)
![desktop](https://user-images.githubusercontent.com/...)

### Tablet (1024×768)
![tablet](https://user-images.githubusercontent.com/...)

### Mobile (390×844)
![mobile](https://user-images.githubusercontent.com/...)

## Lista de Verificación de Pruebas
- [x] Los enlaces de navegación funcionan
- [x] El cajón móvil abre/cierra
- [x] El cambio de tema persiste
- [ ] La validación de formularios muestra errores

El issue se convierte en un informe de pruebas vivo. Cualquiera revisando el PR puede ver exactamente qué se probó.

El Ciclo Completo

Una funcionalidad típica pasa por este ciclo:

1. Issue creado: “Agregar navegación lateral”
2. Claude implementa: Escribe el componente
3. Verificación visual: Capturas de todos los viewports
4. Pruebas interactivas: Hace clic a través de la UI
5. Error encontrado: El cajón no se cierra al hacer clic en el fondo
6. Corrección aplicada: Actualiza el manejador de clic
7. Re-prueba: Capturas frescas, todo pasando
8. PR creado: Enlaza al issue con historial visual completo

Sin paso de QA manual. Sin “se ve bien” sin realmente mirar. Claude verifica su propio trabajo.

Qué Detecta Esto

Errores reales que he visto a Claude encontrar:

• Navegación móvil oculta detrás del contenido (problema de z-index)
• Texto de botón invisible en modo oscuro (variable CSS incorrecta)
• Formulario enviándose dos veces con la tecla Enter
• Menú desplegable recortado por padre con overflow:hidden
• Estado hover atascado en dispositivos táctiles

Estos son los errores que se escapan en revisiones de código porque solo aparecen en el navegador. Claude los ve porque realmente ejecuta el código.

Cada PR ahora viene con prueba de que funciona.