Edytujesz Ruční testování versus automatizace: co odhalí chyby dřív

Začněte tím, že si odpovíte, co je kód a co konfigurace. Kód je to, co se kompiluje nebo interpretuje a co by mělo být stejné ve všech prostředích. Konfigurace je to, co se mezi prostředími liší: připojení k databázi, klíče, limity, zapínání funkcí. Do kódu nepatří žádné hodnoty specifické pro prostředí. Do konfigurace nepatří logika. Tuto hranici si napište a vynuťte ji v CI, ne jen v hlavách.<br><br>Portfolio rozhoduje, ne počet certifikát<br><br>První konkrétní krok: oddělte reprezentaci od identity. Nikdy neposílejte klientům interní databázové klíče jako primární identifikátor v URL. Místo „/objednavky/4711" použijte stabilní, veřejný identifikátor, který si sami generujete a který přežije migraci tabulek. Když se datový model změní – sloučíte tabulky, přejdete na UUID, rozdělíte entitu – veřejné ID zůstane stejné a klienti nic nepoznají.<br><br>Typická chyba začátečníků je snaha naučit se všechno najednou. Místo toho si dejte malé cíle: zobrazit text, reagovat na stisk tlačítka, uložit hodnotu po otočení obrazovky. Další častá chyba je ignorování správy paměti a kontextu – aplikace pak spadne při rotaci nebo při přechodu na jinou obrazovku. Vždy testujte na více zařízeních s různými verzemi systému. Emulátor sice stačí na základní ověření, ale skutečný telefon odhalí problémy s výkonem i s ovládáním.<br><br>Mezi typické chyby patří testování pouze na nejnovější verzi systému, ignorování tmavého režimu a zvětšeného písma, podcenění obnovení aplikace po zabití procesu a spoléhání na to, že se chyba projeví i jinde. Zapisujte ke každému nálezu zařízení, verzi systému a přesný postup – bez toho je reprodukce ztrátou času. Před vydáním projděte kritické cesty ještě jednou na pomalejším zařízení s horším připojením; právě tam se rozdíl mezi funkčním a použitelným projeví nejdřív.<br><br>Ruční testování se vyplatí u všeho, co souvisí s vnímáním: plynulost posouvání, čitelnost textu, chování klávesnice při překrytí formuláře, reakce na otočení displeje. Procházejte scénáře v tomto pořadí: instalace, první spuštění, přihlášení, hlavní úkol aplikace, přerušení hovorem nebo notifikací, návrat do aplikace, odhlášení, odinstalace. Právě přechody mezi stavy odhalí většinu chyb – vývojáři je totiž testují nejméně.<br><br>Konfiguraci dělte podle prostředí, ale ne pomocí větvení v gitu. Větve pro vývoj, test a produkci vedou k nekonečnému mergování a rozjetým rozdílům. Lepší je jedna větev a adresářová struktura: například base, vyvoj, test, produkce, kde se hodnoty překrývají. Tajemství nepatří ani do jednoho repozitáře. Držte je ve správci tajemství nebo v šifrovaném souboru, který se odemyká při nasazení. Do gitu patří jen odkaz na tajemství, ne jeho obsah.<br><br>Verzování kódu a verzování konfigurace mají odlišná pravidla: kód se mění v logických celcích, konfigurace se mění podle prostředí, tajemství a nasazení. Když obojí leží v jednom repozitáři bez pravidel, vzniká zmatek: commit obsahuje změnu logiky i úpravu produkční adresy, historii nelze číst a návrat k předchozí verzi rozbije běžící systém. Řešením není jeden velký repozitář, ale oddělení podle účelu a citlivosti.<br><br>Uložení klíče patří do transakce spolu s vlastní operací. Pokud nejdřív zapíšete výsledek a pak klíč, může selhat zápis klíče a při opakování vznikne duplicita. Vhodné je použít databázi s unikátním indexem na kombinaci klíče a uživatele. Při souběhu dvou požadavků se stejným klíčem jeden zápis uspěje a druhý dostane konflikt. Tento konflikt se nemá vracet jako chyba 500, ale jako 409 nebo 200 s původním výsledkem. Doba platnosti klíče má být omezená, obvykle hodiny až dny. Příliš krátká expirace dovolí duplicitu později, příliš dlouhá zbytečně plýtvá místem.<br><br>Typické chyby: commitování .env s produkčními hesly, míchání změn kódu a konfigurace v jednom commitu, používání větví místo adresářů a nasazování konfigurace bez verze. Každá z nich vede k tomu, že nevíte, co běželo v produkci. Pokud už máte obojí v jednom repozitáři, rozdělte to postupně: nejprve přesuňte konfiguraci do samostatného adresáře, pak do samostatného repozitáře a nakonec nastavte pipeline tak, aby se kód a konfigurace nasazovaly odděleně.<br><br>Kde automatizace pomůže a kde jen zaměstná Automatizované testy nasaďte na opakující se a deterministické části: přihlašovací tok, validace formulářů, zpracování odpovědí ze serveru, navigaci mezi obrazovkami. Pište je tak, aby nespoléhaly na konkrétní souřadnice pixelů – používejte identifikátory prvků, které vývojáři přidělují záměrně pro testy. Počítejte s nestabilitou: čekání na pevný počet sekund místo na dokončení operace je nejčastější důvod, proč testy jednou projdou a podruhé ne.