Testovací dluh

Testovací dluh (z anglického test debt) je forma technického dluhu, která vzniká, když tým:

• nedodělá potřebné testy,
• píše špatné, nedostatečné nebo nespolehlivé testy,
• nebo odkládá automatizaci testů kvůli časovému tlaku.

Na rozdíl od kódu, který „funguje“, testovací dluh sníží důvěru v kvalitu systému, zpomaluje vývoj a zvyšuje riziko regresí (návratu již opravených chyb).

Pojem vychází z analogie s technickým dluhem (Ward Cunningham, 1992), ale konkrétně se zaměřuje na testovací strategii a pokrytí. Testovací dluh se často akumuluje v raných fázích projektu, kdy tým „zrychluje vývoj“ tím, že testy ignoruje – což se později vyplácí náklady na ladění, manuální testování a nestabilitu systému.

• Zpomalení vývoje: Vývojáři se bojí měnit kód, protože nevědí, co porouchají.
• Časté regrese: Chyby se vrací, protože nejsou zachyceny testy.
• Nízká důvěra v automatizaci: Tým začne testy ignorovat nebo je označovat jako „označené k přeskočení“.
• Zvýšené náklady na QA: Roste potřeba manuálního testování.
• Horší kvalita produktu: Do produkce se dostávají chyby, které by mohly být zachyceny dříve.
• Morální úpadek týmu: Vývojáři ztrácejí radost z kódování v „nepřehledném“ systému.

Přestože není možné ho přesně kvantifikovat jako finanční dluh, lze použít následující metriky:

• Test coverage – procento kódu pokrytého testy (např. pomocí JaCoCo, coverage.py).

⚠️ Varování: Vysoké pokrytí ≠ kvalitní testy! Může být 100 %, ale testovat jen „že kód běží“.

• Počet flaky testů – testů, které selhávají náhodně.
• Poměr typů testů – odchylka od testovací pyramidy (např. 80 % E2E, 5 % jednotkových).
• Manuální testovací scénáře – počet kritických scénářů bez automatizace.
• Stáří neotestovaného kódu – kolik dní/kommitů od posledního testovacího commitu.

• Testuj od prvního dne – i malý projekt by měl mít základní jednotkové testy.
• Dodržuj testovací pyramidu – většina testů by měla být jednotkových.
• Nepřijímej PR bez testů – zaved politiku „code coverage gate“ v CI.
• Refaktoruj testy – testy jsou kód; aplikuj na ně stejná pravidla (DRY, čitelnost).
• Pravidelně odstraňuj flaky testy – buď je oprav, nebo odstraň.
• Plať dluh postupně – při každé úpravě kódu přidej testy pro danou komponentu („boy scout rule“).

• Prioritizuj kritické části – začni testováním modulů s nejvyšším rizikem (např. platby, autentizace).
• Použij „stratégii krabičky“ – pokud nemůžeš testovat jednotlivé funkce, otestuj celý modul jako „černou krabičku“.
• Zautomatizuj manuální scénáře – začni s nejčastějšími nebo nejrizikovějšími.
• Vytvoř „dluhový backlog“ – eviduj testovací dluh jako uživatelské příběhy v nástroji pro správu úloh (Jira, Trello).
• Naplánuj „sprint pro kvalitu“ – občas věnuj celý sprint odstranění dluhu.

💡 Testovací dluh je často součástí technického dluhu, ale vyžaduje specifický přístup.

• Technický dluh
• Testovací pyramida
• Jednotkový test
• Flaky test
• CI/CD
• Testovací coverage

• Martin Fowler – Test Debt: https://martinfowler.com/articles/is-quality-worth-cost.html
• Google Testing Blog – Flaky Tests: https://testing.googleblog.com/2017/04/where-do-our-flaky-tests-come-from.html
• IEEE – „The Real Cost of Test Debt“ (akademický článek)

• Testovací strategie
• QA v agilním týmu
• Refaktoring
• Behavior-Driven Development