Testing con IA: generación de tests y self-healing locators, hasta dónde confiar

Durante años, “IA aplicada a testing” significó sobre todo herramientas de grabar-y-reproducir con un poco de machine learning para tolerar cambios menores en el DOM. Lo que ha cambiado en los últimos meses es de otra naturaleza: agentes basados en LLMs que exploran una aplicación real, escriben un plan de pruebas, generan el código de test y, cuando algo se rompe, deciden por su cuenta cómo repararlo. Microsoft ha llevado esa idea al propio Playwright con sus Test Agents, y el ecosistema de servidores MCP alrededor del navegador ha convertido “que un agente maneje el navegador” en una pieza de infraestructura más.

La pregunta que importa no es si esto funciona —funciona, y bastante bien en el caso feliz—, sino cuánta autonomía le puedes dar sin dejar de saber qué está probando tu suite.

Qué hace realmente Playwright con IA

Conviene separar dos piezas que suelen mezclarse en el marketing: el protocolo MCP y los Test Agents.

Playwright MCP (@playwright/mcp, mantenido por Microsoft) es un servidor que expone el control del navegador a cualquier cliente compatible con Model Context Protocol. Su decisión de diseño más relevante es que no opera sobre capturas de pantalla interpretadas por un modelo de visión, sino sobre el árbol de accesibilidad de la página: la misma estructura semántica (roles ARIA, nombres accesibles, jerarquía) que ya usan los locators recomendados de Playwright (getByRole, getByLabel). Esto elimina una capa entera de ambigüedad: el agente no tiene que “adivinar” dónde está el botón mirando píxeles, lee directamente qué es cada elemento y para qué sirve.

Sobre esa base, Playwright define tres agentes especializados que puedes invocar de forma independiente o encadenada:

• Planner explora la aplicación en vivo (a partir de un test semilla que hace de setup) y produce un plan en Markdown: escenarios numerados, pasos y resultado esperado.
• Generator toma ese plan y lo convierte en archivos .spec.ts ejecutables, verificando selectores y aserciones contra la aplicación real mientras genera el código, no a ciegas.
• Healer entra en acción cuando un test falla: repite los pasos, inspecciona el estado actual de la UI y propone un parche —normalmente un locator distinto o un ajuste de espera— reejecutando hasta que el test pasa o concluye que el fallo es real y lo marca para revisión.

graph LR
A[Test semilla] --> B[Planner: explora la app]
B --> C[Plan.md: escenarios y pasos]
C --> D[Generator: escribe el .spec.ts]
D --> E[Suite Playwright normal]
E -->|falla| F[Healer: diagnostica y repara]
F --> E
E -->|pasa| G[CI]

Se activan con npx playwright init-agents --loop=<vscode|claude|codex|opencode>, lo que genera las definiciones de agente (instrucciones + herramientas MCP) para el entorno que uses. El resultado final, en ambos casos —Generator y Healer—, son archivos de test corrientes en tu repositorio: no hay una capa propietaria oculta, corren con tu configuración y tu CI de siempre. Si ya conoces cómo estructurar una suite de Playwright mantenible, estos agentes operan dentro de las mismas convenciones que describimos en la guía completa de testing E2E con Playwright: locators semánticos, fixtures y auto-waiting no desaparecen, se generan automáticamente en vez de escribirse a mano.

Los beneficios reales

Antes de entrar en los riesgos, hay que reconocer lo que sí funciona bien:

• Arrancar cobertura desde cero es mucho más rápido. Escribir el primer smoke test de un flujo de checkout completo a mano puede llevar una hora entre exploración manual y ajuste de selectores. El Planner + Generator lo reduce a minutos, con locators ya alineados a las buenas prácticas de accesibilidad.
• El mantenimiento reactivo baja de forma medible. Cuando un rediseño cambia clases CSS o reordena el DOM sin alterar el comportamiento, el Healer resuelve buena parte de esos fallos sin intervención humana, liberando tiempo de ingeniería que antes se iba en “arreglar selectores rotos” en vez de en escribir tests nuevos.
• Baja la barrera de entrada. Un desarrollador que no vive dentro de Playwright a diario puede describir un flujo en lenguaje natural y obtener un test razonable como punto de partida, en vez de partir de una plantilla en blanco.

Ninguno de estos beneficios es hipotético: son la razón por la que equipos de QA que antes dedicaban gran parte del sprint a mantenimiento de selectores están redirigiendo ese tiempo a diseñar mejores escenarios.

El problema del “false heal”

Aquí está el riesgo que de verdad importa, y tiene nombre propio en la literatura reciente sobre el tema: el false heal. Ocurre cuando el Healer consigue que un test vuelva a pasar, pero cambiando lo que el test verifica de verdad —no arreglando el problema original—. El pipeline se pone en verde; la garantía que ese test daba, no.

