QA agéntico: qué es, la tendencia y lo que se viene en el testing con agentes de IA

Hola a todos. Si trabajás en QA, seguramente en los últimos meses escuchaste la palabra "agéntico" más veces de las que podés contar. Aparece en charlas, en ofertas laborales, en lanzamientos de herramientas y en cada posteo de LinkedIn sobre el futuro del testing. Y como pasa con toda palabra de moda, muchas veces se usa sin explicar bien qué significa.

En este artículo quiero ordenar el tema con calma: qué es el QA agéntico, en qué se diferencia de la automatización que ya conocemos y de los asistentes de IA tipo chat, cómo funciona un agente por dentro, qué tareas puede hacer hoy de verdad, cuáles son sus riesgos y, sobre todo, qué cambia para nosotros como QAs. Al final te dejo una guía para empezar a probarlo sin morir en el intento.

Spoiler: no, la IA no viene a reemplazar al QA. Pero sí está cambiando mucho la forma en que trabajamos, y conviene entenderlo antes de que nos pase por arriba.

¿Qué es el QA agéntico?

El QA agéntico (en inglés, agentic QA o agentic testing) es una forma de hacer aseguramiento de la calidad en la que agentes de inteligencia artificial ejecutan tareas de testing de manera autónoma o semiautónoma: entienden un objetivo, deciden qué pasos seguir, usan herramientas para llevarlos a cabo, observan el resultado y ajustan su plan sobre la marcha.

La palabra clave es agente. Un agente de IA no es simplemente un modelo de lenguaje que responde preguntas. Es un sistema que combina varias piezas:

• Un modelo de lenguaje (LLM) que razona, interpreta instrucciones y decide qué hacer.
• Herramientas que le permiten actuar sobre el mundo: abrir un navegador, hacer clic, enviar una request a una API, leer un archivo, correr un comando, consultar una base de datos o crear un ticket en Jira.
• Un ciclo de trabajo en el que el agente piensa, actúa, observa lo que pasó y vuelve a pensar, hasta cumplir el objetivo o darse cuenta de que no puede.
• Memoria y contexto: información sobre el proyecto, los requisitos, la historia de ejecuciones anteriores y las reglas del equipo.
• Un objetivo, que en vez de ser una secuencia de pasos fija es algo como "verificá que un usuario nuevo pueda registrarse y completar su primera compra".

Esa última diferencia es la más importante. En la automatización tradicional nosotros le decimos a la máquina cómo hacer cada cosa: "buscá el elemento con este selector, escribí este texto, hacé clic acá, verificá que aparezca este mensaje". En el enfoque agéntico le decimos qué queremos lograr, y el agente se encarga de descubrir el cómo, adaptándose si la pantalla cambió, si apareció un popup inesperado o si el botón ahora se llama distinto.

Para que quede claro desde el principio: QA agéntico no significa "QA sin humanos". En la práctica, los mejores resultados aparecen cuando el agente hace el trabajo repetitivo y pesado, y el QA define la estrategia, revisa lo que produce el agente, toma decisiones y aporta el criterio que la máquina todavía no tiene. Es lo que en la industria se llama human-in-the-loop: el humano sigue en el circuito, pero en un rol distinto.

De los scripts a los agentes: un poco de historia

Para entender por qué el QA agéntico es un cambio grande, sirve mirar cómo evolucionó el testing en las últimas décadas. Simplificando bastante, podemos pensar en cinco etapas.

1. Testing manual

Todo empezó con personas ejecutando casos de prueba a mano, siguiendo un documento o una planilla. El testing manual sigue siendo fundamental, sobre todo para el testing exploratorio, la usabilidad y todo lo que requiere criterio humano. Pero escala mal: probar lo mismo en cada release es lento, caro y aburrido, y el aburrimiento es enemigo de la atención.

2. Automatización con scripts

Después llegaron herramientas como Selenium, y más tarde Cypress y Playwright, que permiten escribir código que ejecuta las pruebas. Esto revolucionó las regresiones: lo que antes llevaba días ahora corre en minutos dentro de un pipeline de CI/CD. El problema es que los scripts son frágiles. Si cambia un selector, un texto o el orden de una pantalla, la prueba se rompe aunque la funcionalidad siga andando bien. Cualquiera que haya mantenido una suite grande sabe que una parte importante del tiempo se va en arreglar pruebas, no en encontrar bugs.

