Na závěr si dejte pozor na jednu věc: neposílejte životopis, ve kterém napíšete „nemám praxi, ale jsem pečlivý”. Taková fráze nefunguje. Místo toho uveďte konkrétní projekt, na kterém jste testovali, kolik chyb jste nahlásili a jaké typy testů jste prováděli. Můžete si založit jednoduché portfolio, kde budou ukázky vašich reportů a testovacích plánů. Když tohle ukážete, nikdo se nebude ptát, kde jste pracoval. Klíčem je ukázat, že už testovat umíte — a že vám chybí jen formální razítko v podobě zaměstnání.
První testovací úkol: najděte chybu v běžné aplikaci Začněte u aplikací, které používáte denně — internetové bankovnictví, e-shop, mobilní hru nebo třeba kalendář. Zkuste si vytvořit jednoduchý testovací plán: co chcete ověřit, jaké kroky provedete a jaký výsledek očekáváte. Zaznamenejte si každou odchylku od očekávání, ať je sebemenší. Pozor na typickou chybu začátečníků: testují jen šťastnou cestu, tedy že vše funguje, když uživatel dělá přesně to, co aplikace předpokládá. Skutečný tester musí zkoušet i neobvyklé vstupy, prázdná pole, neplatné formáty nebo rychlé klikání. Právě tam se skrývá nejvíce chyb.
Pozor na častý nešvar: testovat bez záznamů. Když jen „něco zkoušíte” a výsledky si nepíšete, nemůžete se pochlubit žádným konkrétním výstupem. Veďte si jednoduchou tabulku s datem, testovanou verzí aplikace, krokem, očekáváním a skutečným výsledkem. Taková dokumentace je zároveň skvělou přípravou na pracovní pohovor, kde se vás zeptají na váš postup. Personalisté ocení, když jim ukážete, že umíte myslet systematicky a že vaše testování není náhodné klikání.
Nezapomeňte na okrajové případy. První test obvykle pokrývá hlavní scénář, ale kvalitní test by měl zahrnovat i prázdné hodnoty, nulové vstupy nebo maximální velikosti. Není nutné pokrýt hned všechny, ale alespoň jeden okrajový případ vám pomůže odhalit skryté problémy. Pište testy čitelně — název testu by měl popisovat chování, které ověřuje, ne jen číslo metody. Takový přístup usnadní údržbu, až se ke kódu vrátíte za několik týdnů.
První unit test obvykle vzniká s nejlepším úmyslem, ale často končí jako test, který testuje špatnou věc, nebo rovnou testuje implementaci místo chování. Než začnete psát, určete si, co přesně chcete ověřit. Vezměte si jednu konkrétní metodu nebo funkci a definujte si vstup, očekávaný výstup a okrajové případy. Pokud nedokážete říct, co má test dokázat, ještě nezačínejte psát kód.
Když nasadíte JWT tokeny jako ochranu API, obvykle věříte, že je tím vyřešeno vše. Realita je ale jiná: většina bezpečnostních incidentů s JWT nevzniká kvůli prolomení podpisu, ale kvůli chybám v implementaci. Nejčastěji jde o špatné ověření podpisu, nevhodnou volbu algoritmu nebo o to, že vývojář spoléhá na token, který už dávno neměl platit. V tomto textu se zaměříme na konkrétní chyby, kterých se vyvarovat, a na postupy, které skutečně fungují.
Nejčastější chybou bývá testování příliš mnoha věcí najednou. Jeden test by měl ověřovat jednu konkrétní věc. Pokud test selže, musíte hned vědět, co je špatně. Vyhněte se také testování vnitřních detailů implementace, jako je pořadí volání metod nebo soukromé proměnné. Testujte pouze veřejné rozhraní. Pokud se později rozhodnete refaktorovat vnitřní kód, test by měl zůstat beze změny. To je klíč k tomu, aby testy skutečně chránily funkčnost, a ne jen aktuální podobu kódu.
Jak začít s prvním testem bez zbytečných komplikací Nejprve si připravte prostředí. Vyberte si testovací framework, který odpovídá jazyku vašeho projektu. V Javě to bývá JUnit, v C# xUnit nebo NUnit, v Pythonu pytest. Ujistěte se, že máte v projektu správně nastavenou strukturu — testy patří do samostatné složky, oddělené od produkčního kódu. Vytvořte jednoduchý test, který ověří, že se metoda chová podle očekávání pro běžný vstup. Nepoužívejte žádné závislosti na databázi, síti ani jiných službách — test musí být rychlý a izolovaný.
Retrospektiva týmu často skončí u povzdechů, mlčení nebo donekonečna omílaných stejných problémů. Nejde o to, že by lidé neměli co říct, ale že chybí bezpečný a jasný rámec, jak se vyjádřit. Strukturovaná zpětná vazba mění chaotickou diskusi v cílenou práci s konkrétními výstupy. Než ale začnete, ujasněte si, co od setkání čekáte: máte najít úzká místa, rozhodnout o změně procesu, nebo jen posílit důvěru? Od toho se odvíjí výběr techniky i délka setkání.
Jak na to: jednoduchá technika Start-Stop-Continue Nejlepší je začít metodou, kterou všichni znají a která nevyžaduje žádné pomůcky. Každý člen napíše na tři sloupce: co by měl tým začít dělat, co přestat dělat a v čem pokračovat. Důležité je pravidlo: každý bod musí být konkrétní, ne obecný komentář. Místo „zlepšit komunikaci” napište „každé ráno 5 minut sdílet, na čem dělám”. Pak hlasujte tečkami – každý má tři hlasy na nejpalčivější položky. Vyberte jednu akci z každého sloupce a dohodněte, kdo ji zajistí a do kdy. Tím se vyhnete klasické chybě: retrospektiva skončí, ale nikdo neví, co se bude dít dál.
