DeanMcCoppin/browser-qa

Browser QA — Pruebas Visuales Automatizadas e Interacción

Cuándo Usarlo

• Después de desplegar una funcionalidad en staging/vista previa
• Cuando necesites verificar el comportamiento de la UI en varias páginas
• Antes de enviar cambios — confirmar que los diseños, formularios e interacciones realmente funcionan
• Al revisar PRs que afectan código de frontend
• Auditorías de accesibilidad y pruebas responsive

Cómo Funciona

Utiliza el MCP de automatización del navegador (claude-in-chrome, Playwright o Puppeteer) para interactuar con páginas en vivo como un usuario real.

Seguridad primero — radio de explosión (ejecutar solo lectura por defecto)

Browser QA maneja autenticación real y recorridos de usuario reales, por lo que el radio de explosión debe tratarse explícitamente. Por defecto: solo lectura: nunca ejecutar un recorrido mutante (compra, pago, eliminación, actualización masiva) contra una URL de producción — exigir un consentimiento explícito y una URL de staging/vista previa. Usar credenciales de prueba sembradas, nunca inicios de sesión reales de producción, y redactar credenciales/tokens/PII antes de guardar cualquier captura de pantalla.

Fase 1: Prueba de Humo

1. Navegar a la URL objetivo
2. Verificar errores de consola (filtrar ruido: analítica, terceros)
3. Verificar que no haya 4xx/5xx en las solicitudes de red
4. Capturar la parte visible en escritorio + viewport móvil
5. Comprobar Core Web Vitals: LCP < 2.5s, CLS < 0.1, INP < 200ms
   (INP reemplazó a FID en marzo de 2024; umbrales según web.dev)

Fase 2: Prueba de Interacción

1. Hacer clic en cada enlace de navegación — verificar que no haya enlaces rotos
2. Enviar formularios con datos válidos — verificar estado de éxito
3. Enviar formularios con datos inválidos — verificar estado de error
4. Probar flujo de autenticación: iniciar sesión → página protegida → cerrar sesión (solo credenciales de prueba, nunca producción)
5. Probar recorridos críticos de usuario (compra, incorporación, búsqueda)
   — solo lectura por defecto; solo ejercitar recorridos mutantes contra staging
     con consentimiento explícito (ver "Seguridad primero" arriba)

Fase 3: Regresión Visual

1. Capturar páginas clave en 3 puntos de interrupción (375px, 768px, 1440px)
2. Comparar con capturas de línea base comprometidas
   — sin línea base ⇒ reportar INCONCLUSIVO, nunca un PASO silencioso
3. Señalar desplazamientos de diseño > 5px, elementos faltantes, desbordamientos
4. Comprobar modo oscuro si aplica

Fase 4: Accesibilidad

1. Ejecutar axe-core o equivalente en cada página
2. Señalar violaciones WCAG 2.2 AA (contraste, etiquetas, orden de enfoque)
3. Verificar que la navegación por teclado funcione de extremo a extremo
4. Comprobar los puntos de referencia del lector de pantalla

Nota: axe-core cubre automáticamente aproximadamente el 30–40% de WCAG. Una ejecución limpia es necesaria, no suficiente — la navegación por teclado, el orden de enfoque y una prueba con lector de pantalla aún requieren una comprobación manual. No reportar "accesible" solo a partir de una prueba automatizada.

Formato de Salida

## Informe QA — [URL] — [marca de tiempo]

### Prueba de Humo
- Errores de consola: 0 críticos, 2 advertencias (ruido de analítica)
- Red: todo 200/304, sin fallos
- Core Web Vitals: LCP 1.2s ✓, CLS 0.02 ✓, INP 89ms ✓

### Interacciones
- [✓] Enlaces de navegación: 12/12 funcionando
- [✗] Formulario de contacto: falta estado de error para email inválido
- [✓] Flujo de autenticación: inicio/cierre de sesión funcionando

### Visual
- [✗] Sección hero se desborda en viewport de 375px
- [✓] Modo oscuro: todas las páginas consistentes

### Accesibilidad
- 2 violaciones AA: falta texto alternativo en imagen hero, bajo contraste en enlaces del pie de página

### Veredicto: SHIP WITH FIXES (2 problemas, 0 bloqueantes)
# veredicto ∈ SHIP / SHIP WITH FIXES / DO NOT SHIP; usar INCONCLUSIVO si no hay línea base visual

Integración

Funciona con cualquier herramienta de navegador que tenga la sesión: Claude in Chrome (mcp__claude-in-chrome__*), un servidor MCP de Playwright, o un script plano de Playwright ejecutado desde la terminal. Si no hay ninguna disponible, indícalo y ofrece un script de Playwright en lugar de adivinar resultados.

Para comprobaciones repetibles, convierte los hallazgos en pruebas con e2e-testing; para profundidad en accesibilidad, consulta accessibility.