Claude Code y 11 Agentes: Cómo un equipo de QA automatizó hasta el 80% de la rutina de pruebas

Un equipo de QA ha demostrado que los agentes de IA ya pueden asumir la mayor parte del trabajo rutinario de pruebas: desde la lectura de requisitos y diseño de escenarios de prueba hasta la carga de casos de prueba en TMS y creación de Merge Requests con autotests listos. En lugar de ampliar su personal con dos evaluadores más, el equipo construyó un "exoesqueleto" de 11 agentes especializados basado en Claude Code y afirma que cubre hasta el 80% del trabajo operacional de un ingeniero de QA. Partieron de un problema típico de los equipos de productos: el desarrollo lanza nuevas funcionalidades más rápido de lo que las pruebas pueden convertir requisitos en escenarios, datos y automatización.

Según evaluación interna, aproximadamente el 20% del tiempo de QA se dedica al análisis de requisitos y diseño de pruebas, otro 15% a la creación de casos en TMS, 10% a la preparación de datos, 25% a la automatización, y luego vienen las comprobaciones, regresión e informes. En total, hasta el 80% de la carga de trabajo puede describirse mediante reglas y desglosarse en etapas repetibles. De ahí la idea: no reemplazar al ingeniero, sino convertirlo en un operador de pipeline que establece la tarea, controla artefactos e interviene solo donde el sistema carece de contexto o necesita tomar una decisión ambigua.

La arquitectura se construye como una cadena modular de 11 skills y un orquestrador separado. Un agente extrae la tarea de Jira y materiales relacionados de Confluence, otro descompone requisitos en User Stories y tareas, un tercero genera escenarios de prueba según reglas ISTQB, los siguientes se ocupan de datos faltantes, discrepancias, selectores DOM, autotests de API e interfaz de usuario, comparando escenarios con código, cargando casos en Zephyr Scale y creando Merge Requests en GitLab. Escenarios JSON con trazabilidad completa a requisitos y criterios de aceptación sirven como única fuente de verdad, mientras que se construye en paralelo una matriz de cobertura RTM.

Para la parte frontend, el sistema además accede a Figma a través de MCP y extrae no solo capturas de pantalla, sino la estructura de la interfaz, estados de elementos y restricciones. Se puso énfasis especial en calidad y protección contra debilidades típicas de LLM. Después de la generación de escenarios, el orquestrador ejecuta puntos de control de calidad: verifica esquema JSON, completitud de pasos, prioridades, ausencia de duplicados y cobertura de requisitos.

Después de la generación de autotests, el control se vuelve aún más estricto: se validan código Python, fixtures y ejecución real de pruebas. Se utiliza un esquema de depuración en dos etapas. Primero, el sistema ejecuta cada prueba por separado y diferencia problemas de código de prueba de defectos reales del producto.

Luego interviene las pruebas de mutación: en una prueba ya aprobada, se invierte el assert, y si aún permanece verde, tal prueba se considera vacía y requiere refinamiento. Otra capa importante es el protocolo de conflictos entre Jira, Figma, texto de requisitos y comportamiento real de la interfaz. Los conflictos obvios se resuelven automáticamente por jerarquía de prioridad de fuentes, mientras que los casos disputados se escalan al ingeniero.

En la práctica, el piloto durante un mes y medio entregó números que típicamente justifican lanzar tales experimentos. El número de casos de prueba de regresión creció de aproximadamente 50 a 400, el detalle de escenarios se volvió completo, y la cobertura de regresión por automatización se aproximó al 100%. El propio tiempo de regresión se redujo de aproximadamente un día a decenas de minutos, la ruta de finalización del desarrollo a aprobación de QA de varios días a varias horas, e integrar pruebas en un nuevo proyecto ahora toma alrededor de cuatro horas de configuración en lugar de meses de contratación y adaptación.

Además, el sistema comenzó a encontrar más contradicciones ocultas de requisitos y bugs que el proceso manual. Mientras tanto, la versión piloto se ejecuta en una suscripción Claude Pro por $100 por mes y, según se afirma, es capaz de servir 2–3 proyectos con más de 100 pruebas por mes para cada uno. La principal conclusión de este caso es que el rol de QA está comenzando a cambiar de la ejecución manual a la gestión de contexto, reglas y calidad de las decisiones que toma la IA.

Pero la historia funciona solo bajo ciertas condiciones: los requisitos deben ser suficientemente completos, el proyecto debe tener una fuente apropiada de contexto como contratos de API y datos de prueba, y el pipeline en sí no debe ser una "caja negra". El valor aquí no está en la generación mágica de pruebas, sino en una cadena transparente de pasos que puede re-ejecutarse, verificarse y fortalecerse gradualmente. Si este enfoque despega más allá de los pilotos, el mercado de pruebas podría obtener no un reemplazo para ingenieros, sino un formato mucho más productivo y escalable para su trabajo.