QA Automation with AI

Prácticas para automatizar QA con IA (Cursor + Playwright + TypeScript) sin perder criterio, sin inflar suites y sin romper páginas que se regeneran seguido.

Objetivo: detectar regresiones reales rápido. No es cubrir cada pixel, cada copy ni cada animación.

1. Qué es y qué no es

Es:

• Un analista de QA que usa IA para escribir, extender y revisar tests más rápido.
• Un baseline estable (smoke + flujos críticos) que sobrevive a regeneraciones de UI.
• Un contrato entre diseño, desarrollo y QA: qué se afirma, con qué selectores, y qué queda fuera.

No es:

• Pedirle a la IA "haceme todos los tests" y mergear el output.
• Reemplazar exploración, review de diseño ni criterio de producto.
• Un suite pixel-perfect contra Figma en cada PR.
• Inventar reglas de negocio porque el Figma "se ve" como un botón.

La IA acelera. La responsabilidad del test sigue siendo humana.

2. Principio rector

Figma describe cómo se ve. Los behaviors describen qué tiene que pasar. Los tests afirman outcomes de usuario, no implementación.

Si solo hay Figma: se puede automatizar smoke estructural (página carga, landmarks visibles, sin overflow, sin errores de consola). No se inventan destinos de CTA, validaciones de formulario ni flujos.

Si hay behaviors (chat o doc corto): cada ítem P0/P1 in-scope mapea a un test o a un test.step.

3. Roles

• Dev (implementación UI): agrega los data-testid en el mismo cambio que el markup. Un CTA, sección o formulario sin ID no está terminado.
• QA: diseña cobertura, Page Objects, assertions y el smoke de CI. Propone los IDs faltantes; no parchea la app sin aprobación.
• IA (Cursor): genera y edita tests dentro de la carpeta e2e, siguiendo el starter y los behaviors. No corre la suite salvo pedido explícito.
• Diseño: exporta baselines visuales cuando se usa comparación con Figma. No es fuente de verdad de navegación.

Regla dura: en trabajo solo de QA, los cambios viven en e2e. Tocar la app (IDs, hooks, copy) requiere aprobación explícita.

4. Qué automatizar y en qué orden

P0, siempre:

• La página principal carga.
• Landmarks visibles: hero, nav, footer, secciones clave.
• CTAs principales visibles; la navegación se testea solo si el destino está documentado.
• Flujos críticos del producto, cuando existan: login, registro, recuperación de cuenta, checkout, envío de un formulario de negocio, o el equivalente sin el cual el usuario no puede usar el sitio. Se automatiza el camino feliz y, si hay regla documentada, el error bloqueante (credenciales inválidas, campo requerido). No se inventa el flujo: hace falta behavior o spec de producto.
• Nav principal y menú mobile, cuando los destinos están definidos.
• Sin overflow horizontal en mobile.
• Sin errores críticos de consola al cargar y al clickear CTAs.
• Sin 404/5xx relevantes en assets o APIs críticas.

P1, después:

• Accesibilidad básica con axe (violaciones serias y críticas).
• Visual regression en dos viewports (desktop y mobile), con animaciones desactivadas.
• Links rotos o crawl liviano si el sitio lo justifica.

P2, opcional:

• Presupuesto de performance (LCP, load) como señal, no como gate ciego.

Diferir por default: copy largo de marketing, timing de carousels y loaders decorativos, detalle de animaciones, internals de widgets de terceros, y comparación 100% contra Figma en CI.

Regla de tamaño: pocas pruebas de alta señal. Se profundiza solo cuando un patrón se repite en varias páginas.

5. Behaviors: la fuente de verdad del "qué"

Formato corto. Nada de Gherkin/Cucumber salvo pedido explícito.

Buenos behaviors:

• [P0] El CTA principal navega a /contact
• [P0] El formulario de newsletter muestra estado de éxito con un email válido
• Fuera de alcance: animación del hero, copy del disclaimer

Malos behaviors:

• "Clickear el botón azul del tercer div"
• "Tiene que verse lindo"
• Una lista de 20 ítems para una landing

Tope práctico: 3 a 6 ítems in-scope por feature. En el día a día alcanzan 1 o 2 bullets en el chat; se escribe un archivo cuando el flujo se reutiliza o se revisa.

Orden de prioridad para la IA: primero lo que dijo el humano en el mensaje, después los docs de behaviors, y recién al final los defaults P0/P1 del starter (sin inventar destinos).

6. Selectores: el contrato anti-churn

La UI generada por IA cambia clases, wrappers y copy. Los tests no pueden colgarse de eso.

Orden preferido: data-testid para landmarks, CTAs, cards y formularios; getByRole para interactivos con nombre accesible estable; getByLabel para campos con label estable.

