Testpyramide für KI-Assistenten in QA

Testpyramide als architektonische Einschränkung für KI-Assistenten in der QA

Wenn ein Sprachmodell zum Test-Designer wird, hört die klassische Testpyramide auf, nur eine Empfehlung zu sein – sie wird zu einer strengen technischen Anforderung. Der Grund ist einfach: Das Kontextfenster des LLM kann physisch keine vollständige Beschreibung einer komplexen Feature mit Dutzenden User Stories und Tasks aufnehmen. Der Versuch, „alles auf einmal zu füttern“, führt zu einem Qualitätsabfall oder vollständigem Generierungsversagen.

Warum die Pyramide das Kontextproblem löst

Die Testpyramide bietet einen natürlichen Weg, Aufgaben zu zerlegen. Statt das Modell mit der Beschreibung der gesamten IT-Lösung zu beladen, arbeiten Sie mit Ebenen:

• Task-Ebene (Component) – nur der API-Vertrag und die Geschäftsregeln für einen Microservice.
• User-Story-Ebene (System) – Front-End- und Back-End-Integration innerhalb eines Informationssystems.
• Feature-Ebene (E2E) – Interaktionen zwischen Systemen und End-to-End-Geschäftsprozesse.

Jede Ebene benötigt ihren eigenen Kontext. Und jede passt in die LLM-Limits, wenn sie isoliert bereitgestellt wird. Das ist keine Theorie – es ist eine praktische Notwendigkeit.

Beispiel: Die Feature „Promo Codes During Order Checkout“ umfasst drei User Stories und neun Tasks. Die vollständige Beschreibung inklusive Mockups, API-Spezifikationen und Testdaten umfasst ~150K Tokens. Claude 3 Opus mit seinem 200K-Token-Fenster kann das technisch handhaben – aber die Testqualität auf unteren Ebenen leidet unter dem „Rauschen“ aus höheren Ebenen. Die Aufschlüsselung nach Ebenen reduziert die Belastung auf 8–15K Tokens pro Anfrage – und die Qualität steigt dramatisch.

Wie der KI-Assistent die Pyramidebenen nutzt

Im QA-Assist-System wird jede Testebene von einem dedizierten Agenten bearbeitet. Die Architektur sieht so aus:

• Unit/API-Agent – erhält die Spezifikation für einen Endpoint oder eine Komponente. Generiert Unit-Tests und API-Tests, die Randwerte, negative Szenarien und Rückwärtskompatibilitätsprüfungen abdecken.
• System-Agent – erhält die User-Story-Beschreibung und die Schnittstellen der beteiligten Komponenten. Generiert System-Tests, die Integration und Benutzerszenarien prüfen.
• E2E-Agent – erhält die Feature-Karte und den Status der User Stories. Generiert End-to-End-Tests, die Datenkonsistenz über Systeme hinweg prüfen.

Der Schlüssel ist, dass der Kontext jedes Agents streng auf seine Ebene beschränkt ist. Der Unit-Agent kennt kein Admin-Panel. Der System-Agent sieht keine Bestellhistorie. Das ist keine Einschränkung – es ist eine Optimierung, die auf LLM-Fähigkeiten zugeschnitten ist.

Konkrete Beispiele: Was die KI auf jeder Ebene generiert

Nehmen wir eine Task: Back-End-API zum Anwenden eines Promo-Codes (POST /orders/apply-promo).

Was der Unit/API-Agent erhält:

• Endpoint-Spezifikation (Eingabeparameter, Ausgabefelder, Fehlercodes).
• Geschäftsregeln für Rabattberechnung (festgelegter Betrag, Prozentsatz, kombinierte Rabatte).
• Einschränkungen (Nutzungslimits, Verfallsdaten, geografische Restriktionen).

Was der Agent generiert:

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

Nehmen wir eine User Story: „Benutzer wendet Promo-Code während des Bestellabschlusses an“.

Was der System-Agent erhält:

• Szenariobeschreibung (Benutzer fügt Artikel hinzu, gibt Promo-Code ein, sieht Rabatt, schließt Bestellung ab).
• Front-End- und Back-End-Schnittstellen (Eingabeformular, API-Aufrufe, Gesamtsumme-Anzeige).
• UX-Anforderungen (Client-seitige Validierung, Fehlermeldungen, Ladezustände).

Was der Agent generiert:

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

Warum LLMs bei oberen Ebenen mehr kämpfen

Sprachmodelle zeigen einen vorhersehbaren Qualitätsabfall bei der Bewältigung hochrangiger Abstraktionen:

• Feature/E2E-Ebene – erfordert Verständnis von Geschäftslogik, die oft nicht explizit formalisiert ist. Das Modell muss Annahmen treffen, die falsch sein können.
• System/User-Story-Ebene – besser, aber erfordert immer noch Integration von Wissen aus mehreren Quellen (Front-End, Back-End, UX).
• Task/Unit-Ebene – ideal auf LLM-Stärken abgestimmt: klare Spezifikationen, formale Regeln, vorhersehbare Eingaben/Ausgaben.

Empirische Regel: Je niedriger die Pyramideebene, desto höher die Genauigkeit der Testgenerierung durch den KI-Assistenten. In der Praxis bedeutet das:

• Für Unit/API-Tests – der KI fast vollständig vertrauen (90–95% Abdeckung).
• Für System-Tests – Reviews durchführen, besonders bei komplexen Integrationen (70–80% Abdeckung).
• Für E2E-Tests – KI nur für die Generierung von Entwürfen nutzen, die erhebliche menschliche Nachbearbeitung brauchen (50–60% Abdeckung).

Architektonische Erkenntnisse für KI-Assistenten

Wenn Sie ein KI-System für Testgenerierung bauen, ist das Ignorieren der Testpyramide ein Rezept für Misserfolg. Hier die Schlüsselpunkte, die wir in QA Assist integriert haben:

• Zerlegung nach Ebenen – obligatorisch. Keine Prompts, die die gesamte Feature auf einmal laden.
• Isolierter Kontext – jeder Agent arbeitet ausschließlich mit seiner Ebene. Informationen zwischen Ebenen werden über strukturierte Daten weitergegeben, nicht über textuellen Kontext.
• Mensch im Loop – besonders auf oberen Ebenen. KI erzeugt einen Entwurf; Menschen verfeinern und genehmigen.
• Feedback-Loop – Testergebnisse dienen zur Feinabstimmung der Agents. Wenn die KI einen Randfall verpasst, wird er ins Training aufgenommen.

Ohne diese Prinzipien produziert selbst das leistungsstärkste LLM Tests, die plausibel wirken, aber echte Bugs nicht fangen.

Wichtige Erkenntnisse

• Die Testpyramide ist nicht nur eine Methodik – sie ist eine technische Anforderung für effektive KI-Assistenten.
• Das LLM-Kontextfenster verhindert physisch die Verarbeitung komplexer Features in voller Länge ohne Qualitätsverlust.
• Zerlegung nach Ebenen (Task → User Story → Feature) ist der einzige Weg, qualitativ hochwertige Tests auf allen Ebenen zu erzeugen.
• KI glänzt bei unteren Pyramidebenen (Unit/API) und hat bei oberen (E2E) mehr Probleme.
• Menschen bleiben essenziell, insbesondere für die Überprüfung und Verfeinerung von System- und E2E-Tests.

— Editorial Team