3. Frameworks, BDD y low-code

Para hacer la automatización más mantenible y accesible aparecieron patrones como Page Object, enfoques como BDD con Cucumber y Gherkin, y herramientas low-code que graban las acciones del usuario. Ayudaron muchísimo a ordenar el trabajo y a acercar la automatización a perfiles menos técnicos, pero la lógica de fondo seguía siendo la misma: pasos definidos de antemano, ejecutados al pie de la letra.

4. IA como asistente

Con la llegada de los modelos de lenguaje modernos, empezamos a usar la IA como copiloto: le pedimos a un chat que nos genere casos de prueba a partir de una historia de usuario, que nos escriba un script, que nos explique un error o que nos arme datos de prueba. Es un salto enorme en productividad, pero el humano sigue haciendo de intermediario en todo: copia, pega, ejecuta, revisa, vuelve a preguntar.

5. IA como agente

La etapa actual es la del agente. En vez de devolvernos texto para que nosotros lo usemos, el agente actúa directamente: lee la historia de usuario, genera los casos, abre el navegador, ejecuta las pruebas, junta la evidencia, analiza los fallos y nos deja un reporte. Nosotros pasamos de ejecutar a supervisar, de escribir cada paso a definir objetivos y criterios de calidad.

Ninguna etapa reemplazó por completo a la anterior. Hoy conviven el testing manual, los scripts, BDD, los asistentes y los agentes. La clave está en saber qué herramienta usar para cada problema.

Asistente de IA vs. agente de IA

Esta es una confusión muy común, así que vale la pena detenerse. No todo lo que tiene IA es agéntico. Muchas herramientas que se venden como "agentes" en realidad son asistentes con buen marketing. Esta tabla resume las diferencias principales:

Una forma sencilla de distinguirlos: si la herramienta necesita que vos hagas de puente entre lo que te dice y lo que pasa en el sistema, es un asistente. Si puede interactuar con el sistema por sí misma, observar resultados y decidir el siguiente paso, es un agente.

Ojo, que un asistente no es "peor". Para muchas tareas, como pensar escenarios, revisar la redacción de un caso o entender un concepto, un asistente es perfecto y más barato. El agente brilla cuando la tarea tiene muchos pasos, requiere interactuar con sistemas reales y se repite seguido.

Cómo funciona un agente de QA por dentro

No hace falta ser experto en machine learning para entender cómo trabaja un agente. Su funcionamiento se puede explicar con un ciclo bastante intuitivo, muy parecido a cómo trabaja un tester humano.

El ciclo: pensar, actuar, observar

1. Entender el objetivo. El agente recibe una instrucción ("validá el flujo de recuperación de contraseña") junto con contexto: la historia de usuario, los criterios de aceptación, la URL del ambiente de pruebas, las credenciales de testing.
2. Planificar. El modelo razona sobre qué pasos necesita: ir a la pantalla de login, buscar el link de "olvidé mi contraseña", ingresar un email válido, verificar el mensaje, revisar la casilla de correo de prueba, seguir el link, definir una nueva contraseña e intentar ingresar.
3. Actuar. Usa una herramienta para ejecutar el primer paso, por ejemplo abrir el navegador en la URL indicada.
4. Observar. Recibe el resultado de la acción: el contenido de la página, una captura, la respuesta de la API o un mensaje de error.
5. Ajustar. Con esa información decide el siguiente paso. Si apareció un banner de cookies, lo cierra. Si el link cambió de lugar, lo busca. Si encontró algo raro, lo registra.
6. Repetir hasta completar el objetivo, quedarse sin opciones o llegar a un límite definido (de pasos, tiempo o costo).
7. Reportar. Arma un resumen con lo que hizo, lo que encontró y la evidencia correspondiente.

Este patrón de razonar, actuar y observar en bucle es la base de casi todos los agentes actuales. Lo potente es que el agente no necesita que cada paso esté escrito de antemano: lo va resolviendo sobre la marcha, como haría una persona.

Las herramientas y el protocolo MCP

