Práce ve větvi je bezpečná jen tehdy, když víš, kde jsi. git branch vypíše větve, git switch -c nova-vetev vytvoří a přepne. Častá chyba: upravovat soubory, pak přepnout větev a divit se, že změny „zmizely". Git je nemaže, jen je nechá v pracovním adresáři a přepnutí buď zablokuje, nebo je přenese jinam. Před přepnutím buď změny commitni, nebo je odlož pomocí git stash. Sloučení (git merge) přináší konflikty — nejsou porucha, jsou normální stav. Otevři označené soubory, vyber správnou verzi, odstraň značky >>>>>>, pak soubor přidej a commit dokonči.

Časté chyby mají společné jméno: „any" a tvrzení typu. Když napíšete „něco as SomeType", jen tím překladateli řeknete, ať věří, že data mají tvar, který nemají. Kontrola projde a chyba se objeví až v provozu. Stejně zrádné je ignorovat návratové hodnoty funkcí, které mohou vrátit null. Řešení není složité: vždy pracujte s možností, že hodnota chybí. Pomůže volitelný řetězec „?.", výchozí hodnota přes „??" a úzké typy místo širokých. Místo „string" použijte konkrétní unijní typ, pokud znáte povolené hodnoty.

Kontrola nestačí jednorázově. Nové dotazy vznikají při každé změně a je snadné zapomenout na parametrizaci právě tam, kde se přidává filtr nebo export. Proto se vyplatí zavést pravidlo, že přímé spojování vstupu do SQL se v kódu vůbec nesmí objevit, a to i v pomocných funkcích a testech. Pravidelná revize dotazů a testování s neobvyklými vstupy odhalí slabá místa dřív než útočník.

Analytická fáze je plná nejistoty, protože nevíte, co se dozvíte, až začnete mluvit s lidmi. Proto ji neodhadujte jednou provždy. Udělejte hrubý odhad pro plánování kapacity a pak těsný odhad ve chvíli, kdy je úkol na řadě. Hrubý odhad stačí v řádu dnů nebo týdnů, těsný v řádu hodin. Tím se vyhnete tomu, že budete držet zastaralé číslo z doby, kdy o problému nikdo nic nevěděl.

Pro efektivní pokrytí je potřeba kombinovat oba přístupy. Automatizace odvede rutinu při každé změně kódu, ruční testování odhalí to, co skript nevidí – neobvyklé chování, nesrozumitelné hlášky, problémy s čitelností na malém displeji. Výsledky měřte podle počtu odhalených vad, ne podle počtu spuštěných testů. Ať už zvolíte kteroukoli cestu, bez reálných zařízení a skutečných uživatelů zůstane část chyb skrytá až do vydání.

Konzistence a nástroje místo dohadován

Testování mobilních aplikací se výrazně liší od testování webových stránek. Na jedné platformě běží aplikace na stovkách zařízení s různými verzemi operačního systému, velikostmi displeje a výkonem. Kdo začne testovat až po dokončení vývoje, obvykle skončí s hromadou chyb, které se špatně reprodukují. Rozdíl mezi ručním a automatizovaným testováním přitom není v tom, které je lepší, ale v tom, co má smysl řešit jak.

Začněte malou sadou testů, které pokrývají nejčastější cesty uživatelů. Nesnažte se automatizovat všechno najednou. Testovací prostředí udržujte oddělené od produkčního a data pro testy připravujte skriptem, ne ručně. Nestabilní testy, které jednou projdou a podruhé ne, jsou horší než žádné – lidé jim přestanou věřit a začnou je ignorovat. Pokud test opakovaně selhává bez skutečné chyby v aplikaci, opravte ho nebo smažte.

Ruční testování je nenahraditelné tam, kde rozhoduje lidský úsudek. Patří sem ověření plynulosti přechodů, chování aplikace při příchozím hovoru, práce s oprávněními, přepnutí do režimu na pozadí nebo rotace displeje. Testovací scénáře pište jako krátké kroky s jasným očekávaným výsledkem. Typická chyba: tester zapíše, že „aplikace se zasekla", ale už neuvede, na kterém zařízení, s jakou verzí systému a po jaké konkrétní akci. Bez těchto údajů vývojář chybu neopraví.

Kdy má smysl sáhnout po automatizaci Automatizace se vyplatí u opakujících se regresních testů: přihlášení, vyplnění formuláře, dokončení nákupu, načtení seznamu položek. Nástroje pro automatizaci mobilních aplikací obvykle pracují dvěma způsoby. První přistupuje k aplikaci jako k černé skříňce a hledá prvky podle textu, identifikátoru nebo pozice na obrazovce. Druhý vkládá do kódu testovací značky, což je spolehlivější, ale vyžaduje spolupráci s vývojáři. Pozor na selektory vázané na pořadí prvků – po jakékoli úpravě rozvržení se celá sada testů rozpadne.