Jak správně testovat mobilní aplikace

Mobilní aplikace se testují jinak než webové. Na webu máte v podstatě dva renderovací enginy (Chromium a WebKit), předvídatelné rozlišení a stabilní síťové připojení. Na mobilech máte tisíce různých zařízení, desítky verzí operačních systémů, nespolehlivé sítě a uživatele, kteří vaši aplikaci přeruší telefonátem v tom nejhorším možném momentu. Kvalitní testovací strategie je proto nezbytnost, ne luxus.

Testovací pyramida pro mobilní aplikace

Koncept testovací pyramidy platí i pro mobilní vývoj, ale s důležitými nuancemi. Základ tvoří unit testy, střed integrační testy a špičku end-to-end testy. Poměr by měl být zhruba 70:20:10.

Unit testy ověřují izolované jednotky kódu -- funkce, třídy, utility. V mobilním vývoji typicky testujete business logiku, datové transformace, validace formulářů a stavový management. Nástroje závisí na platformě: Jest pro React Native, XCTest pro Swift, JUnit pro Kotlin.

Unit testy by měly být rychlé (celá sada pod 30 sekund), deterministické (žádné závislosti na síti nebo reálné databázi) a měly by pokrývat edge cases. Pokud váš kód zpracovává datum, testujete přechod přes půlnoc, přestupný rok, změnu letního času. Pokud zpracovává částky, testujete záporné hodnoty, nulu, maximální hodnoty.

Integrační testy ověřují, že komponenty spolupracují správně. Typicky testujete komunikaci s API (s mockovaným serverem), persistence dat (zápis a čtení z lokální databáze), navigaci mezi obrazovkami a správnou interakci komponent.

Pro integrační testy v React Native se osvědčil React Native Testing Library, který testuje komponenty z pohledu uživatele -- hledá elementy podle textu a accessibility labelu, ne podle interní struktury. Pro nativní iOS a Android slouží XCUITest a Espresso.

End-to-end testy simulují kompletní uživatelské cesty od spuštění aplikace po dosažení cíle. Registrace, přihlášení, provedení hlavní akce, odhlášení. Tyto testy jsou nejpomalejší a nejkřehčí, proto jich mějte nejméně -- pokryjte kritické business flows a happy paths.

Fragmentace zařízení -- hlavní výzva mobilního testování

Android ekosystém čítá tisíce různých zařízení od desítek výrobců. Každý výrobce si přizpůsobuje systém po svém -- Samsung má One UI, Xiaomi MIUI, Huawei EMUI. Tyto nadstavby mohou ovlivnit chování aplikace způsobem, který v emulátoru nezachytíte.

Rozlišení a velikosti obrazovek. Od 4palcových kompaktních telefonů po 7palcové phablety a skládací zařízení. Vaše UI musí fungovat na všech. Testujte minimálně na čtyřech kategoriích: malý telefon (iPhone SE / Galaxy A-serie), běžný telefon (iPhone 15 / Pixel 8), velký telefon (iPhone 15 Pro Max / Galaxy S24 Ultra) a tablet.

Verze operačního systému. Na iOS je situace jednodušší -- většina uživatelů aktualizuje relativně rychle a stačí podporovat poslední 2-3 verze. Na Androidu je situace dramaticky horší. Android 12 a starší stále používá významné procento uživatelů, zejména na levnějších zařízeních. Před rozhodnutím, jaké verze podporovat, zkontrolujte data z Google Play Console nebo Firebase Analytics pro váš konkrétní trh.

Výkon na slabších zařízeních. Vaše aplikace možná běží skvěle na Pixelu 8 Pro s 12 GB RAM. Ale jak si vede na Samsung Galaxy A14 s 3 GB RAM a pomalejším procesorem? Právě na těchto zařízeních ji bude používat značná část vašich uživatelů. Testujte plynulost animací, dobu načítání a spotřebu paměti na zařízení z nižší cenové kategorie.

