Pyramide de tests pour les assistants IA en QA

La Pyramide des Tests comme Contrainte Architecturale pour les Assistants IA en QA

Quand un modèle de langage devient concepteur de tests, la classique pyramide des tests cesse d'être une simple recommandation — elle devient une exigence technique stricte. La raison est simple : la fenêtre de contexte du LLM ne peut physiquement pas accommoder une description complète d'une Feature complexe avec des dizaines de User Stories et de Tasks. Tenter de « lui fournir tout d'un coup » entraîne une chute de qualité ou un échec complet de génération.

Pourquoi la Pyramide Résout le Problème de Contexte

La pyramide des tests offre une façon naturelle de décomposer les tâches. Au lieu de charger le modèle avec une description de l'ensemble de la solution IT, vous travaillez par niveaux :

• Niveau Task (Composant) — seulement le contrat API et les règles métier pour un microservice.
• Niveau User Story (Système) — intégration front-end et back-end au sein d'un seul système d'information.
• Niveau Feature (E2E) — interactions entre systèmes et processus métier de bout en bout.

Chaque niveau nécessite son propre contexte. Et chacun s'adapte aux limites du LLM lorsqu'il est fourni isolément. Ce n'est pas de la théorie — c'est une nécessité pratique.

Exemple : la Feature « Promo Codes During Order Checkout » est composée de trois User Stories et de neuf Tasks. La description complète, incluant les maquettes, les spécifications API et les données de test, représente ~150K tokens. Claude 3 Opus avec sa fenêtre de 200K tokens peut techniquement la gérer — mais la qualité des tests aux niveaux inférieurs chute à cause du « bruit » des niveaux supérieurs. La décomposition par niveaux réduit la charge à 8–15K tokens par requête — et la qualité s'améliore drastiquement.

Comment l'Assistant IA Utilise les Niveaux de la Pyramide

Dans le système QA Assist, chaque niveau de test est géré par un agent dédié. L'architecture ressemble à ceci :

• Agent Unit/API — reçoit la spécification d'un endpoint ou d'un composant. Génère des tests unitaires et des tests API couvrant les valeurs limites, les scénarios négatifs et les vérifications de compatibilité ascendante.
• Agent Système — reçoit la description de la User Story et les interfaces des composants impliqués. Génère des tests système qui vérifient l'intégration et les scénarios utilisateur.
• Agent E2E — reçoit la carte de la Feature et les statuts des User Stories. Génère des tests de bout en bout qui vérifient la cohérence des données entre systèmes.

Le point clé est que le contexte de chaque agent est strictement limité à son niveau. L'agent unitaire ne connaît pas le panneau d'administration. L'agent système ne voit pas l'historique des commandes. Ce n'est pas une limitation — c'est une optimisation adaptée aux capacités du LLM.

Exemples Concrets : Ce que l'IA Génère à Chaque Niveau

Prenons une Task : API back-end pour appliquer un code promo (POST /orders/apply-promo).

Ce que Reçoit l'Agent Unit/API :

• Spécification de l'endpoint (paramètres d'entrée, champs de sortie, codes d'erreur).
• Règles métier pour le calcul de remise (montant fixe, pourcentage, remises combinées).
• Contraintes (limites d'utilisation, dates d'expiration, restrictions géographiques).

Ce que Génère l'Agent :

# 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()

Prenons maintenant une User Story : « User applies promo code during order checkout ».

Ce que Reçoit l'Agent Système :

• Description du scénario (l'utilisateur ajoute un article, saisit le code promo, voit la remise, complète la commande).
• Interfaces front-end et back-end (formulaire de saisie, appels API, affichage du total).
• Exigences UX (validation côté client, messages d'erreur, états de chargement).

Ce que Génère l'Agent :

// 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');
});

Pourquoi les LLM Peinent Plus aux Niveaux Supérieurs

Les modèles de langage montrent une dégradation prévisible de la qualité lorsqu'ils gèrent des abstractions de haut niveau :

• Niveau Feature/E2E — nécessite de comprendre une logique métier souvent non formalisée explicitement. Le modèle doit faire des hypothèses qui peuvent être incorrectes.
• Niveau Système/User Story — mieux, mais exige encore d'intégrer des connaissances de multiples sources (front-end, back-end, UX).
• Niveau Task/Unitaire — parfaitement adapté aux forces du LLM : spécifications claires, règles formelles, entrées/sorties prévisibles.

Règle empirique : plus le niveau de la pyramide est bas, plus la précision de génération de tests par l'assistant IA est élevée. En pratique, cela signifie :

• Pour les tests Unit/API — faire confiance à l'IA presque complètement (couverture 90–95 %).
• Pour les tests Système — effectuer des revues, surtout pour les intégrations complexes (couverture 70–80 %).
• Pour les tests E2E — utiliser l'IA seulement pour générer des brouillons nécessitant une refinement humaine significative (couverture 50–60 %).

Retours d'Architecture pour les Assistants IA

Si vous construisez un système IA pour la génération de tests, ignorer la pyramide des tests est une recette pour l'échec. Voici les principes clés intégrés dans QA Assist :

• Décomposition par Niveaux — obligatoire. Pas de prompts déversant toute la Feature d'un coup.
• Contexte Isolé — chaque agent travaille uniquement avec son niveau. Les informations transmises entre niveaux via des données structurées, pas via du contexte textuel.
• Humain dans la Boucle — surtout aux niveaux supérieurs. L'IA génère un brouillon ; les humains raffinent et approuvent.
• Boucle de Rétroaction — les résultats d'exécution des tests servent à affiner les agents. Si l'IA rate un cas limite, il est ajouté à l'ensemble d'entraînement.

Sans ces principes, même le LLM le plus puissant produira des tests qui semblent plausibles mais échouent à détecter les vrais bugs.

Points Clés

• La pyramide des tests n'est pas juste une méthodologie — c'est une exigence technique pour des assistants IA efficaces.
• La fenêtre de contexte du LLM empêche physiquement de traiter des Features complexes en entier sans perte de qualité.
• La décomposition par niveaux (Task → User Story → Feature) est la seule façon de produire des tests de qualité à tous les niveaux.
• L'IA excelle aux niveaux inférieurs de la pyramide (Unit/API) et peine plus aux supérieurs (E2E).
• Les humains restent essentiels, particulièrement pour reviewer et raffiner les tests Système et E2E.

— Editorial Team