Kolik testů stačí? Testovací pyramida bez dogmatu
Otázka „kolik testů potřebujeme“ nemá jako odpověď jedno číslo. Sada s tisícovkou testů může být horší než sada se dvěma sty – pokud ta tisícovka běží tři hodiny, pravidelně selhává a nikdo její výsledky nečte. Podstatná není velikost sady, ale to, na jaké úrovni se jednotlivé věci ověřují.
Testovací pyramida je jednoduchý model vrstvení testů. Ve zjednodušené podobě rozlišuje jednotkové, integrační nebo API a UI testy. Větší podíl kontrol má být na nižších, zpravidla rychlejších úrovních a menší na nákladnějších koncových scénářích. Nejde o pevný poměr, ale o pomůcku při návrhu sady.
Běžné problémy, které je třeba vyřešit
Častým důvodem vysoké ceny a pomalých běhů je, že sada ověřuje příliš mnoho věcí přes uživatelské rozhraní.
Je to pochopitelné. UI test se blíží tomu, co dělá zákazník, a při jeho návrhu nemusíte znát všechny vnitřní detaily aplikace. Takový test však často musí spustit prohlížeč, připravit uživatele a data, projít více obrazovek a čekat na vykreslení. Bývá pomalejší a citlivější na síť, data či rozložení stránky – a může ho ovlivnit také změna, která funkčně nic nemění.
Pokud potom ověřujete dvacet kombinací slevového kuponu tak, že pokaždé proklikáte celý nákupní košík, výsledkem může být dlouhý běh a vysoké náklady na údržbu.
Jak to řešit: co patří na kterou úroveň
Jednotkové testy – výpočty a pravidla. Patří sem izolované části logiky, například výpočet ceny, DPH, slev, validace formátů či přechody mezi stavy. Obvykle poskytují rychlou zpětnou vazbu a tým jich může mít mnoho. Píší je především vývojáři, ale do strategie patří – protože mnoho pravidel lze levněji a přesněji ověřit právě zde.
API testy – chování systému. Vytvoření objednávky, změna stavu, oprávnění, reakce na neplatný vstup či zpracování chyb. Tato úroveň často nabízí dobrý poměr přínosu a ceny: test zpravidla běží rychleji než stejná kontrola přes uživatelské rozhraní a redesign ho ovlivní méně. Mnoho kombinací a okrajových případů lze účelněji ověřit zde než v prohlížeči. Více se dozvíte v tématu API testy.
UI testy – ověření, že vše drží pohromadě. Přes rozhraní ověřujte především reprezentativní cesty, nikoli každou kombinaci. Zákazník se přihlásí, najde zboží, objedná a zaplatí; další scénář může pokrývat registraci nebo klíčový formulář. Počet a hloubku těchto testů přizpůsobte riziku a rozsahu důležitých uživatelských cest.
Proto má model tvar pyramidy: více rychlých a izolovaných kontrol dole, méně komplexních koncových scénářů nahoře.
Bez dogmatu
Pyramida je pomůcka, nikoli zákon. Přesné poměry si nemusíte pamatovat, důležité je pravidlo: ověřujte na nejnižší úrovni, na které to lze ověřit.
Existují případy, kdy to neplatí doslova. Pokud je vaše aplikace především rozhraním nad cizími systémy a má málo vlastní logiky, jednotkových testů bude přirozeně málo a těžiště se přesune k integračním a API testům. Pokud dodáváte produkt, u kterého je kritický vzhled a rozložení, část práce převezme vizuální porovnávání. A pokud už máte velkou UI sadu, která funguje, není důvod ji zahodit – důvodem je nepřidávat do ní další kombinace, které patří níže.
Co vám vhodné rozložení testů přinese
Vhodnější rozložení může zkrátit běhy, snížit počet nestabilních výsledků a omezit náklady na údržbu. Rychlejší zpětná vazba zároveň zvyšuje šanci, že tým bude výsledky testů používat při každodenní práci.
Při návrhu strategie proto nejprve rozdělíme, co se má ověřovat kde. Pokud lze část kombinací přesunout z UI na API nebo jednotkovou úroveň, může to přinést výraznou úsporu času při bězích i údržbě.
Další krok
Pošlete nám informace o tom, co dnes vaše testy pokrývají a jak dlouho trvá regresní testování, a ozvěte se nám. Navrhneme, co ověřovat na nižší úrovni, co ponechat přes UI a která rizika dnes nemají přiměřené pokrytí.