Piramida testowania dla asystentów AI w QA

Piramida testowania jako ograniczenie architektoniczne dla asystentów AI w QA

Gdy model językowy staje się projektantem testów, klasyczna piramida testowania przestaje być rekomendacją — staje się sztywnym wymogiem technicznym. Powód jest prosty: okno kontekstowe LLM fizycznie nie pomieści pełnego opisu złożonego Feature z dziesiątkami User Stories i Tasks. Próba „wrzucenia wszystkiego naraz" prowadzi do utraty jakości lub całkowitego niepowodzenia generacji.

Dlaczego piramida rozwiązuje problem kontekstu

Piramida testowania proponuje naturalny sposób dekompozycji. Zamiast obciążać model opisem całego rozwiązania IT, pracujesz z poziomami:

• Poziom Task (komponentowy) — tylko kontrakt API i reguły biznesowe jednego mikrousługi.
• Poziom User Story (systemowy) — integracja frontendu i backendu w ramach jednej systemu informacyjnej.
• Poziom Feature (E2E) — interakcje między systemami i procesy biznesowe end-to-end.

Każdy poziom wymaga własnego kontekstu. I każdy mieści się w limitach LLM, jeśli podajesz go izolowanie. To nie teoria — to praktyczna konieczność.

Przykład: Feature „Promokody przy składaniu zamówienia" składa się z trzech User Stories i dziewięciu Tasks. Pełny opis z makietami, specyfikacjami API i danymi testowymi zajmuje ~150K tokenów. Claude 3 Opus z oknem 200K tokenów formalnie sobie poradzi — ale jakość testów na niższych poziomach spadnie z powodu „szumu" z wyższych. Podział na poziomy redukuje obciążenie do 8–15K tokenów na zapytanie — i jakość gwałtownie rośnie.

Jak asystent AI wykorzystuje poziomy piramidy

W systemie QA Assist każdy poziom testowania jest obsługiwany przez oddzielnego agenta. Architektura wygląda następująco:

• Agent Unit/API — otrzymuje specyfikację jednego endpointu lub komponentu. Generuje testy jednostkowe i API z wartościami brzegowymi, negatywnymi scenariuszami, sprawdzaniem kompatybilności wstecznej.
• Agent System — otrzymuje opis User Story i interfejsy zaangażowanych komponentów. Generuje testy systemowe sprawdzające integrację i scenariusze użytkownika.
• Agent E2E — otrzymuje mapę Feature i statusy User Stories. Generuje testy end-to-end sprawdzające spójność danych między systemami.

Kluczowy moment — kontekst każdego agenta jest ograniczony do jego poziomu. Agent Unit nie wie nic o panelu administracyjnym. Agent System nie widzi historii zamówień. To nie wada — to optymalizacja pod możliwości LLM.

Konkretne przykłady: co generuje AI na każdym poziomie

Weźmy Task: backendowe API do zastosowania promokodu (POST /orders/apply-promo).

Co otrzymuje agent Unit/API:

• Specyfikację endpointu (parametry wejściowe, pola wyjściowe, kody błędów).
• Reguły biznesowe obliczania zniżki (stała kwota, procent, kombinowane zniżki).
• Ograniczenia (limity użycia, termin ważności, ograniczenia geograficzne).

Co generuje agent:

# Przykład wygenerowanego testu
@pytest.mark.parametrize("promo_code, expected_discount", [
    ("SALE10", 10.0),      # Procentowa zniżka
    ("FIXED50", 50.0),     # Stała kwota
    ("COMBO", 60.0),       # Kombinowana (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()

Teraz weźmy User Story: „Użytkownik stosuje promokod przy składaniu zamówienia".

Co otrzymuje agent System:

• Opis scenariusza (użytkownik dodaje produkt, wpisuje promokod, widzi zniżkę, składa zamówienie).
• Interfejsy frontendu i backendu (formularz wejściowy, wywołania API, wyświetlanie kwoty).
• Wymagania UX (walidacja po stronie klienta, komunikaty błędów, stany ładowania).

Co generuje agent:

// Przykład testu Playwright
 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');
  
  // Sprawdzamy wyświetlanie zniżki
  await expect(page.locator('.discount-amount')).toHaveText('-10%');
  
  // Sprawdzamy przeliczenie kwoty końcowej
  const originalTotal = await page.locator('.original-total').innerText();
  const discountedTotal = await page.locator('.final-total').innerText();
  expect(parseFloat(discountedTotal)).toBeLessThan(parseFloat(originalTotal));
  
  // Składamy zamówienie
  await page.click('#checkout-button');
  await expect(page).toHaveURL('/order-confirmation');
});

Dlaczego LLM gorzej radzi sobie z wyższymi poziomami

Modele językowe wykazują przewidywalny spadek jakości przy pracy z wysokopoziomowymi abstrakcjami:

• Poziom Feature/E2E — wymaga zrozumienia logiki biznesowej, która często nie jest sformalizowana jawnie. Model musi robić założenia, które mogą być błędne.
• Poziom System/User Story — lepiej, ale nadal wymaga integracji wiedzy z kilku źródeł (frontend, backend, UX).
• Poziom Task/Unit — idealnie pasuje do mocnych stron LLM: jasne specyfikacje, formalne reguły, przewidywalne wejścia/wyjścia.

Empiryczna reguła: im niżej w piramidzie, tym wyższa dokładność generowania testów przez asystenta AI. W praktyce oznacza to:

• Dla testów Unit/API — ufaj AI prawie w pełni (90–95% pokrycia).
• Dla testów System — przeprowadzaj rewizję, zwłaszcza dla złożonych integracji (70–80% pokrycia).
• Dla testów E2E — używaj AI tylko do generowania szkiców wymagających poważnej obróbki przez człowieka (50–60% pokrycia).

Architektoniczne wnioski dla asystentów AI

Jeśli budujesz system AI do generowania testów, ignorowanie piramidy testowania to skazanie go na porażkę. Oto kluczowe zasady, które zaimplementowaliśmy w QA Assist:

• Dekompozycja na poziomy — obowiązkowa. Żadnych „promptów z całym Feature naraz".
• Izolowany kontekst — każdy agent pracuje tylko ze swoim poziomem. Przekazywanie informacji między poziomami — przez dane strukturalne, nie przez kontekst tekstowy.
• Człowiek w pętli — zwłaszcza na wyższych poziomach. AI generuje szkic, człowiek dopracowuje i zatwierdza.
• Informacja zwrotna — wyniki wykonywania testów służą do dalszego uczenia agentów. Jeśli AI pominął przypadek brzegowy — ten przypadek trafia do zbioru treningowego.

Bez tych zasad nawet najpotężniejszy LLM będzie generował testy, które wyglądają wiarygodnie, ale nie wykrywają prawdziwych błędów.

Co ważne

• Piramida testowania — to nie tylko metodologia, ale techniczny wymóg dla efektywnej pracy asystentów AI.
• Okno kontekstowe LLM fizycznie uniemożliwia przetwarzanie złożonych Feature w całości bez utraty jakości.
• Dekompozycja na poziomy (Task → User Story → Feature) — jedyny sposób na uzyskanie jakościowych testów na wszystkich poziomach.
• AI najlepiej radzi sobie z dolnymi poziomami piramidy (Unit/API), gorzej — z górnymi (E2E).
• Człowiek pozostaje kluczowym elementem, zwłaszcza przy rewizji i dopracowywaniu testów na poziomach systemowym i E2E.

— Editorial Team