Pyramida testování pro AI asistenty v QA

# Testovací pyramida jako architektonické omezení pro AI asistenty v QA

Když se jazykový model stane návrhářem testů, klasická testovací pyramida přestává být doporučením – stává se tvrdým technickým požadavkem. Důvod je jednoduchý: kontextové okno LLM fyzicky nepojme úplný popis složitého Feature s desítkami User Stories a Tasks. Pokus „nakrmit vše najednou“ vede ke ztrátě kvality nebo úplnému selhání generování.

Proč pyramida řeší problém kontextu

Testovací pyramida nabízí přirozený způsob dekompozice. Místo aby se model zahltil popisem celého IT řešení, pracujete s úrovněmi:

• Úroveň Task (komponentová) – pouze API kontrakt a obchodní pravidla jednoho mikroslužby.
• Úroveň User Story (systémová) – integrace frontendu a backendu v rámci jedné informačního systému.
• Úroveň Feature (E2E) – interakce mezi systémy a průchodové obchodní procesy.

Každá úroveň vyžaduje svůj vlastní kontext. A každá se vejde do limitů LLM, pokud ji podáváte izolováně. To není teorie – je to praktická nutnost.

Příklad: Feature „Přímokódy při objednávce“ se skládá ze tří User Stories a devíti Tasks. Úplný popis s maketami, API specifikacemi a testovacími daty zabírá ~150K tokenů. Claude 3 Opus s oknem 200K tokenů to formálně zvládne – ale kvalita testů na nižších úrovních klesne kvůli „šumu“ z vyšších. Rozbití podle úrovní snižuje zátěž na 8–15K tokenů na požadavek – a kvalita rapídně stoupne.

Jak AI asistent využívá úrovně pyramidy

V systému QA Assist se každá úroveň testování zpracovává samostatným agentem. Architektura vypadá takto:

• Agent Unit/API – obdrží specifikaci jednoho endpointu nebo komponenty. Generuje unit testy a API testy s hraničními hodnotami, negativními scénáři, kontrolou zpětné kompatibility.
• Agent System – obdrží popis User Story a rozhraní zapojených komponent. Generuje systémové testy kontrolující integraci a uživatelské scénáře.
• Agent E2E – obdrží mapu Feature a stavy User Stories. Generuje průchodové testy kontrolující konzistenci dat mezi systémy.

Klíčový moment – kontext každého agenta je omezen na jeho úroveň. Agent Unit nezná admin panel. Agent System nevidí historii objednávek. To není nedostatek – je to optimalizace podle možností LLM.

Konkrétní příklady: co generuje AI na každé úrovni

Vezměme Task: Back-end API pro aplikaci přímokódu (POST /orders/apply-promo).

Co agent Unit/API obdrží:

• Specifikaci endpointu (vstupní parametry, výstupní pole, chybové kódy).
• Obchodní pravidla výpočtu slevy (fixní částka, procento, kombinované slevy).
• Omezení (limity použití, platnost, geografická omezení).

Co agent generuje:

# Příklad vygenerovaného testu
@pytest.mark.parametrize("promo_code, expected_discount", [
    ("SALE10", 10.0),      # Procentní sleva
    ("FIXED50", 50.0),     # Fixní částka
    ("COMBO", 60.0),       # Kombinovaná (10% + 50 Kč)
])
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()

Teď vezměme User Story: „Uživatel aplikuje přímokód při objednávce“.

Co agent System obdrží:

• Popis scénáře (uživatel přidá zboží, zadá přímokód, uvidí slevu, objedná).
• Rozhraní frontendu a backendu (formulář zadání, API volání, zobrazení částky).
• Požadavky na UX (validace na klientovi, chybové zprávy, stavy načítání).

Co agent generuje:

// Příklad Playwright testu
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');
  
  // Kontrolujeme zobrazení slevy
  await expect(page.locator('.discount-amount')).toHaveText('-10%');
  
  // Kontrolujeme přepočet celkové částky
  const originalTotal = await page.locator('.original-total').innerText();
  const discountedTotal = await page.locator('.final-total').innerText();
  expect(parseFloat(discountedTotal)).toBeLessThan(parseFloat(originalTotal));
  
  // Objednáme
  await page.click('#checkout-button');
  await expect(page).toHaveURL('/order-confirmation');
});

Proč LLM horší zvládá vyšší úrovně

Jazykové modely vykazují předvídatelný pokles kvality při práci s vysoceúrovňovými abstrakcemi:

• Úroveň Feature/E2E – vyžaduje porozumění obchodní logice, která často není explicitně formalizována. Model musí dělat předpoklady, které mohou být chybné.
• Úroveň System/User Story – lepší, ale stále vyžaduje integraci znalostí z více zdrojů (frontend, backend, UX).
• Úroveň Task/Unit – ideálně vyhovuje silným stránkám LLM: jasné specifikace, formální pravidla, předvídatelné vstupy/výstupy.

Empirické pravidlo: čím níže v pyramidě, tím vyšší přesnost generování testů AI asistentem. V praxi to znamená:

• Pro Unit/API testy – důvěřujte AI téměř úplně (90–95 % pokrytí).
• Pro systémové testy – proveďte revizi, zejména u složitých integrací (70–80 % pokrytí).
• Pro E2E testy – používejte AI jen na generování nástinů, které vyžadují seriózní úpravy člověkem (50–60 % pokrytí).

Architektonické závěry pro AI asistenty

Pokud stavíte AI systém pro generování testů, ignorovat testovací pyramidu znamená odsoudit ho k selhání. Zde jsou klíčové principy, které jsme implementovali v QA Assist:

• Dekompozice podle úrovní – povinná. Žádné „promptů se vším Feature najednou“.
• Izolovaný kontext – každý agent pracuje jen se svou úrovní. Předávání informací mezi úrovněmi probíhá strukturovanými daty, ne textovým kontextem.
• Člověk v smyčce – zejména na vyšších úrovních. AI generuje nástin, člověk ho upraví a schválí.
• Zpětná vazba – výsledky provedení testů se používají k doladění agentů. Pokud AI přehlédne hraniční případ – tento případ se přidá do tréninkové sady.

Bez těchto principů i nejsilnější LLM produkuje testy, které vypadají věrohodně, ale nenacházejí skutečné chyby.

Co je důležité

• Testovací pyramida – není jen metodologie, ale technický požadavek pro efektivní práci AI asistentů.
• Kontextové okno LLM fyzicky neumožňuje zpracovávat složité Features celé bez ztráty kvality.
• Dekompozice podle úrovní (Task → User Story → Feature) – jediný způsob, jak získat kvalitní testy na všech úrovních.
• AI nejlépe zvládá nižší úrovně pyramidy (Unit/API), hůře vyšší (E2E).
• Člověk zůstává klíčovým elementem, zejména pro revizi a úpravy testů na systémové a E2E úrovních.

— Editorial Team