Případová studie: Zavedení automatizačního testování pro rychlejší testování webové aplikace
Autor: Pavel Andrašší

Jaký problém byl na začátku? 

Manuální testování webové aplikace bylo příliš pomalé na to, aby pokrylo rostoucí nároky na rychlost doručování softwaru. Každé zpoždění v testovacím procesu nejen bránilo včasnému nasazení nových funkcionalit, ale také zvyšovalo riziko výskytu chyb v produkčním prostředí, protože do procesu vstupoval příliš silně lidský faktor a jeho chybovost. 
Tento stav vedl k omezené schopnosti rychle reagovat na zpětnou vazbu od uživatelů a ohrožoval spolehlivost produktu. 

Kdo ten problém pociťoval a co to způsobovalo? 

Problém nejvíce pociťovali testeři, kteří byli zodpovědní za opakované manuální kontroly jednotlivých částí aplikace. Kvůli zdlouhavému procesu docházelo k „bottle neckům“ v testovacích bězích, což opožďovalo doručování dalších verzí applikace.  
Kromě toho vývojáři museli čekat na dokončení manuálního testování, což zpomalovalo nasazování dalších změn. Tento cyklus zvyšoval tlak na tým a zpomaloval celkovou efektivitu.

Designový proces a metody 

Jak probíhalo řešení problému a návrh inovace? 

Na začátku byly zváženy různé možnosti, jak zlepšit rychlost a efektivitu testování. Byl proveden menší audit, jestli proces testování, nebo design samotných testů není nevhodný v kontextu toho jakou výzvu řešíme, což se ale nepotvrdilo.  
Následně mezi diskutovaná řešení patřilo rozšíření testovacího týmu o nové členy, outsourcing testů externím firmám nebo využití programátorů k pomocným testovacím aktivitám. 
Každá z těchto možností však přinášela významné nevýhody – od vysokých nákladů na personální rozšíření a složitostí spolupráce s externími partnery až po negativní dopad na vývojářský čas.  

Po podrobné analýze bylo rozhodnuto, že automatizace testů je nejlepší cestou k dosažení požadovaných cílů, neboť nabízí udržitelné a dlouhodobě efektivní řešení problému rychlosti a kvality testování.  
Tým se zaměřil na průzkum dostupných nástrojů, zahrnující moderní AI-driven a codeless řešení.  

Byla provedena podrobná analýza zaměřená na parametry, jako jsou cena, jednoduchá obsluha, implementace, kompatibilita s existujícím prostředím a dostupnost technické podpory jak ze stany produktu, nebo i komunity. Na základě těchto kritérií byl zvolen nástroj Cypress, který nabízel vyvážený poměr mezi jednoduchostí použití a robustními funkcemi.

Jaké metody byly použity? 

Analýza uživatelských potřeb: Identifikace klíčových oblastí aplikace důležitých pro funkční stabilitu a uživatelskou zkušenost. 

Porovnání nástrojů pomocí průzkumu a testování: Srovnání nástrojů jako Selenium, Playwright a Puppeteer na základě parametrů, jako jsou náklady, technické možnosti a jednoduchost použití. 

Iterativní implementace: Vytváření a vylepšování automatizačních skriptů na základě zpětné vazby. 

Pravidelná komunikace: Koordinace mezi testery a vývojáři pro zajištění hladké integrace nástroje a sdílení aktuálního stavu a problémů.

Specifika designu automatických testů 

Při návrhu automatických testů bylo nezbytné zohlednit rozdíly oproti manuálnímu testování. Zatímco lidský manuální test může provádět vizuální kontrolu a intuitivně odhadnout, zda aplikace funguje a vypadá správně, automatické testy tuto schopnost postrádají.  

Automatický test musí být pevně navázán na konkrétní prvky na stránce, aby mohl jednoznačně vyhodnotit, zda daný prvek existuje, nebo chybí. To vyžaduje důkladný design každého testu s ohledem na strukturu a architekturu aplikace, včetně definice jasných podmínek pro úspěch nebo selhání testu. 

