IA agéntica en QA: qué funciona de verdad y qué no — Techsinmiedo

La IA que autocompletaba tests ya la conocemos. Lo que cambió este año es otra cosa: agentes que corren la suite, leen por qué falló, proponen el arreglo y te dejan un pull request esperando. Llevo unos meses trabajando así y quiero contarte qué funciona de verdad, qué no, y dónde está la línea que yo no cruzo.

Autocompletar no es lo mismo que actuar

Hasta hace poco, usar IA en QA era esto: le pegabas un requisito, te devolvía diez casos de prueba, tú los revisabas y los escribías. Útil, pero el trabajo seguía siendo tuyo. La herramienta sugería; tú ejecutabas.

Un agente hace el ciclo completo. Le dices «la suite de checkout está fallando en CI, averigua por qué», y él ejecuta los tests, lee la traza, abre los archivos implicados, encuentra que el selector cambió tras un rediseño, lo arregla, vuelve a correr la suite para comprobarlo, y te deja el cambio listo para revisar.

La diferencia no es de velocidad. Es de quién sostiene el hilo. Antes, cada paso volvía a ti. Ahora tú entras al principio, a definir qué se busca, y al final, a decidir si eso se queda.

Dónde me ha servido de verdad

No voy a darte la lista de promesas de las páginas de producto. Estos son los tres sitios donde lo he visto rendir en trabajo real:

1. Tests rotos por cambios de interfaz

Es el caso más aburrido y el que más tiempo consume. Alguien renombra un componente, cambia una clase, mueve un botón — y quince tests se caen a la vez sin que haya un solo bug de producto detrás.

Un agente es bueno exactamente aquí: el problema está contenido, la evidencia es la traza del fallo, y la comprobación de que lo arregló es que la suite vuelve a pasar. Le doy el reporte del CI y me devuelve los selectores actualizados.

Ojo con esto

Si un test se arregla solo cada vez que alguien toca la interfaz, en algún momento dejas de mirar por qué se rompió. Y a veces se rompió porque el producto sí cambió de comportamiento. Revisa el diff, no solo el semáforo verde.

2. Traducir una suite de una herramienta a otra

Migrar de Selenium a Playwright, o de Cypress a Playwright, es trabajo mecánico y voluminoso: cientos de archivos con la misma transformación repetida. Un agente que puede leer el repositorio entero, entender tus convenciones y aplicar el cambio archivo por archivo hace en una tarde lo que antes eran semanas.

Aquí el truco está en darle el contexto correcto: tus Page Objects, tu estructura de carpetas, un ejemplo ya migrado a mano. Sin eso escribe código que funciona pero que no se parece al tuyo, y acabas con dos estilos conviviendo en el mismo repositorio.

3. Investigar tests inestables

Este es el que más me sorprendió. Un test que falla una de cada ocho veces es un dolor clásico de QA: reproducirlo cuesta más que arreglarlo. Un agente puede correrlo cincuenta veces seguidas, guardar las trazas de las que fallan, comparar y decirte «falla cuando la petición de sesión tarda más de 800 ms y el test no espera a que el spinner desaparezca».

Eso es paciencia mecánica, que es justo lo que a un humano se le agota.

Dónde no ha funcionado

Y ahora la parte que casi nadie publica.

Decidir qué vale la pena probar. Le puedes dar un requisito y te genera veinte casos. Los cinco obvios están perfectos. Los que dependen del negocio —qué pasa con un usuario que pertenece a dos organizaciones, qué pasa si el cupón caduca entre que se aplica y se paga— sencillamente no aparecen, porque no están escritos en ninguna parte. Viven en la cabeza de quien conoce el producto.

Asserts que no verifican nada. Es el fallo más peligroso, porque el resultado se ve bien: la suite pasa, el reporte está verde y nadie mira más. Pero el test comprueba que la página cargó, no que el importe sea correcto. Un test que siempre pasa es peor que no tener test, porque genera confianza donde no la hay.

Saber cuándo parar. Un agente al que le dices «arregla los tests que fallan» los va a arreglar. Todos. Incluso el que estaba fallando porque encontró un bug de verdad.

La prueba que le hago a todo test generado

Rompo la aplicación a propósito, justo en lo que ese test debería detectar, y compruebo que falla. Si pasa igual, no está verificando nada. Es lo mismo que hago con un test escrito a mano, solo que aquí no me lo salto nunca.

Cómo empezar sin romperlo todo

Si quieres meter esto en tu trabajo, no empieces por la suite crítica. Este es el orden que a mí me funcionó:

Dale contexto antes que tareas. Un archivo con tus convenciones: qué selectores usáis, cómo se llaman los Page Objects, dónde viven los datos de prueba, qué no se toca nunca. Sin esto, todo lo demás sale a medias.
Empieza por lo reversible. Tests rotos por selectores, migraciones, investigación de inestables. Nada que decida qué se prueba.
Que el resultado sea siempre un pull request. Nunca un push directo. Todo lo que hace pasa por revisión humana, igual que el código de cualquier persona del equipo.
Escribe las reglas del equipo. Qué datos nunca salen (código de cliente, credenciales, datos reales de usuarios) y qué siempre se revisa a mano. Ponlo por escrito antes de que haga falta.
Mide si de verdad ayudó. Tiempo de la regresión antes y después, tests inestables al mes, bugs que llegaron a producción. Si no mejora ninguno, estás automatizando el trabajo equivocado.

La pregunta incómoda

Cuando un agente sube un arreglo y ese arreglo esconde un bug que llega a producción, ¿de quién es el error?

Del equipo. Siempre. La herramienta no firma nada.

Por eso el pull request no es burocracia: es el sitio donde una persona pone su nombre. Si el flujo de tu equipo permite que algo llegue a la rama principal sin que nadie lo haya leído, el problema no es la IA — es que quitaste la revisión y no lo dijiste en voz alta.

Entonces, ¿reemplaza a los QA?

Reemplaza la parte mecánica de nuestro trabajo, y esa parte es grande. Si lo que haces todo el día es ejecutar casos de regresión a mano y arreglar selectores, sí: eso se va a automatizar, y antes de lo que parece.

Lo que no reemplaza es el criterio. Decidir qué es riesgo y qué no. Entender por qué a este negocio le duele que falle esto y no aquello. Preguntar en un refinamiento lo que nadie pensó. Eso sigue siendo nuestro, y ahora vale más, no menos, porque es lo único que no se puede generar.

Mi conclusión después de estos meses: un QA con criterio y agentes rinde muchísimo más que uno sin ellos. Y un agente sin alguien con criterio detrás produce una suite verde que no prueba nada. Elige de qué lado quieres estar.

Para empezar esta semana

Coge un solo test inestable de tu proyecto —ese que todos ignoran— y pídele a un agente que lo corra cincuenta veces y te diga cuándo falla. Es una tarea acotada, sin riesgo, y en una hora vas a saber si esto te sirve o no.

Si te quedaste con ganas de más, en la Ruta QA hay un plan de 4 semanas según de dónde partas, y en QAConia trabajamos esto con proyectos reales.

El miedo es el mapa. 🌸