Príklad:
Predstavte si mobilnú bankovú aplikáciu, kde sa zákazník neprihlasuje heslom, ale potvrdí vstup buď odtlačkom prsta, rozpoznaním tváre, alebo jednorazovým kódom cez mobilný token. Tento spôsob je dnes bežný v bankovníctve – heslo je slabé miesto, biometria či token výrazne zvyšujú bezpečnosť.
Ako to otestovať?…
1. Overenie toku autentifikácie:
2. Správnosť a jedinečnosť kódu:
Zobrazí sa, ale nie je to správne. Alebo sa nezobrazí vôbec.
Aj takto môže vyzerať tlačová zostava v aplikácii, ak nefunguje dobre šablóna (template), cesta k nej alebo samotné generovanie.
Príklad z praxe:
Tester si chcel overiť tlačovú zostavu, ktorá sa generuje z používateľských údajov. V aplikácii bol odkaz na štandardné vzory, no konfigurácia ukazovala na iný adresár.…
Príklad:
Predstav si firemnú aplikáciu, kde zamestnanci nahrávajú faktúry vo formáte PDF. Účtovníčka stiahne súbor a uloží ho do archívu. Po nasadení novej verzie zistia, že niektoré súbory sa nedajú otvoriť, majú nesprávny názov alebo link na stiahnutie smeruje do iného adresára (napr. na inú tlačovú zostavu).…
Príklad:
Predstav si, že program na fakturáciu s mesačným/ročným predplatným (SaaS aplikácia) má naplánovanú nočnú odstávku kvôli migrácii databázy. Počas tohto obdobia by mal byť systém nedostupný – ale používateľ nemá vidieť len „chybu 500“. Mal by ho privítať oznam, ktorý mu zrozumiteľne vysvetlí, čo sa deje.…
Príklad:
Predstav si e-shop, ktorý na spracovanie platieb využíva externú platobnú bránu. Zákazník prejde celým procesom nákupu, vloží tovar do košíka, vyplní údaje, zvolí platbu kartou – a v tom sa platobná brána stane nedostupnou. Dôvod môže byť plánovaná údržba, neočakávaný výpadok, sieťový problém alebo chyba na strane poskytovateľa.…
Príklad:
Predstav si e-shop, ktorý spustil novú verziu katalógu produktov. Dizajnér zmenil farby tlačidiel, upravil font nadpisov a pridal viac miesta medzi jednotlivé položky filtrov. Tester má preveriť, či sa tieto zmeny prejavili presne podľa návrhu a či sa nezmenilo nič, čo sa meniť nemalo – napríklad rozbité zarovnanie textu, posunuté obrázky alebo neviditeľné tlačidlá.…
Predstav si, že testuješ aplikáciu na evidenciu dochádzky vo firme. Nový zákazník si práve kúpil program a po prvom prihlásení musí:
Niektoré funkcie (napr.…
Príklad:
Predstavte si, že testujete aplikáciu, kde sa v testovacom prostredí zobrazuje nové tlačidlo „Exportovať report“. Na vývoji to fungovalo, ale na teste sa to správa inak – neodosiela žiadosť na server. Na produkcii sa tlačidlo ani nezobrazuje. Problém? Zlá konfigurácia prostredí.
Pri testovaní medzi prostrediami sa nekontroluje len funkcionalita, ale aj správna konfigurácia, verzie, feature toggles či dáta.…
Predstav si, že aplikácia prešla aktualizáciou a k tabuľke objednavky boli pridané nové stĺpce: zdroj_objednavky a typ_zakaznika. Backend už tieto hodnoty ukladá, UI ich zobrazuje, a reporty sa majú čoskoro meniť.
Ako to celé otestovať, aby si mal(a) istotu, že nič neuniklo?
`INSERT, UPDATE, DELETE`… v testoch nestačí len kliknúť. Treba sa pozrieť, čo sa reálne zmenilo v databáze.
Príklad:
Tester vyplní formulár objednávky a stlačí tlačidlo Vytvoriť. Objednávka je vytvorená a zobrazí sa v zozname objednávok.
Otázka je: Naozaj vznikla nová objednávka v databáze? A má správne údaje?…
Nie všetky autocomplete fungujú rovnako. Niektoré sa učia z tvojich predchádzajúcich vstupov, iné čerpajú zo širokej databázy a hneď ponúkajú návrhy.
Predstavte si pole na zadanie výrobku v e-shope. Používateľ napíše „pracka“ a systém mu navrhne:
Záleží na tom, či vie pracovať s diakritikou, ako rozumie významom a čo má v dátach.…
Predstav si, že testuješ aplikáciu, kde si používateľ môže vygenerovať report o tržbách za zvolené obdobie – podľa krajiny, typu produktu a stavu objednávky.
Čo všetko treba pri testovaní overiť?
1. Kombinácie filtrov
2.…
V dnešnej dobe sú Excelové exporty základným spôsobom, ako zdieľať a analyzovať dáta. Ak ale pri exporte niečo nefunguje, môže to viesť k chybným reportom, zle interpretovaným výsledkom a strate času. Preto by mal každý QA inžinier či analytik mať pripravený jednoduchý, no dôkladný check-list.
Príklad:
Predstavte si interný systém na správu podujatí – organizátori môžu pridávať eventy, upravovať detaily alebo pozývať účastníkov. Dobrovoľníci majú prístup len na čítanie. A bežní používatelia môžu vidieť len verejné podujatia. Všetko beží cez REST API.
Čo všetko treba otestovať:
V niektorých systémoch býva soft delete implementovaný veľmi jednoducho – záznam sa fyzicky neodstráni, len sa v databáze nastaví určitá hodnota (napr. is_deleted = true alebo stav = ‚zmazané‘).
Vďaka tomu sa dá záznam opäť zobraziť úpravou tejto hodnoty, ak je na to oprávnenie. V logoch alebo histórii záznamu býva zaznamenané, kto a kedy záznam zmazal.…
Príklad z praxe:
Testujem aplikáciu, ktorá má byť dostupná v slovenčine, angličtine a arabčine. Prepnem jazyk na arabčinu – text sa síce preložil, ale rozloženie stránky sa nerozbilo? Fajn. Ale dátum má stále európsky formát, nie arabský. A fallback jazyk? Namiesto angličtiny sa zobrazuje poľština… 🤯
Na čo sa zamerať pri testovaní lokalizácie?…
Bez záznamov niet retrospektívy. A bez retrospektívy niet analýzy ani zlepšovania.
Príklad:
Testujem webovú aplikáciu pre interný informačný systém. Pridám nový záznam do databázy a úmyselne zmením dátum narodenia na neplatný formát. Aplikácia zobrazí chybu – ale čo ďalej?
Otváram logy – očakávam, že:
od košíka po potvrdenie?
Príklad:
Predstavte si, že testujete e-shop s oblečením. Zákazník si do košíka pridá tričko a bundu. Vyberie osobný odber v Bratislave a platbu kartou. V poslednom kroku sa však suma zrazu zvýši – bez dôvodu. Takéto situácie musíme odhaliť pred tým, než sa dostanú k zákazníkovi.…
Zmeny roly môžu výrazne ovplyvniť, čo používateľ vidí, čo môže robiť a čo má zakázané. A práve to je výzva pre testerov.
Príklad:
Máme interný systém, kde môže byť používateľ zamestnancom, manažérom alebo adminom. Každá rola má iné oprávnenia – napríklad zamestnanec môže vidieť len svoje dáta, manažér údaje svojho tímu a admin všetko vrátane nastavení systému.…
