Co se stane, když otestujete mobilní aplikaci až po vydání

Na závěr – testování mobilních aplikací není jednorázová fáze, ale kontinuální proces. Zavádějte testy do průběžné integrace a spouštějte je při každém commit, ideálně na nejmenším počtu zařízení, která reprezentují hlavní skupiny uživatelů. Důležité je také sledovat metriky z produkce, jako jsou pády, ANR (Application Not Responding) a výkon. Až získáte dostatek dat, budete schopni optimalizovat svůj testovací plán a prioritizovat oblasti, které skutečně ovlivňují spokojenost uživatelů.

Základním krokem je vybrat správný typ pokrytí. Nejčastěji se setkáte s pokrytím řádků, které je snadné spočítat a snadno se prezentuje. Větší výpovědní hodnotu má pokrytí větví, protože odhaluje, jestli byly testovány obě možnosti u podmínek, a pokrytí podmínek, které kontroluje jednotlivé logické výrazy. Pro nový kód si nastavte cíl alespoň pro pokrytí větví; jen řádky vás nechají ve slepé uličce, protože můžete mít 80 % řádků a přitom polovinu rozhodovacích cest netestovanou. Důležité je měřit pokrytí na úrovni jednotek, nikoli jen na úrovni celého systému, a výsledky ukládat do historie, abyste viděli trend.

Pokrytí přestává být užitečné ve chvíli, kdy se stane cílem samo o sobě. Když tým diskutuje o tom, jak zvýšit procento z 85 na 90, místo aby řešil, které rizikové části kódu nejsou otestované, je to varovný signál. Stejně tak když je pokrytí používáno jako jediné kritérium pro schválení pull requestu, vede to k formálním úpravám, které nemají vliv na spolehlivost. Místo honění čísel se zaměřte na testování kritických a často měněných částí. Pokud máte systém s mnoha vnějšími závislostmi, pokrytí řádků u integračních testů vypovídá málo o tom, jestli je spolupráce komponent správná.

Nakonec si pamatujte, že DevOps je o lidech víc než o technice. Pokud váš tým nechce měnit zaběhnuté postupy, žádná technologie to nespasí. Začněte tím, že si s kolegy sednete a sepíšete si, co je nejvíc bolí. Z toho jednoho bodu pak postavte experiment — a nejlépe nechte mluvit výsledky, ne názory. Jakmile uvidíte, že se nasazení zrychlilo a chyby klesají, zbytek týmu se přidá sám.

Při automatizaci testů se zaměřte na stabilní a pomalé UI prvky, jako jsou přihlašovací formuláře, nákupní košík nebo onboarding. Automatizace mobilních testů je náročnější než u webu kvůli dynamickým prvkům a animacím. Používejte nástroje, které umožňují čekání na prvek na základě podmínky, ne jen pevný časový limit. Častou chybou je spoléhat na „sleepy", které testy zpomalují a činí je křehkými. Místo toho definujte explicitní očekávání, kdy má být prvek viditelný nebo klikatelný.

Další krok se týká pojmenování. Pokud budete mít soubory jako text-cz.txt a text-en.txt, čeká vás peklo při hledání, co se změnilo. Místo toho zaveďte jednotný klíč, který odpovídá umístění v aplikaci, například homepage.hero.headline. Tenhle klíč pak použijete ve všech jazykových verzích. Do zdrojového kódu nikdy nepíšete hotový text, ale odkaz na klíč. Když marketing změní titulek, stačí upravit jeden soubor a celý web se přeloží sám. Tohle je první místo, kde lidé dělají chybu – začnou psát texty přímo do šablon a později už nedokážou říct, kde který jazyk končí.

Když už máte první službu v CI, zaměřte se na měření. Klíčové metriky nejsou počet nasazení za den, ale doba od nápadu po produkci a frekvence selhání. Zapisujte si čísla do tabulky, ale neanalyzujte je každý den — stačí týdenní revize. Pokud vidíte, že jsou nasazení častější, ale výpadky se nemění, děláte to dobře. Když se ale výpadky začnou množit, přibrzděte a přidejte víc testů, ne další automatizace.

Měření pokrytí testy patří mezi nejčastěji používané metriky kvality kódu. Na první pohled vypadá jednoduše: stačí spustit nástroj, který projde zdrojový kód a spočítá, kolik řádků, větví nebo funkcí bylo při testech vykonáno. Výsledek v procentech pak působí jako objektivní ukazatel. Jenže samotné číslo vám neřekne, jestli testy skutečně chrání před chybami, nebo jen mechanicky procházejí kódem. Než začnete hodnoty interpretovat, měli byste vědět, co přesně měříte a kde jsou limity této metriky.

Pozor na dva typické problémy. První je, že si lidé myslí, že DevOps je jenom o nástrojích jako Docker nebo Kubernetes. To je omyl — nástroje jsou až druhé. Nejprve si definujte, co chcete zlepšit: rychlost nasazení, stabilitu nebo spolupráci. Druhý problém je tichá sabotáž ze strany provozu. Když ho nezapojíte do návrhu procesu, bude se bránit změnám. Mluvte s nimi předem, ne až ve chvíli, kdy jim předáte hotový skript.