Portfolio · softwarové testování
Tester · přechod z procesní a datové role do IT
Posouvám se do testování softwaru po 7 letech v koordinaci procesů, operations a účetnictví — z práce, kde se denně hlídá přesnost dat, dodržují se postupy a problémy se jasně reportují. Komerční praxi v testování zatím nemám, zato mám za sebou kompletní cyklus na reálné aplikaci: od ručního hledání chyb přes bug reporty a API testy až po ověřování dat v databázi a návrh testovacích případů.
Čtyři ukázky odvedené práce. Klikni na kapitolu nebo použij menu nahoře.
6 nálezů z explorativního testování, bug reporty se severitou a re-testem.
Otevřít → 02 · API6 testů REST API — metody, stavové kódy, pozitivní i negativní případy.
Otevřít → 03 · DataOvěřování dat u zdroje pravdy — základní dotazy a tři pasti.
Otevřít → 04 · AnalýzaSystematická sada TC-01 až TC-05: pozitivní, negativní, hraniční.
Otevřít →Co konkrétně umím doložit na kapitolách výše.
Pozornost k detailu a přesnost dat. Roky v účetnictví a koordinaci procesů mě naučily všímat si nesrovnalostí a nespoléhat na „asi to sedí". Přesně to dělá tester s každou obrazovkou.
Procesy a dokumentace. Nastavoval jsem onboarding a předávací protokoly, psal checklisty. Testování je o stejné disciplíně: systematicky, krok za krokem, nic nevynechat.
Jasný reporting. Zvyk hlásit problémy srozumitelně a přesně — ne „nejde to", ale co, kde a za jakých okolností — je jádro dobrého bug reportu.
Kapitola 01 · Protokol o testování
Nálezy z ručního (explorativního) testování aplikace Evidence údržby jeřábů. Testováno na tabletu (Android), na hostované verzi.
*) nechat prázdné, odeslat.3 na 30 dní. Pozn. testera: 3denní předstih je u revize jeřábu provozně nebezpečný — nestihne se objednat termín.Záznamy se procházely systematicky přes čtyři „čočky", aby se pokrylo víc než jen běžný průchod:
Kapitola 02 · Protokol o testování
Testování REST API pro evidenci revizí. Ověřovaly se HTTP metody, stavové kódy a obsah odpovědí přes přímé dotazy na API (bez uživatelského rozhraní).
200 OK, 201 vytvořeno, 204 hotovo)400 špatný dotaz, 404 nenalezeno)500)| # | Dotaz | Vstup / záměr | Pohled | Oček. | Skutečnost | Výsledek |
|---|---|---|---|---|---|---|
| 1 | GET /revize/3 | Načíst existující revizi (Demag) | pozitivní | 200 | 200 + Demag | PASS ✅ |
| 2 | POST /revize | Uložit bez povinných polí | negativní | 400 | 400 | PASS ✅ |
| 3 | DELETE /revize/2 | Smazat existující revizi (Tatra) | pozitivní | 204 | 204 | PASS ✅ |
| 4 | DELETE /revize/7 | Smazat neexistující revizi | hraniční | 404 | 404 | PASS ✅ |
| 5 | GET /revize/99 | Načíst neexistující revizi | hraniční | 404 | 404 | PASS ✅ |
| 6 | POST /revize | Uložit kompletně vyplněnou revizi | pozitivní | 201 | 201 + nový záznam | PASS ✅ |
201 Created — konvence pro vytvoření nového záznamu přes POST. Obecné 200 OK by nebylo tvrdou chybou, ale nedodržením konvence → drobné doporučení, nikoliv bug.Kapitola 03 · Testování dat
Ověřování dat přímo u zdroje pravdy. Aplikace může zobrazit cokoli — co se ve skutečnosti uložilo, zjistí tester dotazem do databáze.
Tabulka revize — ber ji jako Excel se sloupci.
| id | jerab | datum | technik | vysledek | dalsi_revize |
|---|---|---|---|---|---|
| 1 | Liebherr LTM 1050 | 2026-09-10 | Novák | Vyhověl | 2027-09-10 |
| 2 | Tatra AD 28 | 2026-10-02 | Svoboda | S výhradami | 2026-11-24 |
| 3 | Demag AC 40 | 2026-07-18 | Dvořák | Nevyhověl | 2026-10-25 |
| 4 | Grove GMK 3050 | 2026-11-01 | Horák | Vyhověl | 2027-11-01 |
| 5 | Liebherr LTM 1090 | 2026-08-15 | Novák | Nevyhověl | 2026-11-30 |
| 6 | Tatra AD 20 | 2026-10-20 | Svoboda | Vyhověl | 2027-04-20 |
SELECTZáklad všeho — vrať mi řádky. SELECT * znamená „všechny sloupce".
SELECT * FROM revize
→ 6 řádků — celá tabulka.
WHEREJen řádky, které splní podmínku. Tady: které jeřáby u revize neprošly.
SELECT * FROM revize WHERE vysledek = 'Nevyhověl'
→ 2 řádky — Demag AC 40 (Dvořák) · Liebherr LTM 1090 (Novák).
COUNT(*)Nevrací řádky, ale jedno číslo. Na ověřování počtů, které hlásí aplikace.
SELECT COUNT(*) FROM revize WHERE technik = 'Novák'
→ 2 — tolik revizí dělal technik Novák.
ORDER BYPořadí výpisu. Vzestupně automaticky, sestupně přes DESC.
SELECT * FROM revize ORDER BY technik
→ 6 řádků podle abecedy: Dvořák → Horák → Novák → Novák → Svoboda → Svoboda.
Nejcennější část — každou jsem potkal naživo při psaní dotazů výše.
Past 1 · Velikost písmen & diakritika
SELECT * FROM revize WHERE technik = 'novak'
→ 0 řádků ❌ · s hodnotou 'Novák' → 2 řádky ✅
novak ≠ Novák — liší se velké písmeno i háček, a dotaz vrátí nulu. Pozor: nula tady neznamená „technik neexistuje", ale „hledám špatně napsanou hodnotu". Když má vyhledávání ignorovat velikost a diakritiku a neignoruje je → bug.
Past 2 · Rozbitý dotaz vs. nula výsledků
SELECT COUNT(*) FROM revize WHERE
→ CHYBA: incomplete input ❌ · bez WHERE → 6 ✅
Buď za WHERE je podmínka, nebo tam WHERE vůbec není. Tester musí rozlišit dotaz proběhl a vrátil 0 (data nejsou) od dotaz je špatně napsaný (spadl na syntaxi).
Past 3 · Řazení textu vs. data
SELECT * FROM revize ORDER BY datum
→ správné pořadí od nejstaršího po nejnovější.
Datum ve formátu 2026-09-10 se řadí správně i jako text. Ale kdyby bylo uloženo jako 10.9.2026, řadilo by se podle prvního znaku a 10.9. by skončilo před 9.9. Klasická chyba: tlačítko „seřadit podle data" seřadí vizuálně špatně.
Kapitola 04 · Testovací analýza
Systematické pokrytí jedné funkce místo náhodného šťourání. Každá situace má svůj případ, jasné kroky a přesný očekávaný výsledek — doložitelné a opakovatelné.
Analýza hraničních hodnot kolem zlomu „propásnuto / blíží se". Zlom je dnešek (5. 11. 2026), proto se testují tři data těsně kolem něj.
| ID | Datum další revize | Pozice | Očekávaný výsledek |
|---|---|---|---|
| TC-03 | 4. 11. 2026 | včera | propásnuto |
| TC-04 | 5. 11. 2026 | dnes (hrana) | blíží se — dnešek lze ještě řešit |
| TC-05 | 6. 11. 2026 | zítra | blíží se |
„Zobrazí se hláška" nestačí. U TC-02 se ověřují tři věci: hláška se zobrazí, formulář se neuloží a záznam se neobjeví v seznamu. Důvod: aplikace může ukázat hlášku „pole je povinné" a přesto uložit. Volně napsaný očekávaný výsledek by takovou chybu propustil.
Dvakrát se ukázalo, že zadání mlčí: (1) má být datum další revize v minulosti vůbec přijato, nebo odmítnuto? (2) Jaká přesně hláška platí v samotný den termínu? Tester si odpověď nevymýšlí — označí nejasnost a ptá se, čímž chytá chyby dřív, než vzniknou.