Pirámide de Pruebas como Herramienta de Descomposición de Tareas para Agentes IA en QA Assist

Cuando un modelo de lenguaje se convierte en diseñador de pruebas, la teoría clásica de QA adquiere inesperadamente una nueva dimensión. Este es el tema del tercer artículo de Mikhail Fedorov en su serie sobre el sistema QA Assist, publicado en Habr. Esta vez, el autor explica por qué la pirámide de pruebas, concebida mucho antes de la era de las redes neuronales, resulta ser crítica para los agentes de IA con ventanas de contexto limitadas.

QA Assist es un sistema de 11 agentes de IA especializados diseñados para automatizar las pruebas de software. En el primer artículo de la serie, Fedorov describió la arquitectura: cómo los agentes se dividen por responsabilidad, cómo interactúan y qué pueden hacer. En el segundo, mostró honestamente la realidad de la implementación: una tarea que en papel parece cuatro horas de trabajo se transforma en una semana de aprobaciones, reuniones con especialistas en seguridad y correcciones de configuración de infraestructura en un entorno corporativo.

El tercer artículo sube a un nivel superior—a la cuestión de cómo formular adecuadamente tareas para la IA para obtener un resultado de alta calidad y reproducible. La pirámide de pruebas es uno de los principios fundamentales del desarrollo de software. En la base hay pruebas unitarias rápidas y económicas que verifican funciones y métodos de forma aislada.

En el medio hay pruebas de integración que verifican la interacción de componentes. En la parte superior hay pruebas end-to-end lentas y costosas que simulan escenarios de usuarios reales. La proporción clásica: muchas pruebas unitarias, menos pruebas de integración, E2E mínimo.

Esta estructura ahorra tiempo en la ejecución de pruebas y simplifica la depuración: cuando una prueba unitaria falla, es inmediatamente evidente qué se rompió.

El problema surge cuando un modelo de lenguaje diseña pruebas en lugar de un ingeniero. Un LLM opera dentro de una ventana de contexto—un volumen fijo de tokens que el modelo puede mantener en una sesión de generación única. Para tareas pequeñas, esto no es crítico.

Pero si le pides a una red neuronal que escriba un conjunto de pruebas completo para una aplicación grande en una sola solicitud, el resultado se vuelve predecible: o parte de la lógica empresarial se perderá más allá del borde del contexto, o el modelo producirá escenarios superficiales sin profundizar en dependencias reales y casos límite. Aquí es donde la pirámide de pruebas deja de ser teoría de libro de texto y se convierte en una herramienta práctica para descomposición de tareas. La metáfora del autor—alimentar a un elefante a una red neuronal a pedazos—describe con precisión la esencia del enfoque.

Una tarea grande se divide en capas según la pirámide: primero, los agentes generan pruebas unitarias a nivel de función, luego pasan a escenarios de integración, y finalmente, a E2E. Cada capa se ajusta dentro de la ventana de contexto del modelo y se procesa de forma aislada, sin pérdida de calidad por desbordamiento de contexto.

Este enfoque proporciona varias ventajas concretas. Cada solicitud al modelo se vuelve enfocada: el agente recibe un alcance claro, un contrato de entrada definido y un artefacto de salida específico. Los errores están localizados—si una prueba unitaria se escribe incorrectamente, esto es visible de inmediato, no después de varias iteraciones cuando un escenario de integración ya está siendo construido sobre él.

Finalmente, la pirámide establece un orden natural de dependencias: las pruebas E2E se construyen sobre una base verificada, no en paralelo con ella. Fedorov no pretende haber inventado la rueda. El propio autor reconoce: esto es la aplicación de un principio de ingeniería conocido desde hace mucho a un contexto nuevo.

Pero ahí radica la idea principal: la IA no elimina los principios básicos de desarrollo; los hace aún más significativos. Entender la pirámide de pruebas ahora es necesario no solo para un ingeniero de QA, sino también para quienes diseñan la arquitectura de solicitudes a modelos de lenguaje. Para los equipos que consideran herramientas de IA para automatización de pruebas, esta es una lección práctica: primero diseña la descomposición de la tarea, luego confíala al modelo.

Un elefante se come a pedazos—y esto no es una limitación de la tecnología, sino la única arquitectura que funciona.