Výhody a nevýhody automatizovaného testování
Automatizace testů není odpovědí na všechno. Jedné firmě ušetří několik pracovních dnů měsíčně, ve druhé se investice nemusí vrátit – a rozdíl nespočívá v tom, která z nich je „modernější“. Tento text není prodejní leták. Je to vyvážený pohled na to, co automatizace přinese a co hovoří proti ní, abyste se mohli rozhodnout sami. Záměrně bez konkrétních částek – ty závisí na vašem případu a sdělíme je, až ho společně projdeme.
Co může automatizace přinést
Rychlejší zpětná vazba. Pokud manuální regresní testování trvá několik pracovních dnů, vhodně navržená automatizovaná sada ho může výrazně zkrátit také díky souběžným běhům. Výsledný čas závisí na rozsahu, prostředí a konfiguraci, release však nemusí čekat na dokončení celé ruční kontroly.
Testy mohou běžet při každé relevantní změně. Po zapojení do CI/CD se vybrané kontroly mohou spouštět automaticky při buildu, pull requestu nebo před releasem. Frekvenci je třeba nastavit podle délky běhů, rizika a nákladů na infrastrukturu.
Opakovatelný postup. Automatizovaný test provádí naprogramované kroky konzistentně. Výsledek však stále může ovlivnit testovací prostředí, data nebo chyba v samotném testu, proto potřebuje údržbu a vyhodnocování.
Chybu můžete odhalit dříve. Problém odhalený před nasazením se obvykle řeší s menším dopadem; výsledné náklady však závisí na příčině a fázi vývoje.
Tester dělá to, co stroj nedokáže. Průzkumné testování, záludné hraniční případy, posouzení použitelnosti – tam je hodnota člověka, nikoli v proklikávání stejného formuláře podvacáté. Automatizace mu pro tyto úkoly uvolní ruce.
Dohledatelný výsledek testu. Podle zvoleného nástroje a konfigurace může být součástí běhu přehledný report, snímek obrazovky, video nebo technická stopa. Tyto výstupy dokumentují průběh a výsledek konkrétní kontroly; samy o sobě však nedokazují bezchybnost celého produktu.
Běžné problémy a omezení automatizace
Platíte předem. Sadu je třeba nejprve vybudovat. Úspora přichází až potom – do té doby jde o čistý náklad. Pokud hledáte výsledek na příští týden, automatizace není rychlou zkratkou.
Testy je třeba udržovat. Když se aplikace mění, mění se také sada. Údržba není drobným písmem pod čarou, je to trvalá položka – a pokud se zanedbá, sada postupně přestane fungovat.
Ne všechno se vyplatí automatizovat. Scénář, který spustíte dvakrát ročně, se zpravidla nezaplatí. Kritická cesta kontrolovaná při každém releasu je silnějším kandidátem než snaha o úplné pokrytí za každou cenu. Podrobněji o tom píšeme v tématu co se nevyplatí automatizovat.
Nespolehlivá sada může snížit důvěru v testování. Pokud testy často selhávají bez chyby v produktu, tým může začít výsledky přehlížet a čas věnovaný jejich vyhodnocování roste. Proto na kvalitě záleží už při návrhu; a pokud takovou sadu už máte, lze ji opravit.
Jak to řešit: podle čeho se rozhodnout
Rozhodnutí nestojí na jediném čísle, ale na čtyřech otázkách:
- Jak často vydáváte releasy? Vyšší četnost znamená více příležitostí test použít a získat z něj zpětnou vazbu. Více se dozvíte v tématu kdy se vyplatí automatizovat.
- Jak velký je rozsah regresního testování? Desítky scénářů proklikávaných před každým releasem jsou silnějším argumentem než několik krátkých kontrol.
- Jak stabilní je rozhraní? Ustálená aplikace se obvykle automatizuje snáze. U přepisovaného rozhraní může být rozumnější dočasně zúžit UI scénáře a více ověřovat na stabilnějších nižších úrovních.
- Kolik stojí chyba? U plateb, objednávek nebo dat může vyšší dopad chyby odůvodnit automatizaci i při menším počtu opakování.
Co vám vyvážené rozhodnutí přinese
Když vše zvážíte z obou stran, výsledek bývá jasnější, než se zdá. Buď zjistíte, že máte silné argumenty pro automatizaci – a potom se vyplatí začít kritickými cestami. Nebo zjistíte, že vám zatím nevychází, a ušetříte si investici do něčeho, co by zůstalo ležet ladem. Obě odpovědi jsou platné.
Další krok
Pokud to budete chtít probrat konkrétně, ozvěte se nám: projdeme vaše regresní scénáře a pomůžeme vám odhadnout, zda se automatizace v současnosti vyplatí.