Príklad:
Predstav si, že klient zadáva SEPA platbu v internet bankingu. Vyplní IBAN príjemcu, zadá sumu a dátum splatnosti. Následne systém zobrazí chybu: „Nesprávny formát IBAN“. V praxi sa často stáva, že klienti uvedú o jeden znak viac alebo menej, alebo preklepnú číslo. Úlohou testera je preveriť, že aplikácia takéto chyby správne zachytí a používateľovi poskytne jasné hlásenie.…
Príklad:
Predstav si situáciu: zákazník dostane faktúru s QR kódom, ktorý obsahuje všetky potrebné údaje pre platbu (IBAN, suma, variabilný symbol). Stačí ho nasnímať v mobilnej bankovej aplikácii a údaje sa automaticky vyplnia. Rýchle, pohodlné, ale aj veľmi citlivé na chyby – stačí malý detail a platba môže byť odoslaná nesprávne.…
Príklad:
Predstav si situáciu: zákazník sa prihlási do internetového bankovníctva a očakáva, že uvidí správny zostatok, všetky svoje transakcie a výpis za vybrané obdobie. Ak sa zobrazia nesprávne údaje alebo sú neúplné, môže to spôsobiť stratu dôvery voči banke a zbytočné reklamácie.
Príklad:
Zákazník si v aplikácii zapne notifikácie pre karty: platby nad 20 €, výbery z bankomatu a prihlásenia do IB. Po platbe kartou 35 € očakáva push do 10 sekúnd, ak nie je online tak SMS do 1 minúty, a súhrnný e-mail na konci dňa. V praxi sa mu zobrazí push s nesprávnym zostatkom, SMS príde duplicitne a e-mail dorazí s chybným formátovaním sumy.…
Príklad:
Banka spustila novú mobilnú aplikáciu, ktorá má klientom umožniť rýchle a bezpečné zadávanie platieb, kontrolu zostatkov a notifikácie o pohyboch na účte. Tester dostane úlohu overiť, či aplikácia funguje spoľahlivo na rôznych zariadeniach a neohrozuje bezpečnosť klientov.
Príklad:
Predstav si banku, ktorá zaviedla nový systém na detekciu podozrivých transakcií.
Zákazník napríklad nikdy neposielal peniaze do zahraničia a zrazu zadá prevod vysokej sumy na účet v inej krajine. Systém má takúto anomáliu zachytiť a transakciu označiť alebo dočasne zablokovať.
Ako tester však musíš overiť, či systém funguje správne – či dokáže rozlíšiť bežné správanie od skutočne podozrivého a či zbytočne neblokuje klientov.…
Príklad:
Predstav si, že si tester v banke a máš za úlohu overiť, že bežný zákazník nemá prístup k údajom iného klienta. V praxi to znamená, že ak sa prihlásim ako používateľ A, nesmiem vidieť zostatky, IBANy ani výpisy používateľa B – a naopak.
V jednej firme, kde som testovala, sa stalo, že backend posielal viac údajov, než bolo potrebné.…
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.…