Un modelo de lenguaje por sí solo no puede abrir un navegador ni consultar una base de datos. Para eso necesita herramientas conectadas. Durante mucho tiempo cada plataforma resolvía esto a su manera, hasta que apareció el Model Context Protocol (MCP), un estándar abierto que define cómo un agente se conecta con herramientas y fuentes de datos externas.

Para el mundo del QA, MCP es una gran noticia: hoy existen servidores MCP para controlar navegadores con Playwright, para trabajar con repositorios, para consultar bases de datos o gestionar tickets. Eso significa que un mismo agente puede, en una sola sesión, leer la historia en tu herramienta de gestión, ejecutar la prueba en el navegador, consultar la base para validar que el dato se guardó bien y dejar el bug documentado. Todo sin que vos tengas que copiar y pegar entre ventanas.

Contexto: el combustible del agente

La calidad del trabajo de un agente depende muchísimo del contexto que le damos. Un agente que no conoce las reglas de negocio va a probar cosas obvias y se va a perder lo importante. Por eso cada vez se habla más de ingeniería de contexto: preparar documentación clara, criterios de aceptación bien escritos, glosarios del dominio, convenciones del equipo y ejemplos de buenos casos de prueba y buenos reportes.

Fijate en algo interesante: todo eso que el agente necesita para hacer bien su trabajo es exactamente lo que siempre defendimos desde QA. Requisitos claros, criterios de aceptación testeables, documentación al día. El enfoque agéntico no reemplaza las buenas prácticas, las vuelve todavía más necesarias.

Uno o varios agentes

Muchos sistemas actuales no usan un único agente que hace todo, sino un equipo de agentes especializados coordinados por un orquestador. Por ejemplo: un agente analiza historias, otro diseña casos, otro genera datos, otro ejecuta en el navegador y otro arma reportes. Cada uno tiene instrucciones y herramientas acotadas a su tarea, lo que suele dar mejores resultados que un agente generalista y hace más fácil entender qué falló cuando algo sale mal.

Es el mismo enfoque que usamos en los agentes de k0lmenIA: once agentes con responsabilidades bien definidas, desde el análisis de historias hasta el informe de cierre, pensados para que un QA manual los pueda usar conversando en español.

Qué puede hacer hoy un agente de QA

Separemos el hype de la realidad. Estas son tareas que los agentes ya hacen razonablemente bien hoy, siempre con supervisión humana:

Análisis de requisitos e historias de usuario

Un agente puede leer una historia y detectar ambigüedades, criterios de aceptación faltantes, contradicciones o casos borde que nadie contempló. Es una forma muy concreta de aplicar Shift-Left: encontrar problemas antes de que exista una sola línea de código. Las preguntas que genera el agente son un excelente insumo para las reuniones de refinamiento.

Diseño de casos de prueba

A partir de requisitos, el agente puede proponer casos de prueba aplicando técnicas clásicas como partición de equivalencia, valores límite o tablas de decisión, y escribirlos en el formato que use tu equipo: una planilla, un gestor de casos de prueba o escenarios en Gherkin. El resultado no es perfecto, pero como primer borrador ahorra muchísimo tiempo y suele cubrir escenarios que a uno se le pasan por cansancio.

Generación de datos de prueba

Crear datos realistas, variados y coherentes entre sí es una tarea tediosa que los agentes resuelven muy bien: usuarios con distintos perfiles, direcciones válidas e inválidas, tarjetas de prueba, combinaciones raras de caracteres, archivos con formatos límite. Además pueden generar datos que respeten las reglas de negocio, algo difícil con generadores aleatorios tradicionales.

Ejecución de pruebas E2E en el navegador

Conectado a un navegador, un agente puede ejecutar un flujo de punta a punta, interpretar la pantalla, completar formularios y verificar resultados, sin depender de selectores escritos a mano. Esto es especialmente útil para pruebas de humo, validaciones rápidas después de un deploy y testing exploratorio guiado.

Testing de APIs

A partir de un contrato OpenAPI o una colección de Postman, un agente puede proponer casos de prueba, ejecutar las requests, validar códigos de estado, estructuras de respuesta y reglas de negocio, y documentar lo que encuentre. Si querés repasar los fundamentos, en el blog tenemos guías de Postman y Swagger, y una referencia de códigos HTTP que te va a venir bien para revisar lo que te reporte el agente.

