Pirámide de Pruebas para Asistentes de IA en QA

# Pirámide de pruebas como restricción arquitectónica para asistentes de IA en QA

Cuando un modelo de lenguaje se convierte en diseñador de pruebas, la clásica pirámide de pruebas deja de ser solo una recomendación: se transforma en un requisito técnico estricto. La razón es simple: la ventana de contexto del LLM no puede contener físicamente una descripción completa de una Feature compleja con docenas de User Stories y Tasks. Intentar «alimentarlo con todo de una vez» provoca una caída en la calidad o un fallo total en la generación.

Por qué la pirámide resuelve el problema de contexto

La pirámide de pruebas ofrece una forma natural de descomponer las tareas. En lugar de cargar al modelo con la descripción de toda la solución TI, se trabaja por niveles:

• Nivel de Task (Componente) — solo el contrato de la API y las reglas de negocio para un microservicio.
• Nivel de User Story (Sistema) — integración entre front-end y back-end dentro de un único sistema de información.
• Nivel de Feature (E2E) — interacciones entre sistemas y procesos de negocio de extremo a extremo.

Cada nivel requiere su propio contexto. Y cada uno cabe dentro de los límites del LLM cuando se proporciona de forma aislada. Esto no es teoría: es una necesidad práctica.

Ejemplo: La Feature «Promo Codes During Order Checkout» consta de tres User Stories y nueve Tasks. La descripción completa, incluyendo mockups, especificaciones de API y datos de prueba, ocupa ~150K tokens. Claude 3 Opus con su ventana de 200K tokens puede manejarlo técnicamente, pero la calidad de las pruebas en niveles inferiores cae debido al «ruido» de los niveles superiores. Descomponer por niveles reduce la carga a 8–15K tokens por solicitud, y la calidad mejora drásticamente.

Cómo utiliza el asistente de IA los niveles de la pirámide

En el sistema QA Assist, cada nivel de pruebas es manejado por un agente dedicado. La arquitectura es así:

• Agente Unit/API — recibe la especificación de un endpoint o componente. Genera pruebas unitarias y de API que cubren valores límite, escenarios negativos y verificaciones de compatibilidad hacia atrás.
• Agente Sistema — recibe la descripción de la User Story y las interfaces de los componentes involucrados. Genera pruebas de sistema que verifican la integración y escenarios de usuario.
• Agente E2E — recibe el mapa de la Feature y los estados de las User Stories. Genera pruebas de extremo a extremo que comprueban la consistencia de datos entre sistemas.

El punto clave es que el contexto de cada agente está estrictamente limitado a su nivel. El agente Unit no sabe nada del panel de administración. El agente Sistema no ve el historial de pedidos. Esto no es una limitación: es una optimización adaptada a las capacidades del LLM.

Ejemplos concretos: qué genera la IA en cada nivel

Tomemos una Task: API de back-end para aplicar un código promocional (POST /orders/apply-promo).

Qué recibe el agente Unit/API:

• Especificación del endpoint (parámetros de entrada, campos de salida, códigos de error).
• Reglas de negocio para el cálculo de descuentos (cantidad fija, porcentaje, descuentos combinados).
• Restricciones (límites de uso, fechas de expiración, restricciones geográficas).

Qué genera el agente:

# Example sgenerirovannogo test
@pytest.mark.parametrize("promo_code, expected_discount", [
    ("SALE10", 10.0),      # Protsentnaya skidka
    ("FIXED50", 50.0),     # Fiksirovannaya sum
    ("COMBO", 60.0),       # Kombinirovannaya (10% + 50 rubles)
])
def test_valid_promo_codes(api_client, promo_code, expected_discount):
    response = api_client.post("/orders/apply-promo", json={"code": promo_code})
    assert response.status_code == 200
    assert response.json()["discount"] == expected_discount

@pytest.mark.parametrize("invalid_code", ["EXPIRED", "OVERUSED", "INVALID_FORMAT"])
def test_invalid_promo_codes(api_client, invalid_code):
    response = api_client.post("/orders/apply-promo", json={"code": invalid_code})
    assert response.status_code == 400
    assert "error" in response.json()

