Certifikát, nebo portfolio: co rozhoduje při hledání první práce v testování

Při samotné opravě se vyhněte dvěma častým chybám. První je snaha opravit chybu a zároveň přidat vylepšení — tím se ztrácí přehled o tom, co změnu způsobilo. Druhá je oprava bez testu, který selhání původně odhalil. Napište test, který chybu reprodukuje, teprve pak upravte kód. Pokud test nejde napsat, je to signál, že problému ještě nerozumíte, a horká oprava může přinést víc škody než užitku.

Volba klíče rozhoduje o tom, zda limit omezí útočníka, nebo vaše uživatele. IP adresa je nejjednodušší, ale za NATem nebo proxy může jedna IP skrývat stovky lidí. Pokud aplikace běží za reverzní proxy, musíte správně důvěryhodnost hlaviček, jinak budete všechny požadavky vidět z jedné adresy. U přihlášených uživatelů je lepší klíčovat podle ID účtu nebo tokenu. U veřejných endpointů kombinujte IP s cestou. Okno volte podle chování – pro přihlašování stačí krátké okno v řádu minut, pro API třeba delší. Vyhněte se pevnému oknu, které se resetuje v celou minutu, protože to vytváří nárazové špičky. Plynulé klouzavé okno nebo token bucket lépe rozloží zátěž v čase.

Moduly přinášejí čistší strukturu, ale mají vlastní pravidla. Importy se vyhodnocují jednou a platí pro celý běh aplikace, takže vedlejší efekty v modulu se spustí i tam, kde je nečekáš. Pojmenované importy musí přesně odpovídat exportům, jinak dostaneš chybu při načtení, ne za běhu. Výchozí export se importuje pod libovolným názvem, což svádí k nekonzistenci v projektu. Drž se jednoho stylu a názvy souborů i exportů udržuj shodné.

Filtrování navrhuj tak, aby každý podporovaný filtr měl odpovídající index. Kombinace více volitelných filtrů je zrádná: dotaz s pěti nepovinnými podmínkami se v praxi rozpadá na desítky variant a databázový plánovač přestane indexy používat. Řešením je omezit počet kombinací, zavést složené indexy přesně pro nejčastější scénáře, případně oddělit fulltextové hledání od strukturovaného filtrování. Vždy si ověř plán dotazu přes EXPLAIN, ne podle pocitu.

Dalším krokem je sledovat, jak dlouho review skutečně trvá. Nestačí jen odhadnout, že to „nějak půjde". Zapište si, kdy jste poslali kód k revizi, kdy přišly první komentáře a kdy jste dokončili poslední úpravu. Po několika úkolech uvidíte vzorec. Možná zjistíte, že review trvá déle v pátek odpoledne, nebo že kolega, který má na starosti bezpečnost, přidá vždy několik připomínek. To všechno jsou faktory, které patří do odhadu.

Reálný postup je nudný a pomalý: tři měsíce testuj jeden projekt, veď si záznamy, uč se pojmy, které při tom potkáš, a pak teprve oslovuj lidi s konkrétní ukázkou. Nepotřebuješ certifikát, abys ukázal, že umíš přemýšlet. Potřebuješ doklad, že jsi něco skutečně otestoval a dokázal to srozumitelně popsat.

Vyber si reálnou aplikaci, kterou používáš, a začni si vést testovací deník. U každé obrazovky si napiš, co má dělat, co dělá a co se stane, když uděláš něco neočekávaného. Zkoušej prázdné formuláře, příliš dlouhé vstupy, odpojení od sítě, dvojité odeslání, tlačítko zpět v prohlížeči. Každý nález zapiš takto: kroky k reprodukci, očekávaný výsledek, skutečný výsledek, prostředí a verze. Právě tahle struktura je to, co se v pohovoru hodnotí víc než znalost definic.

Základní technické znalosti drž na úrovni, kterou dokážeš obhájit. Rozuměj tomu, co je HTTP požadavek, stavové kódy, databázový dotaz, log soubor, rozdíl mezi frontendem a backendem. Nauč se základy SQL, práce s prohlížečem a čtení chybových zpráv. Automatizaci nech na později, ale věz, že existuje nástroj pro spouštění testů a že testy mají být opakovatelné. Nepředstírej znalost, kterou nemáš — první technický pohovor to odhalí a ztratíš kredibilitu i u pozic, kde by stačilo málo.

Nakonec platí, že odhad je jen odhad. Nikdy nebude přesný na minutu. Ale pokud do něj systematicky zahrnete code review a zapracování připomínek, přestanete být frustrovaní z neustálého přetahování. A to je nakonec to, co všichni chtějí – předvídatelnost a méně stresu.

Vstup do testování bez předchozí praxe je možný, ale nefunguje přes životopis poskládaný z kurzů a odznaků. Zaměstnavatelé u juniorních pozic řeší jednu otázku: umí ten člověk najít chybu a popsat ji tak, aby ji vývojář opravil? Kurz ti dá slovníček pojmů, ale tenhle návyk získá jen ten, kdo skutečně testuje nějaký software. Proto první krok není hledat nabídky, ale najít si něco, co můžeš rozbíjet.

Co mají v portfoliu ti, kdo projdou Portfolio nemusí být web. Stačí jeden soubor nebo veřejné úložiště s deseti až patnácti nahlášenými chybami, ke každé screenshot nebo krátké video a jasný popis. Přidej k tomu jeden menší testovací scénář pro nějakou funkci a seznam toho, co bys netestoval ručně, protože to patří automatizaci. Důležité je přiznat, co jsi nedotestoval a proč — to ukazuje úsudek, ne slabost. Vyhni se opisování cizích šablon; hodnotitelé je poznají během prvních vět.