Auto-healing de pruebas automatizadas

Cuando una prueba automatizada falla porque cambió un selector o un texto, un agente puede analizar el error, inspeccionar la página, proponer la corrección y, si el equipo lo permite, aplicarla. Esto ataca directamente el mayor dolor de la automatización tradicional: el mantenimiento. Eso sí, hay que tener mucho cuidado de que el agente no "arregle" una prueba que falló por un bug real.

Análisis de fallos y triage

Cuando una suite de cientos de pruebas falla en el pipeline, alguien tiene que mirar los logs y decidir qué es un bug, qué es un problema del ambiente y qué es una prueba inestable. Los agentes pueden agrupar fallos similares, identificar la causa probable y priorizar qué revisar primero. Para equipos con suites grandes, esto ahorra horas por semana.

Reportes de bugs y de resultados

A partir de las notas desordenadas de una sesión de prueba, un agente puede redactar reportes de bugs claros, con pasos para reproducir, resultado esperado, resultado obtenido, severidad sugerida y evidencia. También puede consolidar resultados de una ronda de pruebas en un informe ejecutivo con métricas y una recomendación de salida a producción.

Otras tareas en crecimiento

• Revisión de pull requests desde la perspectiva de testing: qué cambió, qué pruebas faltan, qué riesgos introduce.
• Accesibilidad: detección de problemas de contraste, etiquetas faltantes y navegación por teclado.
• Testing visual: comparación de pantallas para encontrar diferencias que importan e ignorar las que no.
• Selección de pruebas: decidir qué subconjunto de la regresión correr según los cambios de cada commit.

Un día de trabajo con agentes

Para bajar todo esto a tierra, imaginemos a Sofi, QA en un equipo que desarrolla una app de reservas. Esta semana entra al sprint una nueva funcionalidad: cancelar una reserva con reembolso parcial según la anticipación.

Por la mañana, Sofi le pasa la historia de usuario al agente de análisis. En pocos minutos recibe una lista de preguntas: ¿qué pasa si la cancelación ocurre exactamente en el límite de 48 horas? ¿El reembolso se calcula sobre el precio con o sin impuestos? ¿Qué ve el usuario si el medio de pago ya expiró? Sofi descarta dos preguntas que no aplican, agrega una propia y lleva el resto a la reunión de refinamiento. El Product Owner ajusta los criterios de aceptación.

Antes del almuerzo, le pide al agente de diseño que genere los casos de prueba a partir de los criterios actualizados. Recibe cuarenta casos. Revisa, elimina duplicados, corrige dos que interpretaron mal una regla y prioriza. Le pide al agente de datos que prepare reservas con distintas anticipaciones y medios de pago.

Por la tarde, cuando el desarrollo llega al ambiente de pruebas, Sofi lanza al agente de ejecución sobre los casos de mayor prioridad, mientras ella hace testing exploratorio de la parte que más le preocupa: lo que pasa cuando dos personas intentan cancelar la misma reserva compartida. Ahí encuentra un bug serio que ningún caso preescrito contemplaba.

Al final del día, el agente de ejecución dejó resultados con capturas y tres posibles bugs. Sofi verifica cada uno: dos son reales y uno es un falso positivo causado por datos mal cargados. Le pide al agente de reportes que redacte los bugs confirmados con la evidencia y los revisa antes de cargarlos.

¿Qué hizo el agente? El trabajo pesado y repetitivo. ¿Qué hizo Sofi? Las decisiones, el criterio, la revisión y el testing exploratorio que encontró el bug más importante. Ese reparto es, hoy, el corazón del QA agéntico bien hecho.

La tendencia: ¿por qué ahora?

La idea de automatizar el testing con inteligencia artificial no es nueva. Hace años que existen herramientas que prometen pruebas "inteligentes". ¿Qué cambió para que ahora sí se hable de agentes en serio? Hay varios factores que se combinaron.

Modelos mucho más capaces

