Které mobilní scénáře se vyplatí automatizovat
Hodnotu automatizace neurčuje počet testů, ale chyby, které pomůže včas odhalit. Prvními scénáři proto nemají být pouze ty, které se píší nejsnáze. Vybíráme je podle dopadu na uživatele, četnosti používání, opakovatelnosti a nákladů na údržbu.
Proč dlouhý seznam obrazovek nestačí
Tým často začne automatizovat lineárně podle nabídky aplikace. Vzniknou desítky kontrol seznamů a nastavení, ale přihlášení, platba nebo obnovení po výpadku sítě zůstanou součástí ručního testování. Report vypadá plný, největší rizika však zůstávají nepokrytá.
Opačným problémem je snaha přenést do end-to-end vrstvy každý detail. Takové testy jsou pomalejší, pracují s více systémy a vyžadují více údržby. Výpočet ceny nebo validaci vstupu lze často ověřit rychleji a přesněji na úrovni jednotkového testu nebo testu API.
Jak určit pořadí
Každému kandidátovi přiřadíme čtyři jednoduchá hodnocení:
- Dopad chyby: zastaví zákazníka, platbu nebo důležitý proces?
- Četnost: jak často cestu používají zákazníci a tým ji opakuje?
- Opakovatelnost: dokážeme připravit známý stav a jednoznačně ověřit výsledek?
- Vhodná vrstva: musí scénář projít přes mobilní rozhraní, nebo ho lépe ověří API či nižší test?
Jako první vybíráme scénáře s vysokým dopadem a jasným výsledkem. Náročnost implementace bereme v úvahu, neměla by však automaticky vyřadit nejdůležitější cestu.
Scénáře, které bývají dobrými kandidáty
- Instalace, aktualizace a první spuštění. Ověřují čistý stav, úvodní nastavení a zachování dat po aktualizaci.
- Přihlášení a obnovení přístupu. Zahrnují úspěšný i neúspěšný pokus a stav relace po restartu. Dvoufaktorové ověření potřebuje testovací mechanismus.
- Hlavní funkce produktu. Jde o cestu, kvůli které si zákazník aplikaci nainstaloval, nikoli o obecný seznam obrazovek.
- Platba nebo objednávka. Používáme sandbox a kontrolovaná testovací data, nikoli skutečnou kartu ani produkční nákup.
- Oprávnění. Ověřujeme udělení, odmítnutí a návrat z nastavení, přičemž před testem spolehlivě obnovíme stav aplikace.
- Offline a přerušený proces. Kontrolujeme srozumitelnou reakci, opakování požadavku a ochranu před duplicitní operací.
- Notifikace a odkazy do aplikace. Samostatně lze ověřit registraci a zpracování dat; menší počet end-to-end testů kontroluje otevření správné obrazovky.
Scénáře, jako je hovor, změna orientace nebo omezení procesu na pozadí, vybíráme podle toho, zda ovlivňují konkrétní funkci. Ne každá aplikace je potřebuje v první sadě.
Jak z kandidátů vytvořit udržitelnou sadu
Pro každý scénář určujeme počáteční stav, testovací data, očekávaný výsledek a vlastníka. Data připravujeme přes API nebo řízený pomocný mechanismus, pokud není předmětem testu právě jejich vytvoření přes rozhraní. Tím zkracujeme běh a snižujeme počet náhodných selhání.
Nejkratší kritické cesty tvoří smoke sadu. Širší a pomalejší kombinace běží pravidelně nebo před releasem na vybrané matici zařízení. Test, který dlouhodobě selhává bez chyby produktu, opravíme nebo dočasně vyřadíme s jasným vlastníkem; nesmí se stát tolerovaným šumem.
Pokud mobilní aplikace závisí na backendu, velkou část pravidel lze levněji pokrýt prostřednictvím testování API. Mobilní vrstva potom ověřuje propojení systémů a skutečnou cestu uživatele.
Co tím získáte
Menší, dobře zvolená sada odhalí důležitější chyby než velký počet povrchních scénářů. Výsledky přicházejí dříve, snáze se vyhodnocují a tým rozumí tomu, jaké riziko každý test pokrývá.
Jasné priority také usnadní rozšiřování. Když přibude funkce nebo produkční problém, nový scénář se zařadí podle stejných pravidel namísto nahodilého zvětšování sady.
Další krok
Vezměte pět nejdůležitějších uživatelských cest a ohodnoťte je podle dopadu, četnosti, opakovatelnosti a vhodné testovací vrstvy. Dvě nejvýše hodnocené ověřte v pilotu a u každé si stanovte měřitelný výsledek. Teprve potom přidávejte další scénáře.