Z výše uvedeného vyplívá, že pro kontrolu visuálních prvků v aplikaci je automatizační test ne moc nevhodný.

Kategorizace typu testů podle priorit

Bylo nutno v rámci časových a kapacitní odhadů vytvořit i hrubý nákres toho v jakém pořadí, jaká kategorie testů bude vytvářena. To nám umožnilo lépe plánovat, protože každý z typů testů má jinou šířku a hloubku.

1. Průchod aplikací (Smoke testy) 
2. Funkční testy 
3. Negativní scénáře 
4. Testy detailů (např. texty, grafické prvky)

Kategorizace smoke-testů podle priorit/komplexity

Některé testovací scénáře jsou těžko odhadnutelné z pohledu komplexity, protože zatím není vybrán finální testovací framework/nástroj, nebylo možno odzkoušet co vše lze nástrojem testovat a některé testy vyžadují vizuální kontrolu různých prvků – test design se bude muset upravit, nebo některé části testu vynechat.


Příklad designu a rozdílnosti manuálního a automatizačního testu 
Manuální test na registraci farmy ve webové aplikaci:

  

 
Následná automatizace:

 
 

Co bylo výstupem? Jaké byly výsledky? 

Jaká inovace vznikla? 

Automatizační testování pomocí Cypressu přineslo efektivnější testování klíčových funkcí aplikace.  
Byly zavedeny regresní testy, které se automaticky spouštějí při každé změně kódu, a automatické reporty s výsledky testů byly sdíleny v reálném čase přes Slack a JIRA. Implementace zahrnovala funkční testy, smoke testy a end-to-end testování, které zajistily komplexní pokrytí.

Komu inovace pomohla a jak? 

Automatizace ušetřila testerům čas, který mohli využít na komplexnější úkoly a jiné zapeklité problémy.  
Vývojáři dostávali rychlejší zpětnou vazbu, což zlepšilo efektivitu jejich práce a urychlilo nasazování změn.  
Uživatelé aplikace ocenili rychlejší aktualizace a vyšší stabilitu softwaru.  
Projektový manažer měl k dispozici lepší přehled o výsledcích a průběhu testování. 

Jaké je poučení z procesu? 

Co se tým naučil? 

Tým zjistil, že efektivní automatizace vyžaduje nejen technickou zdatnost, ale také koordinaci mezi týmy a dobře promyšlený proces implementace. Pečlivý výběr nástroje, jako je Cypress, byl klíčem k úspěchu. Iterativní přístup a pravidelná zpětná vazba pomohly rychle reagovat na změny a vylepšovat proces. 
 
Nicméně se ukázal, že náročnost na prvotní vytvoření testů je vysoká jak na technické dovednosti, tak i na časovou náročnost.  
Údržba testů není o moc méně náročnější. V dynamické prostředí menší společnosti, kde se věci mění velice rychle je nutné počítat s tím, že se spousta věcí mění tzv. “pod rukama”. 
 
V údržbě a vytvářeni testů je potřebná určitá dovednost orientovat se v problematice a lidí, kteří na tom mohou pracovat je omezené množství. A tím pádem i zastupitelnost je velice problematická.

Co šlo udělat lépe? 

Zajistit větší zapojení vývojářů do procesu implementace.
V průběhu se zjistilo, že vícero lidí má zkušenost s implementací, nebo i průzkumem z předchozích zaměstnání. 
 
Ponechat si více času na definování problému a research. V naší situaci tohle bylo dost řešeno metodou “ Big Bang”. Na vše bylo málo času i z důvodu vytížení lidí, kteří měli na starost implementaci a nastaveni workflow testů.  
 
V rámci researche pokud by bylo více času tak se mohla různá řešení konzultovat s externími odborníky na automatizační nástroje.