Ahora tomemos una User Story: «El usuario aplica un código promocional durante el checkout del pedido».

Qué recibe el agente Sistema:

• Descripción del escenario (el usuario añade un artículo, ingresa el código promocional, ve el descuento, completa el pedido).
• Interfaces de front-end y back-end (formulario de entrada, llamadas a API, visualización del total).
• Requisitos de UX (validación en cliente, mensajes de error, estados de carga).

Qué genera el agente:

// Example Playwright-test
test('User applies valid promo code during checkout', async ({ page }) => {
  await page.goto('/cart');
  await page.fill('#promo-code', 'SALE10');
  await page.click('#apply-promo');
  
  // Checking otobrazhenie skidki
  await expect(page.locator('.discount-amount')).toHaveText('-10%');
  
  // Checking pereschyot itogovoy summy
  const originalTotal = await page.locator('.original-total').innerText();
  const discountedTotal = await page.locator('.final-total').innerText();
  expect(parseFloat(discountedTotal)).toBeLessThan(parseFloat(originalTotal));
  
  // Oformlyaem zakaz
  await page.click('#checkout-button');
  await expect(page).toHaveURL('/order-confirmation');
});

Por qué los LLM tienen más dificultades con los niveles superiores

Los modelos de lenguaje muestran un declive predecible en la calidad al tratar con abstracciones de alto nivel:

• Nivel Feature/E2E — requiere entender lógica de negocio que a menudo no está formalizada explícitamente. El modelo debe hacer suposiciones que podrían ser incorrectas.
• Nivel Sistema/User Story — mejor, pero aún exige integrar conocimiento de múltiples fuentes (front-end, back-end, UX).
• Nivel Task/Unit — ideal para las fortalezas del LLM: especificaciones claras, reglas formales, entradas/salidas predecibles.

Regla empírica: cuanto más bajo el nivel de la pirámide, mayor la precisión en la generación de pruebas por parte del asistente de IA. En la práctica, esto significa:

• Para pruebas Unit/API — confiar en la IA casi por completo (cobertura 90–95 %).
• Para pruebas de Sistema — realizar revisiones, especialmente en integraciones complejas (cobertura 70–80 %).
• Para pruebas E2E — usar la IA solo para generar borradores que necesitan una refinación humana significativa (cobertura 50–60 %).

Lecciones arquitectónicas para asistentes de IA

Si estás construyendo un sistema de IA para generación de pruebas, ignorar la pirámide de pruebas es una receta para el fracaso. Aquí están los principios clave que incorporamos en QA Assist:

• Descomposición por niveles — obligatoria. Nada de prompts que vuelquen toda la Feature de una vez.
• Contexto aislado — cada agente trabaja solo con su nivel. La información se pasa entre niveles mediante datos estructurados, no contexto textual.
• Humano en el bucle — especialmente en niveles superiores. La IA genera un borrador; los humanos lo refinan y aprueban.
• Bucle de retroalimentación — los resultados de ejecución de pruebas se usan para ajustar finamente a los agentes. Si la IA omite un caso límite, se añade al conjunto de entrenamiento.

Sin estos principios, incluso el LLM más potente producirá pruebas que parecen plausibles pero fallan en detectar bugs reales.

Lecciones clave

• La pirámide de pruebas no es solo una metodología: es un requisito técnico para asistentes de IA efectivos.
• La ventana de contexto del LLM impide físicamente procesar Features complejas en su totalidad sin pérdida de calidad.
• La descomposición por niveles (Task → User Story → Feature) es la única forma de producir pruebas de calidad en todos los niveles.
• La IA destaca en los niveles inferiores de la pirámide (Unit/API) y tiene más dificultades con los superiores (E2E).
• Los humanos siguen siendo esenciales, particularmente para revisar y refinar pruebas de Sistema y E2E.

— Editorial Team