La IA puede ayudarte muchísimo en QA Automation.
Pero también puede hacerte automatizar basura con más confianza.
Y ese es el peligro.
Porque cuando una respuesta viene bien escrita, con código prolijo y nombres que parecen profesionales, es fácil bajar la guardia. Es fácil pensar: “esto debe estar bien”.
No necesariamente.
La IA no entiende tu producto como vos. No conoce el contexto del equipo. No sabe qué flujo le duele al usuario si falla. No sabe qué parte del negocio no puede romperse un viernes a la tarde.
La IA puede proponer.
El criterio lo tenés que poner vos.
IA no reemplaza saber testear
Hay una fantasía bastante peligrosa dando vueltas: que con IA ya no hace falta saber tanto, porque la herramienta te genera los tests.
Y pará un poco.
Que una IA pueda escribir un test en Playwright, Cypress o Selenium no significa que ese test tenga valor.
Puede estar bien escrito y validar algo irrelevante. Puede tener buenos selectores y cubrir un flujo que nadie usa. Puede pasar siempre y no detectar el error importante. Puede fallar cada dos corridas porque no entendió los datos, los estados o las dependencias del sistema.
Eso no es calidad.
Eso es código con apariencia de test.
Automatizar no es producir archivos .spec. Automatizar es convertir conocimiento del producto en verificaciones confiables.
Y para eso necesitás criterio.
Dónde sí me sirve la IA en QA Automation
Usada bien, la IA es una herramienta tremenda. No para apagar la cabeza, sino para pensar mejor y más rápido.
A mí me sirve sobre todo en estas partes.
1) Para explorar escenarios posibles
Cuando tengo una funcionalidad nueva, puedo pedirle que me ayude a pensar casos:
- camino feliz,
- errores esperados,
- permisos,
- límites,
- estados raros,
- datos inválidos,
- combinaciones que normalmente se me podrían escapar.
Pero ojo: esa lista no es una verdad revelada.
Es materia prima.
Después tengo que revisar qué aplica al producto real, qué es importante, qué es ruido y qué riesgo estoy cubriendo con cada caso.
Si copiás todos los escenarios que te propone una IA sin filtrar, no estás diseñando una estrategia de testing. Estás juntando tareas.
2) Para revisar cobertura
También sirve para hacer una segunda pasada sobre lo que ya pensaste.
Le podés decir: “estos son los escenarios que quiero automatizar, estos son los riesgos principales, ¿qué huecos ves?”.
Ahí la IA puede ayudarte a detectar puntos ciegos.
Pero la decisión final sigue siendo tuya.
Porque cobertura no es cantidad de tests. Cobertura es confianza sobre los riesgos correctos.
Y eso no sale de una respuesta automática. Sale de entender el negocio, el producto, el usuario y el costo de falla.
3) Para mejorar código de tests
La IA puede ayudar mucho a refactorizar pruebas:
- nombres más claros,
- assertions más expresivas,
- pasos repetidos,
- fixtures,
- Page Objects,
- helpers,
- estructura de carpetas,
- legibilidad del reporte.
Pero hay que tener cuidado con algo: una IA suele optimizar forma antes que intención.
Te puede dejar un test más lindo, pero no necesariamente más útil.
Por eso, antes de aceptar un refactor, me pregunto:
- ¿el test sigue validando el comportamiento importante?
- ¿la falla va a ser más fácil de diagnosticar?
- ¿el cambio reduce duplicación real o es abstracción por deporte?
- ¿el reporte queda más claro para alguien que no escribió el test?
Porque si el test queda más elegante pero menos entendible, perdiste.
4) Para detectar smells
Acá la IA puede ser muy buena si le das contexto.
Le podés pasar un test y pedirle que busque señales de fragilidad:
- waits fijos,
- dependencias de orden,
- datos compartidos,
- asserts pobres,
- demasiadas responsabilidades en un solo test,
- selectores frágiles,
- acoplamiento al texto visual cuando no corresponde,
- setup poco claro.
Eso suma.
Pero otra vez: no alcanza con que la IA marque cosas. Hay que entender por qué eso es un problema.
Si no entendés el concepto, solo vas a aplicar recomendaciones como checklist. Y los checklists sin criterio son otra forma de automatizar mal.
El prompt no salva una mala estrategia
Podés escribir el mejor prompt del mundo.
Si no sabés qué querés validar, la respuesta va a salir floja.
La calidad de lo que pedís depende de la calidad de tu pensamiento previo.
Antes de pedirle a la IA que escriba un test, conviene tener claro:
- qué comportamiento importa,
- qué riesgo querés cubrir,
- qué dato necesitás,
- qué precondición tiene sentido,
- qué evidencia debería quedar si falla,
- qué parte vale automatizar y cuál no.
Eso es trabajo de QA.
La IA puede acelerar ese trabajo, discutirlo con vos, ordenarlo, cuestionarlo o ayudarte a pasarlo a código.
Pero no debería reemplazarlo.
Porque cuando arrancás por la herramienta antes de entender el riesgo, terminás midiendo éxito por cantidad de tests generados.
Y ya sabemos cómo termina eso: suites enormes, lentas, frágiles y con poca confianza real.
Una forma sana de usar IA
Para mí, un buen flujo sería algo así:
- Primero entiendo la funcionalidad y el riesgo.
- Después diseño escenarios con mi criterio.
- Uso IA para desafiar esos escenarios y encontrar huecos.
- Priorizo qué vale automatizar.
- Recién ahí pido ayuda para implementar o refactorizar.
- Reviso el resultado como si lo hubiera escrito otra persona del equipo.
- Ejecuto, observo fallas y ajusto.
Ese orden importa.
Porque si empezás pidiendo código, la conversación queda condicionada por una solución antes de entender el problema.
Y en testing eso es peligroso.
Un test no vale por existir. Vale por la confianza que aporta.
La IA amplifica tu nivel
Esta es la parte incómoda.
La IA no te vuelve automáticamente mejor QA Automation.
Amplifica lo que ya traés.
Si tenés criterio, te ayuda a ir más rápido, revisar mejor, detectar huecos y escribir tests más mantenibles.
Si no tenés criterio, te ayuda a producir más ruido con apariencia profesional.
Por eso no compro la idea de “con IA ya no hace falta aprender tanto”.
Al revés.
Hace falta aprender más fundamentos: testing, producto, riesgo, arquitectura, datos, diseño de escenarios, debugging, comunicación y mantenibilidad.
Porque ahora generar código es más fácil.
Lo difícil es saber si ese código merece existir.
No apagues la cabeza
Usá IA.
Usala para pensar escenarios, revisar cobertura, detectar smells, refactorizar tests y acelerar partes mecánicas.
Pero no le entregues el volante.
La IA no se hace cargo cuando un test miente. No explica en la daily por qué el pipeline está rojo. No entiende el impacto de liberar una regresión. No prioriza por vos cuando hay poco tiempo y mucho riesgo.
Eso sigue siendo responsabilidad humana.
La herramienta ejecuta, propone y acelera.
El criterio decide.
Y si apagás el criterio, no estás haciendo QA Automation moderno.
Estás automatizando a ciegas, pero con mejor autocomplete.