Reálná zařízení versus emulátory

Emulátory a simulátory jsou neocenitelné pro rychlý vývoj a základní testování. Ale mají limity, které je nutné znát.

Kde emulátory stačí: Unit testy, integrační testy, základní testování UI layoutu, testování různých rozlišení a verzí OS, automatizované CI/CD testy.

Kde potřebujete reálná zařízení: Testování výkonu a plynulosti animací (emulátory mají jiné výkonnostní charakteristiky), testování hardwarových funkcí (kamera, GPS, biometrie, NFC), testování push notifikací v reálných podmínkách, testování chování na specifických výrobcích (Samsung, Xiaomi), testování síťového chování (přechod Wi-Fi na mobilní data, slabý signál).

Ideální přístup je mít 3-5 reálných zařízení pro manuální testování (pokrývajících různé výrobce, velikosti a cenové kategorie) a používat cloudové farmy zařízení pro automatizované testy na širším spektru. Firebase Test Lab, BrowserStack a AWS Device Farm nabízejí přístup ke stovkám reálných zařízení na vyžádání.

Nástroje pro automatizované testování

Výběr správného nástroje pro E2E testování mobilních aplikací je klíčový, protože špatná volba vám způsobí víc frustrace než užitku.

Detox je framework od Wix navržený speciálně pro React Native. Jeho největší výhodou je synchronizace -- Detox ví, kdy aplikace dokončila animace a síťové requesty, takže testy jsou výrazně stabilnější než u konkurence. Nevýhodou je, že funguje pouze s React Native.

Maestro je relativně nový nástroj, který si rychle získal popularitu díky jednoduchosti. Testy se píšou v YAML, nepotřebujete znát žádný programovací jazyk. Je platform-agnostický (funguje s nativními i cross-platform aplikacemi) a má vynikající developer experience. Pro většinu týmů je dnes Maestro nejlepší volba pro začátek s E2E testováním.

Appium je nejstarší a nejrozšířenější framework. Podporuje prakticky jakoukoli mobilní platformu a jakýkoli programovací jazyk. Daní za tuto flexibilitu je složitost konfigurace a pomalejší běh testů. Appium dává smysl pro velké týmy s dedikovaným QA oddělením a potřebou testovat na mnoha platformách.

CI/CD pro mobilní aplikace

Continuous Integration pro mobilní vývoj má svá specifika oproti webovému vývoji.

Build pipeline. Každý push do hlavní větve by měl spustit: linting a statickou analýzu, unit testy, integrační testy, build aplikace pro obě platformy. iOS build vyžaduje macOS runner (GitHub Actions nabízí macOS runnery, ale jsou dražší). Android build lze spustit na Linuxu.

Automatické E2E testy. Spouštějte je alespoň jednou denně nebo před každým mergem do hlavní větve. Na každý commit jsou příliš pomalé a drahé. Používejte paralelizaci -- testy na iOS a Android mohou běžet současně.

Automatická distribuce. Po úspěšném průchodu testy by se build měl automaticky distribuovat testerům. Tím se dostáváme k beta testování.

Beta testování a distribuce

Než aplikaci vydáte veřejně, potřebujete ji otestovat s reálnými uživateli v reálných podmínkách.

TestFlight pro iOS je standardní cesta. Apple ho poskytuje zdarma, podporuje až 10 000 externích testerů a umožňuje postupný rollout. Buildy procházejí základní Apple review (rychlejší než plný review), takže počítejte s 24-48 hodinovou prodlevou.

Firebase App Distribution (dříve Crashlytics Beta) funguje pro Android i iOS. Distribuce je okamžitá (žádný review proces), můžete vytvářet skupiny testerů a sledovat, kdo si build nainstaloval. Pro Android je to jednodušší alternativa ke Google Play internímu testování.

