Odhady času, které ničí důvěru: jak je říct bez slibů

Častou chybou je testovat pouze na nejnovější verzi systému. Uživatelé s staršími verzemi tvoří nezanedbatelnou část a právě tam bývají problémy s kompatibilitou. Stejně tak se vyplatí testovat na zařízeních s malým množstvím úložiště a s omezeným výkonem. Aplikace, která se tváří plynule na výkonném telefonu, může být na slabším zařízení nepoužitelná.

Začnete tím, že si nainstalujete TypeScript globálně nebo lokálně do projektu a vytvoříte konfigurační soubor tsconfig.json. V něm nastavíte cíl kompilace, povolíte přísné kontroly a určíte, kam se má výsledný JavaScript ukládat. Pro nový projekt je rozumné zapnout "strict": true. Zpočátku to bolí, protože kompilátor hlásí i to, co jste dřív přehlíželi. Vyplatí se to ale vydržet: přísný režim vás naučí psát typy pořádně a předejde řadě problémů později.

Práce s daty je v JavaScriptu častý zdroj chyb. Nepředávejte všude celý objekt, když funkce potřebuje jen jednu vlastnost. Ničíte tím čitelnost a ztěžujete testování. Místo uzivatel předávejte uzivatel.email, pokud jde jen o e-mail. U polí používejte map, filter, reduce místo ručních cyklů for s push. Kód je kratší a méně náchylný k chybám s indexy. Pozor ale na přílišné řetězení – tři operace za sebou se ještě čtou, deset už je nečitelných. Rozdělte je do pojmenovaných kroků.

Nejčastější chyba je spoléhat se na výchozí styly prohlížeče. Ty se liší, takže stejná stránka může vypadat jinak v každém programu. Řešením je nastavit základní vlastnosti na začátku: velikost písma, rodinu písma, okraje a způsob počítání šířky prvků. Box model je klíčový pojem. Šířka prvku se ve výchozím stavu počítá jinak, než většina lidí čeká, a proto se prvky rozlézají mimo rodiče. Přepnutím způsobu výpočtu se tento problém vyřeší jednou provždy.

Nakonec si hlídejte slovník. Slova jako „určitě", „stoprocentně" nebo „do té doby to bude" znějí dobře, ale vytvářejí závazek, který nemůžete splnit. Nahraďte je slovy „předpokládám", „odhaduji", „pokud se nic nezmění". Není to slabost, je to přesnost. Klient, který slyší poctivý odhad s podmínkami, vám bude věřit i tehdy, když se termín posune. Klient, který slyšel slib, vám nebude věřit už nikdy.

Základem je rozdělit testování na dvě rovnocenné části: automatizované a manuální. Automatizace se vyplatí u regresních testů, opakovaných scénářů a kontrol rozhraní API. Manuální testování naopak odhalí problémy s ovládáním, čitelností textu, chováním při rotaci displeje nebo při příchozím hovoru. Snaha automatizovat úplně vše vede k sadě testů, které jsou křehké, pomalé a nikdo je neudržuje.

Nezapomínejte na přístupnost a lokalizaci. Otestujte aplikaci s větším zvětšením textu, s čtečkou obrazovky a v jazyce, který má delší názvy tlačítek. České překlady bývají delší než anglické a často rozbíjí rozložení obrazovky. Stejně důležité je sledovat chování po aktualizaci aplikace, kdy se mohou stará data dostat do konfliktu s novou strukturou. Testování není jednorázová aktivita před vydáním, ale průběžná součást vývoje, která se vyplatí nejvíc ve chvíli, kdy ji nikdo neodbývá.

Pro spouštění v CI slouží příkaz pytest s parametrem --junitxml, který vytvoří strojově čitelný výstup. Pokrytí kódu změříte pluginem pytest-cov a příkazem pytest --cov=. Neusilujte ale o stoprocentní pokrytí za každou cenu. Důležité je pokrýt logiku a hraniční případy, ne každý řádek. pytest nabízí i možnost přeskakovat testy pomocí skipif nebo označit očekávaná selhání přes xfail. Tyto značky udržují sadu testů čitelnou i ve chvíli, kdy některé části ještě nejsou hotové.

Začněte tím, že oddělíte odhad od závazku. Místo „bude to do pátku" řekněte „pracovní odhad je pět dní, ale závazek vám dám, až projdeme zadání". Tím se z rozhovoru stane plánování, ne soutěž v optimismu. Pokud klient tlačí na konkrétní datum, je to signál, že potřebuje naplánovat něco dalšího. Zeptejte se čeho. Často zjistíte, že mu stačí vědět, kdy začnete, ne kdy skončíte.

Testování mobilních aplikací se od testování webu liší víc, než se na první pohled zdá. Nejde jen o jinou velikost obrazovky. Aplikace běží na zařízení s omezeným výkonem, přerušovaným připojením, různými verzemi operačního systému a agresivní správou baterie. Pokud se tyto faktory ignorují, testovací scénáře projdou na vývojářském stroji, ale v reálném provozu aplikace padá nebo se chová nepředvídatelně.

Typická chyba je skrývat rezervu a tvářit se jako stroj. Klient pak nevidí, že máte prostor na neočekávané věci, a každé zpoždění bere jako selhání. Lepší je říct: „Můj odhad je deset dní, z toho dva dny jsou rezerva na věci, které teď nevidíme." Rezerva není lenost, je to nástroj, jak slib dodržet. Zároveň ji nepoužívejte jako omluvu pro práci, která se dá udělat hned.