Jak začít s automatizací testů Android aplikace
Začít s automatizací Android aplikace neznamená pokrýt všechny obrazovky a zařízení. Mnohem užitečnější je vybrat několik důležitých uživatelských cest, připravit pro ně spolehlivá data a ověřit, že testy poskytují týmu rychlou a srozumitelnou zpětnou vazbu. Tento základ lze potom rozšiřovat podle rizika a skutečného používání aplikace.
Proč velký plán často nepřinese rychlý výsledek
Android existuje v mnoha verzích, velikostech displeje a úpravách od výrobců. Pokus otestovat každou kombinaci vede k velké matici, dlouhým běhům a výsledkům, které tým nestihne vyhodnotit. Na druhé straně jediný emulátor na počítači vývojáře nepokrývá rozdíly, které se projeví na konkrétním hardwaru.
Dalším problémem je výběr jednoduchých, ale málo důležitých scénářů. Test otevře seznam nebo změní nepodstatné nastavení, neověří však přihlášení, nákup nebo první spuštění. Počet testů roste, ale riziko pro uživatele zůstává téměř stejné.
Na mobilu má navíc chyba delší cestu k opravě: nový release je třeba distribuovat a ne všichni uživatelé aktualizují současně. Podrobněji to vysvětluje článek Proč se chyba v mobilní aplikaci opravuje obtížněji než na webu.
Pět kroků k prvnímu užitečnému pokrytí
1. Určete, co musí fungovat
Vyberte tři až pět cest s největším dopadem na zákazníka nebo příjmy. Obvykle jde o instalaci a první spuštění, přihlášení, hlavní funkci produktu a platbu. Při výběru pomůže přehled mobilních scénářů vhodných k automatizaci.
2. Připravte známý počáteční stav
Test potřebuje samostatné účty, předvídatelná data a způsob, jak aplikaci před během vrátit do známého stavu. Externí služby a platební brány používají testovací režimy. Bez této přípravy bude i správně napsaný scénář náhodně selhávat.
3. Ověřte nástroj v pilotu
Appium a Maestro mají odlišný způsob zápisu a provozu. Stejný kritický scénář proto nejprve vyzkoušíme na konkrétní aplikaci. Sledujeme dostupnost prvků, systémové dialogy, diagnostiku i to, kdo bude testy udržovat.
4. Rozdělte běhy podle účelu
Krátké smoke testy mohou běžet na emulátoru při relevantní změně a rychle odhalit chybu v základní cestě. Širší pokrytí spouštíme pravidelně nebo před releasem a doplňujeme je o vybraná fyzická zařízení. Jejich seznam vychází z analytiky uživatelů a rizik produktu, nikoli z aktuální nabídky telefonů. Rozdíly popisujeme v článku Emulátor nebo reálné zařízení.
5. Nastavte odpovědnost za výsledky
Každý běh musí mít vlastníka, srozumitelný report a pravidlo, co se děje po selhání. Video, snímky, logy a další diagnostická data je třeba nakonfigurovat podle použitého nástroje a prostředí. Test, jehož výsledek nikdo nevyhodnocuje, nepomáhá ani v dokonalé pipeline.
Na co si dát pozor
End-to-end testy nenahrazují jednotkové a integrační testy. Jsou pomalejší a náročnější na údržbu, proto jimi pokrýváme především důležité cesty přes celé rozhraní. CAPTCHA, jednorázové kódy nebo služby třetích stran mohou vyžadovat testovací režim či řízenou náhradu.
Co tím získáte
Tým získá první hodnotu bez čekání na velký projekt. Důležité chyby odhalí krátká sada včas a cílená fyzická zařízení doplní informace o chování v reálném prostředí.
Postupné rozšiřování zároveň udržuje pod kontrolou dobu běhu i údržbu. Každý nový scénář má jasný důvod, vlastníka a místo v testovací strategii.
Další krok
Sepište tři cesty, bez kterých zákazník nemůže aplikaci používat, a ke každé připravte testovací účet a očekávaný výsledek. Jednu cestu ověřte v krátkém pilotu na emulátoru i fyzickém zařízení. Teprve potom rozhodněte o nástroji, frekvenci a rozsahu další sady.