Modelová situace: ruční testování brzdí časté releasy
Tým chce připravovat releasy častěji, ale před každým z nich musí opakovaně projít stejné uživatelské cesty. Ruční testování zabírá významnou část kapacity a výsledek přichází pozdě. Cílem není odstranit lidi z testování, ale přesunout opakovatelné kontroly na automatizaci a uvolnit čas pro nová a nepředvídaná rizika.
Výchozí situace
Webová aplikace nebo e-shop se mění v krátkých cyklech. Před releasem tým ověřuje přihlášení, vyhledávání, objednávku, platbu a další důležité cesty. Když se termín zkrátí, zkrátí se také seznam kontrol nebo se testuje převážně to, co se změnilo.
Chyba se však může projevit i ve zdánlivě nesouvisející části. Tým se proto rozhoduje mezi delším čekáním na release a větším rizikem v produkci. Pokud již má automatizované testy, mohou některé z nich náhodně selhávat, takže je nutné výsledky opakovaně ověřovat ručně.
Jak lze situaci řešit
1. Zmapovat riziko a současnou časovou náročnost
Nejprve se sepíší kontrolované scénáře, jejich délka a dopad případné chyby. Na tomto základě se vyberou první cesty vhodné k automatizaci. Může jít o přihlášení, objednávku nebo platbu, ale ne automaticky o vše.
2. Připravit podmínky pro stabilní testy
Testy potřebují stabilní způsob nalezení prvků, vlastní data a prostředí, ve kterém mohou bezpečně dokončit celý scénář. Tyto podmínky popisujeme v tématu jak připravit web na automatizované testy.
Opakované části rozhraní se oddělí od samotných scénářů, například pomocí Page Object Modelu nebo komponentových objektů. Velké množství kombinací se podle potřeby ověří na úrovni API, kde bývají testy rychlejší a jejich diagnostika jednodušší.
3. Zapojovat testy postupně
První malá sada může běžet v CI/CD při dohodnutých změnách a pravidelně v testovacím prostředí. Při selhání má tým dostat dostatek údajů pro rozhodnutí, například chybovou zprávu a podle konfigurace také trace, snímek nebo video. Teprve když jsou výsledky stabilní a tým na ně reaguje, přidávají se další scénáře.
4. Změřit výsledek
Porovná se čas ruční kontroly, délka automatického běhu, počet náhodných selhání a čas potřebný k údržbě. Teprve měření ukáže, zda se zpětná vazba zkrátila ze dnů na hodiny nebo z hodin na minuty. Stejné údaje pomohou rozhodnout, co automatizovat dále.
Na co si dát pozor
Automatizovaný test může selhat kvůli chybě aplikace, testu i prostředí. Cílem proto není slibovat, že každý červený výsledek znamená chybu produktu, ale snížit počet nejasných selhání natolik, aby tým dokázal výsledek rychle vyhodnotit. Stejně důležité je určit vlastníka údržby po každé změně aplikace.
Co tím uživatel a tým získají
- Důležité cesty se kontrolují stejným způsobem při každém dohodnutém běhu.
- Výsledek může přijít dříve a release nemusí čekat na všechny opakované ruční kroky.
- Testeři získají více času na nové funkce, použitelnost a průzkumné testování.
- Testy a jejich historie zůstávají v repozitáři a lze je předat dalšímu týmu.
Další krok
Změřte, které ruční kontroly před releasem trvají nejdéle a které chrání před největším rizikem. Pokud chcete připravit realistický pilot, ozvěte se nám. Navrhneme rozsah, způsob spouštění i metriky, podle kterých lze přínos vyhodnotit.