Los modelos de lenguaje mejoraron muchísimo en tres habilidades clave para testing: razonar en varios pasos, usar herramientas correctamente y entender interfaces visuales. Hace poco tiempo un modelo se perdía después de cinco o seis acciones; hoy los mejores pueden sostener tareas largas, recuperarse de errores y trabajar durante bastante tiempo sobre un mismo objetivo.

Estándares para conectar herramientas

Protocolos abiertos como MCP hicieron que conectar un agente con un navegador, un repositorio o una base de datos pase de ser un proyecto de integración a algo que se configura en minutos. Cuando conectar herramientas es fácil, aparecen muchos más casos de uso.

Más código, más rápido

Los equipos de desarrollo adoptaron asistentes y agentes para escribir código, y eso aumentó la velocidad y el volumen de cambios. Más código en menos tiempo significa más cosas para probar, y un equipo de QA del mismo tamaño no da abasto con métodos tradicionales. Paradójicamente, la IA que acelera el desarrollo es uno de los motivos por los que la calidad se volvió más importante que nunca: el código generado por IA también tiene bugs, a veces muy sutiles.

Presión por entregar seguido

Con entregas continuas, el ciclo de testing se achica. Ya no hay semanas de regresión antes de cada release. Los agentes ofrecen una forma de mantener la cobertura sin frenar el ritmo de entrega.

Costos accesibles

Usar modelos avanzados se volvió mucho más barato y accesible, y hoy hay herramientas agénticas que cualquier QA puede usar desde su computadora sin infraestructura especial. Eso democratiza el acceso: ya no es algo exclusivo de grandes empresas con equipos de investigación.

Testear con agentes vs. testear agentes

Cuando hablamos de IA y QA hay dos temas distintos que muchas veces se mezclan, y los dos van a ser muy importantes en los próximos años:

• Testear con agentes: usar agentes de IA como herramienta para probar software tradicional. Es lo que venimos describiendo en todo el artículo.
• Testear agentes (y sistemas de IA en general): asegurar la calidad de productos que tienen IA adentro, como chatbots, asistentes, sistemas de recomendación o los propios agentes.

Este segundo punto abre una especialidad completamente nueva para QA, con desafíos que el testing tradicional no tenía:

No determinismo

Un sistema tradicional, ante la misma entrada, da la misma salida. Un sistema basado en un modelo de lenguaje puede dar respuestas distintas cada vez. Eso rompe la idea clásica de "resultado esperado = resultado obtenido". En lugar de comparar textos exactos, hay que evaluar si la respuesta cumple ciertos criterios: es correcta, es relevante, respeta el tono, no inventa datos, no expone información sensible.

Evaluaciones (evals)

Para medir la calidad de un sistema de IA se usan conjuntos de casos de evaluación, conocidos como evals, que se corren muchas veces para obtener métricas estadísticas en lugar de un simple pasa o falla. Diseñar buenas evals se parece mucho a diseñar buenos casos de prueba: hay que pensar en escenarios representativos, casos borde y criterios claros. Es un terreno natural para los QAs.

Un modelo evaluando a otro

Una técnica muy usada es el LLM-as-a-judge: usar un modelo de lenguaje para evaluar las respuestas de otro según una rúbrica. Es práctico y escala bien, pero hay que validar que el juez sea confiable comparando sus veredictos con evaluaciones humanas. Otra vez: criterio de QA.

Seguridad y comportamiento adversarial

Los sistemas con IA tienen vulnerabilidades propias. La más conocida es la inyección de prompts: instrucciones maliciosas escondidas en un texto, una página web o un documento que intentan que el modelo haga algo que no debería, como revelar datos o ejecutar una acción no autorizada. Probar este tipo de ataques, junto con alucinaciones, sesgos y respuestas dañinas, es parte del trabajo de QA en productos con IA. Si te interesa la seguridad, acá hay un cruce muy interesante entre QA y ciberseguridad.

Agentes que prueban agentes

Y sí, ya se usan agentes para probar otros agentes: un agente simula usuarios con distintos perfiles e intenciones, conversa con el chatbot bajo prueba y registra cómo responde. Es una forma de generar miles de conversaciones de prueba que serían imposibles de hacer a mano.

Riesgos y limitaciones

Sería deshonesto hablar solo de lo bueno. El QA agéntico tiene limitaciones reales que todo equipo debería conocer antes de adoptarlo.

