Kdy se vyplatí sáhnout po cloudových zařízeních a kdy po fyzických? Pro začátek si vystačíte s lokálními emulátory a simulátory, ale ty neodhalí problémy s výkonem na slabším hardwaru nebo s teplotou procesoru při delším zatížení. Pokud vyvíjíte aplikaci pro širokou veřejnost, je rozumné investovat do přístupu k reálným zařízením přes cloudové služby. Umožní vám to testovat na stovkách modelů bez nutnosti fyzického vlastnictví. Pozor ale na to, že cloudové služby ne vždy simulují přesně chování senzorů (např. GPS, akcelerometr) nebo síťovou konektivitu. Proto kombinujte: klíčové scénáře ověřte na fyzických zařízeních, která máte k dispozici, a širokou škálu pokryjte cloudem.
Poslední rada: naučte se říkat ne nereálným požadavkům. Když zákazník chce termín, který fyzicky nejde stihnout, řekněte to přímo. Navrhněte kompromis – třeba rozdělit práci na etapy a dodat první část dřív. Tím získáte čas i důvěru. Vyhnete se tak kolotoči slibů, které vedou jen k nespokojenosti. Komunikace o odhadech není o tom, být nejrychlejší, ale o tom, být transparentní. A to je dovednost, kterou si zákazníci pamatují.
Při psaní testovacích scénářů se zaměřte na reálné uživatelské toky, ne jen na izolované funkce. Typickou chybou je testovat každé tlačítko zvlášť, ale neověřit, co se stane, když uživatel přeruší přihlášení, přijde hovor během platby nebo se mu vybije baterie v půlce nahrávání videa. Mobilní aplikace běží v prostředí plném přerušení, a proto je nezbytné testovat i tyto okrajové situace. Pomůže vám to odhalit problémy s ukládáním stavu, obnovením obrazovky nebo ztrátou dat, které by uživatele odradily.
Testovací pyramida není jen hezký obrázek v prezentaci. Je to praktický nástroj, který vám ušetří hodiny práce, když ho použijete správně. Základní myšlenka je jednoduchá: čím blíže k uživatelskému rozhraní test stojí, tím je pomalejší, dražší a křehčí. Proto by jich mělo být méně. Naopak jednotkové testy, které běží v milisekundách, by měly tvořit nejširší základnu. Pokud tuto strukturu ignorujete, skončíte s testy, které se bojíte spustit, protože trvají půl hodiny a padají na maličkostech.
Na závěr si nastavte metriky, podle kterých budete pyramidu vyhodnocovat. Sledujte průměrnou dobu běhu jednotlivých vrstev, počet testů, které selhávají bez zjevné příčiny, a čas, který vývojáři stráví opravou testů. Pokud se tyto hodnoty zhoršují, vraťte se k revizi. Pamatujte, že pyramida není cíl, ale nástroj — jejím smyslem je dát vám rychlou a spolehlivou zpětnou vazbu při každé změně kódu. Když ji postavíte správně, ušetříte čas a předejdete chybám, které by se jinak dostaly až do produkce.
Pamatujte také na testování sítě. Mobilní aplikace se používají na cestách, v metru, na venkově, kde je signál slabý nebo nestabilní. Proto je důležité testovat chování aplikace při pomalém připojení, při výpadku sítě a při přepnutí z Wi-Fi na mobilní data. Vytvořte si testovací scénáře, které simulují tyto podmínky pomocí nástrojů pro omezení šířky pásma nebo emulaci zpoždění. Ujistěte se, že aplikace uživatele informuje o probíhajícím načítání, nedochází ke ztrátě vstupů a po obnovení připojení se data synchronizují bez chyb.
Testování mobilních aplikací se od testování webových stránek liší v mnoha ohledech. Nejde jen o ověření funkčnosti na jednom zařízení, ale o zajištění konzistentního chování napříč stovkami modelů telefonů, verzemi operačních systémů a různými velikostmi obrazovek. Klíčové je začít s testováním co nejdříve – nejlépe již ve fázi návrhu architektury. Čím později chybu odhalíte, tím dražší je její oprava, a to nejen finančně, ale i časově. Praktickým prvním krokem je vytvoření jednoduché matice zařízení, která pokryje nejpoužívanější kombinace systému a rozlišení ve vaší cílové skupině.
Na závěr si ověřte, že váš editor umí správně pracovat s více jazyky v jednom souboru. Například pro HTML s vloženým CSS a JavaScriptem je nezbytné, aby editor zvýrazňoval syntaxi správně pro každou část. Pokud máte pocit, že zvýrazňování nefunguje, zkuste nainstalovat jazykovou podporu pro daný typ souboru nebo upravit asociaci přípon. To je rychlá oprava, která výrazně zlepší orientaci v kódu.
Když zákazník požádá o odhad času, většina z nás automaticky vsadí na optimismus. V duchu si řekneme, že to stihneme dřív, a sdělíme termín, který nás pak dostane pod tlak. Výsledek? Zpoždění, omluvy a zákazník, který vám přestane věřit. Přitom stačí změnit způsob, jakým o čase mluvíte, a komunikace se stane nástrojem důvěry místo zdrojem stresu.