Un benchmark reciente que evaluó 136 perturbaciones de interfaz sobre dos aplicaciones encontró que la reparación automática sin supervisión acertó sobre el elemento equivocado aproximadamente una de cada cuatro veces en las condiciones probadas. El test seguía “pasando”, pero estaba haciendo clic en un control distinto o comprobando un elemento que no era el que originalmente se quería validar.

El efecto agregado se ve en simulaciones de gobernanza en entornos regulados: un pipeline de self-healing sin controles redujo las horas de mantenimiento de selectores de 180 a 99 al mes en un periodo de doce meses, pero cuadriplicó los incidentes de erosión de cobertura, de 7 a 28. Buena parte de ese “ahorro” no era eficiencia real: eran defectos que dejaron de detectarse porque el test que debía atraparlos ya no comprobaba lo que se suponía que comprobaba.

La falsa sensación de cobertura

El false heal es el caso más visible, pero el problema de fondo es más general: un test generado o reparado por IA que pasa no es evidencia de que el comportamiento sea correcto, es evidencia de que el test, tal como quedó escrito, no detectó nada raro. Son afirmaciones distintas, y confundirlas es exactamente lo que produce la falsa sensación de cobertura.

Esto pasa de dos formas concretas con estas herramientas:

1. El Generator documenta el comportamiento actual, no el esperado. Si al generar el test la aplicación ya tenía un bug sutil —un mensaje de error que no debería aparecer, un campo que no se limpia tras enviar un formulario—, el agente puede aceptar ese estado como “correcto” porque es lo que observa, y escribir una aserción que lo confirma. El test pasa desde el primer commit, pero está blindando un defecto en vez de detectarlo.
2. Las aserciones generadas tienden a ser superficiales por defecto. Es más fácil para un agente comprobar que un elemento “es visible” que verificar que contiene el valor de negocio correcto tras una operación concreta. Una suite generada mayoritariamente así puede tener un número de tests y un “porcentaje de flujos cubiertos” que se ve bien en un dashboard, sin que eso se traduzca en detección real de regresiones.

El problema de fondo —tests que pasan sin verificar nada relevante— no es exclusivo de la IA: es exactamente lo que mide una técnica bastante más antigua y ajena a los LLMs, el mutation testing, que introduce fallos deliberados en el código para comprobar si tus tests realmente los detectan. Aplicarlo sobre una suite generada por IA es, hoy, una de las formas más objetivas de saber si esa suite vale lo que promete o solo lo parece.

Cómo usarlas sin perder el control de la suite

Ninguna de las recomendaciones siguientes consiste en “no usar estas herramientas”. Consiste en no tratarlas como una caja negra de confianza total desde el primer día:

• Trata cada test generado como una propuesta de pull request, no como un hecho consumado. El Generator produce código real en tu repositorio: revísalo con el mismo criterio que aplicarías a un test escrito por un compañero junior. Presta atención especial a qué aserciones hace, no solo a si compila y pasa.
• Separa el “heal” automático por riesgo. Un cambio de locator que sigue apuntando al mismo rol semántico (por ejemplo, el mismo botón tras renombrar una clase CSS) es razonablemente seguro de aceptar sin fricción. Un cambio que salta a un elemento distinto, cambia el flujo de navegación o modifica una aserción merece revisión humana antes de mezclarse en main.
• Mide la tasa de false heal, no solo la de éxito. Aunque sea sobre una muestra pequeña de tests críticos, revisa manualmente de vez en cuando si un heal reciente sigue verificando lo mismo que el test original. Es la única forma de detectar el problema antes de que se acumule en silencio.
• Haz que las reparaciones sean observables y reversibles. Cada cambio automático debería quedar en su propio commit o diff auditable, vinculado al fallo que lo disparó, nunca aplicado de forma silenciosa sobre el historial existente.
• Reserva la autonomía total para tests de bajo riesgo. Smoke tests, flujos exploratorios o cobertura adicional “de más” son buenos candidatos para dejar que el Healer actúe sin supervisión constante. Los tests que protegen checkout, pagos, autenticación o cualquier flujo con impacto económico o de seguridad directo deberían pasar siempre por revisión humana antes de dar por buena una reparación.

La conclusión práctica no es “desconfía de la IA en testing”, es la misma disciplina que ya deberías aplicar a cualquier test escrito por humanos: nadie da por buena una suite solo porque está en verde. Los test agents de Playwright son, en el caso feliz, un multiplicador real de productividad para construir cobertura E2E. En el caso menos feliz, son una forma muy eficiente de generar una suite grande que no protege nada. La diferencia entre uno y otro no la pone la herramienta, la pone el proceso de revisión que pongas alrededor.