Alucinaciones y falsos resultados

Los modelos pueden inventar cosas con total seguridad: reportar un bug que no existe, afirmar que una prueba pasó cuando no la ejecutó completa o describir un comportamiento que no observó. Por eso cada resultado importante tiene que estar respaldado por evidencia verificable: capturas, logs, respuestas de la API. Un reporte sin evidencia no se considera válido, venga de un humano o de un agente.

El problema del oráculo

Para saber si algo está bien, el agente necesita saber cómo debería ser. Si los requisitos son ambiguos, el agente va a completar los huecos con suposiciones, y esas suposiciones pueden ser incorrectas. Un agente puede validar con mucha eficiencia que el sistema hace lo que el agente cree que debería hacer, que no es lo mismo que lo que el negocio necesita.

Pruebas que siempre pasan

Un riesgo sutil del auto-healing: si el agente tiene libertad para "arreglar" pruebas que fallan, puede terminar adaptando la prueba al bug en lugar de reportarlo. Una prueba que se ajusta sola hasta pasar no prueba nada. Los cambios en las pruebas tienen que ser revisados y aprobados por una persona.

Reproducibilidad

Como el agente decide sobre la marcha, dos ejecuciones del mismo objetivo pueden seguir caminos distintos. Eso es bueno para explorar, pero malo para una regresión, donde necesitamos repetir exactamente lo mismo. Por eso muchos equipos usan agentes para explorar y generar pruebas, y después convierten lo valioso en scripts deterministas que corren en el pipeline.

Seguridad, permisos y datos

Un agente con acceso a herramientas puede hacer daño real si se equivoca o si alguien lo manipula: borrar datos, modificar configuraciones o enviar información a donde no debe. Nunca hay que darle a un agente acceso a producción ni a datos reales de clientes sin controles estrictos. También hay que revisar qué información se envía al proveedor del modelo y si eso cumple con las políticas de la empresa.

Costos y tiempos

Cada paso del agente consume recursos. Una suite de regresión ejecutada completamente por agentes puede ser más lenta y más cara que la misma suite en Playwright. Los agentes no reemplazan a la automatización tradicional en todo: conviene usarlos donde aportan más valor.

Exceso de confianza

Quizás el riesgo más grande es humano: confiar demasiado. Cuando una herramienta acierta muchas veces seguidas, dejamos de revisar. Y justo ahí se escapa el error importante. El criterio crítico del QA es, más que nunca, la última línea de defensa.

Buenas prácticas para adoptarlo

Si estás pensando en sumar agentes a tu proceso de calidad, estas prácticas te van a ahorrar varios dolores de cabeza:

1. Empezá por tareas de bajo riesgo y alto volumen. Generar borradores de casos, datos de prueba o reportes es ideal para arrancar. Dejá la ejecución sobre ambientes críticos para más adelante.
2. Mantené siempre a un humano en el circuito. Definí en qué puntos el agente tiene que frenar y pedir aprobación: antes de cargar un bug, antes de modificar una prueba, antes de cualquier acción irreversible.
3. Dale el mínimo de permisos necesarios. Si el agente solo tiene que leer, que no pueda escribir. Si solo tiene que probar en el ambiente de QA, que no tenga credenciales de otros ambientes.
4. Trabajá en ambientes aislados. Usá ambientes de prueba, datos ficticios y cuentas de testing. Nunca datos reales de clientes.
5. Exigí evidencia. Cada resultado del agente tiene que venir con capturas, logs o respuestas que permitan verificarlo.
6. Invertí en contexto. Documentá reglas de negocio, convenciones y ejemplos de buen trabajo. Es la mejor inversión para mejorar los resultados.
7. Versioná instrucciones y configuraciones. Las instrucciones que le das a los agentes son parte de tu proceso de calidad: guardalas en el repositorio, revisalas y mejoralas como cualquier otro artefacto.
8. Medí el impacto. Compará antes y después: tiempo de diseño de pruebas, bugs encontrados, falsos positivos, tiempo de mantenimiento. Sin datos, es solo una sensación.
9. Combiná enfoques. Usá agentes para explorar, diseñar y analizar, y automatización determinista para las regresiones que tienen que correr igual cada vez.
10. Capacitá al equipo. Una herramienta poderosa en manos de alguien sin fundamentos de testing produce mucho volumen y poco valor.

