Durante años describimos el trabajo de QA como una combinación de análisis, ejecución de pruebas, automatización y reporte de defectos. Ese modelo sigue siendo necesario, pero ya no alcanza para explicar lo que ocurre cuando un profesional puede apoyarse en varios agentes de IA para revisar requisitos, proponer escenarios, explorar logs, analizar APIs y preparar automatización en paralelo.
La consecuencia no es que el criterio del QA deje de importar. Es exactamente lo contrario. Cuando aumenta la capacidad de producir casos, scripts y reportes, se vuelve más importante decidir qué riesgos merecen atención, qué evidencia es confiable y cuándo un producto tiene suficiente calidad para avanzar. Por eso veo esta evolución menos como el reemplazo del QA y más como el paso de QA Engineer a Quality Owner.
El cambio no es de manual a automático
Automatizar una prueba cambia la forma de ejecutarla. Trabajar con agentes cambia la forma de organizar el trabajo. Un agente puede recibir un objetivo, consultar contexto, utilizar herramientas, producir un resultado y solicitar una decisión. Varios agentes especializados pueden operar como esos “mini QA” que analizan diferentes partes del producto al mismo tiempo.
Sin embargo, producir más artefactos no equivale a comprender mejor el riesgo. Una suite puede crecer y seguir protegiendo poco. Un reporte puede verse completo y partir de una suposición falsa. El valor aparece cuando la capacidad adicional se integra a un sistema de calidad con fuentes, límites, revisión y decisiones humanas.
Qué podrían hacer los mini agentes de un QA
Analizar requisitos y riesgos
Un agente puede separar hechos, reglas, supuestos y preguntas abiertas. También puede comparar una historia con decisiones anteriores y señalar inconsistencias. No decide qué quiso decir el negocio; prepara una conversación mejor informada. En mi guía sobre análisis de requisitos con IA antes de un refinamiento desarrollo este uso con más detalle.
Diseñar cobertura y datos
Otro agente puede proponer particiones, límites, transiciones, tablas de decisión y combinaciones de datos. Su salida es un borrador de cobertura, no una suite aprobada. El QA debe validar trazabilidad, eliminar redundancias y asignar cada riesgo al nivel de prueba donde pueda observarse con precisión.
Apoyar automatización y diagnóstico
Los agentes también pueden explicar un repositorio, sugerir una prueba, comparar respuestas de una API o agrupar señales de un fallo. Esto acelera la investigación, pero no convierte una correlación en causa raíz. La evidencia del sistema sigue teniendo prioridad sobre una explicación bien redactada.
Qué significa ser Quality Owner
Quality Owner no tiene que ser un nuevo cargo. Es una forma de asumir responsabilidad sobre el sistema de calidad. El objetivo deja de ser “terminar las pruebas” y pasa a ser construir confianza suficiente para tomar una decisión de producto.
- Conecta los riesgos del negocio con una estrategia de validación.
- Hace visibles las suposiciones y la evidencia que soporta cada decisión.
- Promueve testabilidad, observabilidad y automatización sostenible.
- Distribuye la calidad entre producto, desarrollo, operaciones y QA.
- Define dónde puede actuar la IA y dónde se requiere aprobación humana.
- Comunica incertidumbre sin reducirla a un porcentaje de pruebas aprobadas.
Esta responsabilidad no significa convertirse en el único dueño de la calidad. Significa diseñar las condiciones para que todo el equipo pueda contribuir y saber quién toma la decisión cuando las señales se contradicen.
Un modelo sencillo para trabajar con agentes
Yo organizaría el flujo en cuatro capas. Primero, contexto verificable: requisitos, contratos, código, telemetría y decisiones vigentes. Segundo, tareas acotadas: cada agente recibe un objetivo, fuentes permitidas y un formato de salida. Tercero, controles: privacidad, permisos, trazabilidad y criterios de rechazo. Cuarto, decisión humana: una persona acepta, modifica o descarta el resultado.
Este modelo coincide con una idea importante del AI Risk Management Framework de NIST: gobernar, mapear, medir y gestionar el riesgo durante todo el ciclo. También es coherente con la formación de ISTQB sobre testing con IA generativa, que incluye evaluación de resultados, alucinaciones, privacidad, seguridad y sesgos.
Lo que no delegaría
- la aceptación de un riesgo de negocio;
- la interpretación final de un comportamiento ambiguo;
- la decisión de utilizar datos sensibles;
- la aprobación de cambios destructivos o despliegues;
- la declaración de causa raíz sin evidencia;
- la decisión de que un producto está listo solo porque una suite terminó en verde.
La IA puede ayudar a preparar estas decisiones, pero no debería ocultar quién responde por ellas. Una recomendación debe conservar sus fuentes, sus límites y el nivel de confianza.
Cómo comenzar sin convertirlo en otro proyecto de herramientas
- Escoge una tarea repetitiva con una salida fácil de revisar.
- Define qué información puede utilizar el agente y qué datos quedan prohibidos.
- Crea un ejemplo de salida aceptable y criterios para rechazarla.
- Mide tiempo total, incluyendo preparación y revisión.
- Registra errores, correcciones y preguntas generadas.
- Amplía el alcance solo cuando la calidad de la decisión mejore.
El primer objetivo no debería ser “tener agentes”. Debería ser reducir trabajo mecánico sin perder trazabilidad ni aumentar el riesgo. Si el sistema produce más ruido, la solución no es añadir otro agente, sino mejorar el contexto y el control.
El futuro del QA sigue necesitando criterio
Un QA con agentes puede analizar más información y explorar más alternativas. Eso eleva el nivel de la responsabilidad: deberá comprender mejor el producto, la arquitectura, los datos y el impacto de sus decisiones. La ventaja profesional no estará en generar más pruebas, sino en construir un sistema que ayude al equipo a aprender y liberar con confianza.
Preguntas frecuentes
¿Quality Owner es lo mismo que QA Lead?
No necesariamente. QA Lead suele describir una responsabilidad de coordinación sobre personas, prácticas o entregables de QA. Quality Owner describe la responsabilidad de conectar riesgo, evidencia y decisiones de calidad en el producto. Una persona puede ejercer ambos papeles, pero el segundo puede existir sin gestión formal de equipo.
¿Los agentes reducirán el número de QA?
Probablemente cambiarán la distribución del trabajo y elevarán las expectativas de productividad. El efecto dependerá de cada organización. Mi apuesta profesional es desarrollar las capacidades que siguen siendo escasas: comprender sistemas, priorizar riesgo, evaluar evidencia y coordinar decisiones. Son precisamente las capacidades que permiten utilizar agentes sin convertir velocidad en deuda.
En el siguiente artículo explico por qué QA no debería ser una fase y cómo distribuir la responsabilidad de calidad en el equipo. Para profundizar en el diseño asistido, también puedes leer cómo crear casos de prueba con IA desde una historia de usuario.
¿Qué tarea delegarías primero a uno de tus “mini QA” y cuál conservarías siempre bajo revisión humana? Te leo en LinkedIn.