Prohibido como locator primario: clases hasheadas o utilitarias como identidad, wrappers de animación, paths profundos del DOM, y copy largo de marketing salvo que el copy sea la regla de negocio.

Naming de data-testid: kebab-case, describe propósito y no estilo. Bien: cta-primary, section-product-overview, form-email. Mal: cta-blue-button, div-hero-gsap.

Si falta un ID crítico, se propone el mínimo necesario y se espera aprobación. No se inventa un selector CSS frágil para salir del paso.

7. Cómo pedirle trabajo a la IA

Un prompt vago produce tests vagos. Un prompt con límites produce un baseline usable.

Incluir siempre: el starter y las reglas del repo como fuente de verdad, los behaviors in-scope y lo que queda fuera, "no inventar destinos ni reglas", "no tocar la app sin aprobación", "no correr Playwright hasta que lo pida", y pedir al final el comando exacto sugerido para esperar el OK.

No pedir: 100% de coverage, tests de cada breakpoint y cada hover, que la IA "arregle la app" para que el test pase, ni subir timeouts globales para tapar flakiness.

Después de generar código, el QA revisa: si cada test nombra la regresión que evita, si hay sleeps o waitForTimeout, si hay asserts sobre clases CSS o estructura de React, si se reutilizan Page Objects y utils en vez de duplicar locators, y si el test visual está en el proyecto correcto con animaciones estabilizadas.

8. Definition of Done de una página hecha con IA

Una página no está terminada solo porque el Figma está implementado.

• Behaviors in-scope cubiertos, si existían
• Smoke pasa
• CTAs verificados: visibilidad siempre, navegación solo con destino definido
• Responsive verificado y sin overflow en mobile
• Sin errores críticos de consola
• Sin 404/5xx relevantes en recursos críticos
• Axe limpio en violaciones serias y críticas
• Snapshot visual revisado y aprobado, si se usa
• data-testid requeridos incluidos en el mismo PR de UI, o gaps aprobados y documentados
• Starter del proyecto actualizado si apareció un patrón reutilizable

9. Comparación visual contra Figma

Sirve para detectar gaps grandes de layout. No reemplaza la review humana de diseño.

Se captura al mismo viewport que el frame exportado, con animaciones desactivadas y contenido dinámico congelado, y con una tolerancia de diferencia de pixeles. Un fail es una señal para revisar, no un veredicto de que el diseño está mal.

Se empieza con baseline manual (PNG exportado por diseño) y se pasa a la API de Figma recién cuando los node IDs y la ownership del diseño son estables. Los tokens nunca se commitean.

El visual queda fuera del CI por default por fragilidad de sistema operativo y entorno: se corre en local y las baselines se actualizan a propósito, nunca "para que pase".

10. Flakiness, CI y ética de mocks

• No inflar timeouts globales.
• No usar esperas arbitrarias.
• No mockear ni bypassear comportamiento real sin declararlo en el PR.
• No cambiar validaciones, copy ni lógica de producto para facilitar un test.
• En CI corre el smoke P0 en PR y en main, cuando el equipo activa el gate. Visual y accesibilidad profunda quedan en local o en jobs opt-in.
• Los tests se corren cuando alguien lo pide. Lint y typecheck sí; la suite completa no por default.

11. Anti-patrones (red flags en review)

• Suite enorme el día uno: se pudre con la primera regeneración de UI.
• Locators basados en copy o clases: falsos negativos constantes.
• Destinos de CTA inventados: tests en verde que no reflejan el producto.
• La IA modificó la app "porque faltaba un id": scope creep y tests acoplados a un parche.
• Sleeps para esperar animaciones: flakiness y suites lentas.
• Visual en CI sin estabilizar: ruido, y el equipo termina ignorando los fails.
• "Lo escribió la IA, debe estar bien": nadie es dueño del riesgo.

12. Flujo recomendado por proyecto

1. El dev implementa la UI con sus data-testid, usando el contrato compartido entre app y e2e.
2. QA o PM pegan 3 a 6 behaviors, o confirman que solo se hace smoke estructural.
3. La IA genera o extiende tests en e2e, con Page Objects y utils, no specs sueltos.
4. Un humano revisa y corre el comando más chico posible (smoke o un solo spec).
5. Se generan las baselines visuales en local cuando el layout está estable.
6. Se activa el smoke en CI cuando el repo deja de ser un prototipo que cambia todos los días.

La IA escribe el test. El equipo decide qué es una falla de producto. Automatizamos lo que un usuario nota que se rompió, con selectores que sobreviven al próximo regenerate.

Stack default: Playwright + TypeScript + Page Object Model. El detalle de carpetas, scripts y convenciones de IDs vive en el documento técnico del starter del repo.