Qué cambia en el rol del QA

Llegamos a la pregunta que más inquieta: ¿qué pasa con nuestro trabajo? Te comparto mi visión después de muchos años en esto.

Del ejecutor al estratega

Las tareas más mecánicas, como ejecutar el mismo caso por enésima vez, transcribir pasos o armar planillas de datos, van a ir quedando cada vez más en manos de agentes. Lo que gana valor es lo que siempre fue el corazón del QA: entender el negocio, identificar riesgos, decidir qué probar y qué no, diseñar una estrategia, cuestionar requisitos y tener el criterio para saber cuándo algo está listo para salir.

Los fundamentos importan más que nunca

Para supervisar a un agente tenés que saber más que el agente. Si no conocés las técnicas de diseño de pruebas, no vas a darte cuenta de que el agente se olvidó los valores límite. Si no sabés cómo funciona una API, no vas a detectar que validó mal una respuesta. Los fundamentos, como los que cubre la certificación ISTQB, no pierden vigencia: se vuelven la base para trabajar bien con IA.

Habilidades nuevas

• Pensamiento crítico para evaluar lo que producen los agentes y detectar errores convincentes.
• Ingeniería de contexto y de instrucciones para comunicarle a un agente qué necesitás, con qué restricciones y con qué criterio de calidad.
• Conocimiento técnico básico de cómo funcionan los modelos, las herramientas y los protocolos, para entender qué puede y qué no puede hacer cada agente.
• Testing de sistemas de IA: evals, no determinismo, seguridad y sesgos. Una especialidad con muchísima demanda por delante.
• Automatización: lejos de desaparecer, saber automatizar te permite combinar lo mejor de los agentes con lo mejor de los scripts deterministas.

¿Y los que recién empiezan?

Escucho seguido la preocupación de que los agentes van a eliminar los puestos junior. Es cierto que algunas tareas de entrada se automatizan, pero también aparece una oportunidad enorme: alguien que arranca hoy, con buenos fundamentos y manejo de herramientas agénticas, puede aportar valor mucho más rápido que hace unos años. La clave es no saltarse los fundamentos por ir directo a la herramienta de moda. Entender qué es un buen caso de prueba, cómo se reporta un bug y cómo se piensa un riesgo sigue siendo el primer paso. Por eso en nuestro curso gratuito de QA desde cero arrancamos por ahí.

Lo que se viene

Predecir el futuro en tecnología es arriesgado, y más en un área que cambia cada pocos meses. Pero hay algunas tendencias que ya se ven con bastante claridad.

Agentes integrados en el pipeline

Los agentes van a dejar de ser algo que el QA usa desde su computadora para convertirse en un paso más del ciclo de CI/CD: analizan cada cambio, deciden qué probar, ejecutan pruebas exploratorias sobre las áreas afectadas y dejan comentarios en el pull request antes de que alguien lo apruebe.

Equipos de agentes cada vez más especializados

En lugar de un agente que hace todo, vamos a ver equipos de agentes especializados en performance, seguridad, accesibilidad, APIs o experiencia de usuario, coordinados entre sí y supervisados por QAs que definen la estrategia general.

Testing continuo en producción

Combinando agentes con observabilidad, el monitoreo en producción va a ser más inteligente: agentes que detectan comportamientos anómalos, reproducen el problema en un ambiente de prueba y proponen un caso de regresión para que no vuelva a pasar. Es el Shift-Right llevado a otro nivel.

Calidad de la IA como disciplina propia

Con cada vez más productos que incluyen IA, el testing de modelos y agentes se va a consolidar como especialidad, con sus propias herramientas, metodologías y certificaciones. ISTQB ya tiene certificaciones vinculadas a la IA, como la de AI Testing, y es esperable que el área siga creciendo.

Regulación y trazabilidad

Marcos regulatorios como la Ley de Inteligencia Artificial de la Unión Europea empiezan a exigir evaluación, documentación y supervisión humana para ciertos sistemas de IA. Eso va a generar demanda de perfiles capaces de demostrar, con evidencia, que un sistema funciona como debe. Suena bastante a QA, ¿no?