Google Play internal testing a closed testing tracky umožňují distribuovat aplikaci přes Google Play, ale jen vybraným testerům. Výhoda je, že testeři dostávají aktualizace stejným způsobem jako finální uživatelé.

Klíčové při beta testování je mít jasnou strukturu zpětné vazby. Dejte testerům formulář nebo dedikovaný kanál pro hlášení problémů. Ptejte se na konkrétní scénáře, ne jen "jak se vám líbí". A nastavte si timeframe -- beta fáze by měla trvat 1-2 týdny, ne měsíce.

Monitoring pádů v produkci

Ani sebelepší testování nezachytí všechny problémy. V produkci potřebujete monitoring, který vám řekne o problémech dřív než uživatelé.

Sentry a Firebase Crashlytics jsou dva nejrozšířenější nástroje pro crash reporting. Oba zachytávají neošetřené výjimky, poskytují stack trace, informace o zařízení a kroky uživatele vedoucí k pádu. Crashlytics je zdarma a hluboce integrovaný s Firebase ekosystémem. Sentry nabízí víc konfigurace a funguje i mimo mobilní aplikace.

Nastavte si alerting na crash-free rate. Pokud procento sessions bez pádu klesne pod 99,5 %, měli byste to vědět okamžitě. Apple i Google používají crash-free rate jako jeden z faktorů pro visibility v obchodech.

Kromě pádů sledujte i ANR (Application Not Responding) na Androidu a hang rate na iOS. Tyto problémy jsou pro uživatele často frustrující víc než pády, protože aplikace vypadá zamrzlá a uživatel neví, jestli čekat nebo ji zavřít.

Co testovat -- praktický checklist

Kromě zřejmých funkčních testů existují scénáře specifické pro mobilní aplikace, na které se často zapomíná.

Přerušení. Příchozí telefonát během vyplňování formuláře. Push notifikace z jiné aplikace. Přepnutí do jiné aplikace a zpět. Uzamčení a odemčení telefonu. Vaše aplikace musí tyto přerušení přežít bez ztráty dat.

Síťové podmínky. Pomalé připojení (3G), výpadek sítě uprostřed requestu, přechod z Wi-Fi na mobilní data. Testujte s network throttlingem -- v Android emulátoru i Xcode simulátoru lze simulovat různé síťové podmínky.

Offline režim. Co se stane, když uživatel otevře aplikaci bez internetu? Vidí cached data? Srozumitelnou chybovou hlášku? Prázdnou obrazovku? Pokud vaše aplikace podporuje offline režim, testujte synchronizaci dat po obnovení připojení, včetně konfliktů (uživatel změnil data offline, zatímco se změnila i na serveru).

Práce s pamětí. Na Androidu systém může vaši aplikaci na pozadí ukončit, pokud potřebuje paměť pro jinou aplikaci. Při návratu by se měla obnovit do posledního stavu. Testujte tento scénář -- v Android Studio existuje možnost "Terminate application" pro simulaci tohoto chování.

Různé jazyky a lokalizace. Německé překlady jsou delší než anglické, arabština se čte zprava doleva, japonština nemá mezery mezi slovy. Pokud aplikaci lokalizujete, testujte UI se všemi jazyky -- tlačítko, které vypadá skvěle s textem "Save", může přetéct s "Speichern".

Závěr

Testování mobilní aplikace je komplexnější než testování webové aplikace, ale nemusí být nepřekonatelně složité. Začněte od základů -- solidní unit testy pro business logiku, pár klíčových E2E testů pro kritické cesty a crash monitoring od prvního dne v produkci. Postupně přidávejte sofistikovanější vrstvy: integrační testy, automatizované testování na reálných zařízeních, performance monitoring.

Nejdůležitější je začít. Nedokonalá testovací strategie, která existuje, je nekonečně lepší než dokonalá strategie, kterou plánujete implementovat "příště". Každá zachycená chyba před vydáním je chyba, kterou váš uživatel nikdy neuvidí -- a to je investice, která se vyplatí vždy.