Lo que probablemente no cambie

Alguien va a tener que decidir qué significa "calidad" para cada producto, qué riesgos son aceptables y cuándo algo está listo para el usuario. Esa responsabilidad no se delega a una herramienta. Las herramientas cambian; el criterio sigue siendo humano.

Cómo empezar hoy

Si llegaste hasta acá y querés pasar de la teoría a la práctica, te propongo un camino en cinco pasos:

1. Afianzá los fundamentos. Si estás empezando, aprendé primero diseño de casos, reporte de bugs, testing de APIs y conceptos de automatización. Nuestro curso gratuito y el material ISTQB en español son un buen punto de partida.
2. Usá IA como asistente en tu trabajo diario. Pedile que revise tus casos, que te sugiera escenarios o que te ayude a redactar reportes. Vas a aprender rápido qué hace bien y dónde se equivoca.
3. Probá un agente en un proyecto de práctica. Elegí una de las webs para practicar testing y dejá que un agente analice una funcionalidad, genere casos y los ejecute. Compará su trabajo con el tuyo.
4. Sumá agentes especializados. En QARMY armamos k0lmenIA, un equipo de agentes de IA gratuito y open source para tareas de QA: análisis de historias, casos de prueba manuales y BDD, datos de prueba, reportes de bugs, ejecución E2E y de APIs, y reportes de resultados. Está pensado para QAs manuales y no requiere saber programar.
5. Combiná con automatización. Cuando un flujo probado por el agente se vuelva crítico, pasalo a una prueba automatizada estable. Para eso podés usar el framework k0lmena, con Playwright, Cucumber y soporte para APIs y performance.

Y lo más importante: compartí lo que aprendés. Este es un campo nuevo para todos, y las comunidades que experimentan juntas aprenden mucho más rápido.

Preguntas frecuentes

¿El QA agéntico reemplaza a la automatización con Playwright o Selenium?

No. Son complementarios. Los agentes son muy buenos explorando, adaptándose a cambios y resolviendo tareas variadas, mientras que los scripts deterministas siguen siendo más rápidos, baratos y confiables para regresiones que tienen que ejecutarse igual cada vez.

¿Necesito saber programar para usar agentes de QA?

Para muchas herramientas actuales, no. Hay agentes que se usan conversando en lenguaje natural. Igual, tener nociones técnicas te va a ayudar a entender lo que hace el agente, configurarlo mejor y detectar cuando se equivoca.

¿Es seguro usar agentes con el sistema de mi empresa?

Puede serlo si se toman precauciones: ambientes de prueba aislados, datos ficticios, permisos mínimos, aprobación humana para acciones sensibles y revisión de qué información se comparte con el proveedor del modelo. Antes de usarlo en un proyecto real, consultá las políticas de seguridad de tu empresa.

¿La IA va a dejar sin trabajo a los QAs?

Va a cambiar el trabajo, como lo cambió la automatización en su momento. Las tareas mecánicas se automatizan y crece la demanda de criterio, estrategia y especialización, incluyendo el testing de sistemas de IA. Los QAs que se adapten van a tener más oportunidades, no menos.

Conclusión

El QA agéntico no es una moda pasajera ni una solución mágica. Es una evolución natural de la automatización, impulsada por modelos de lenguaje capaces de razonar, usar herramientas y adaptarse. Bien usado, libera a los equipos de calidad del trabajo repetitivo y les permite enfocarse en lo que realmente importa: entender riesgos, cuestionar, explorar y decidir.

Mal usado, genera una falsa sensación de seguridad, reportes llenos de ruido y pruebas que pasan sin probar nada. La diferencia la hace el criterio de las personas que lo dirigen.

Por eso mi recomendación es simple: no le tengas miedo, pero tampoco le creas todo. Aprendé los fundamentos, experimentá con las herramientas, medí resultados y mantené siempre el pensamiento crítico. El futuro del QA no es humanos contra máquinas, es humanos que saben dirigir máquinas.

Si querés seguir aprendiendo, sumate al canal de WhatsApp de QARMY, donde compartimos novedades, recursos y anunciamos los próximos cursos. Y si probás agentes en tu equipo, contanos cómo te fue.