Príklad
Predstav si mýtny systém, ktorý spracúva prejazdy vozidiel cez kamery alebo palubné jednotky.
Prejazd sa zaznamená na bráne o 10:00, ale do centrálneho systému sa dostane až o 10:07 – napríklad kvôli dočasnému výpadku siete alebo dávkovému spracovaniu.
Z pohľadu používateľa to môže vyzerať zvláštne:
Príklad
Predstav si dopravcu, ktorý jazdí kamiónom z Bratislavy cez Rakúsko do Talianska. Vozidlo má jednu palubnú jednotku (OBU), ktorá má fungovať vo viacerých krajinách. Pri prejazde hranicou systém automaticky prepne tarifný model a začína účtovať mýto podľa pravidiel danej krajiny.
Ak však integrácia medzi systémami nefunguje správne, môžu nastať rôzne problémy:
Príklad
Predstav si úsek diaľnice, kde už nie sú závory ani mýtne brány. Vozidlo prejde pod portálom a systém automaticky načíta údaje z palubnej jednotky (ENC) alebo z kamerového systému (free-flow).
Vodič nič neplatí na mieste – suma sa zaúčtuje dodatočne podľa prejdeného úseku.
Na papieri jednoduché.…
Vozidlo prechádza mýtnym úsekom, no palubná jednotka (OBU) stratí GPS signál v tuneli.
Po výjazde zo zóny sa signál obnoví, ale systém zaznamená len časť trasy. Výsledok?
Nesprávne vypočítané mýto, reklamácia dopravcu a otázka: kto je zodpovedný – zariadenie, infraštruktúra alebo backend?
Výpadok signálu nie je výnimočná situácia.…
Príklad
Klient zadá platbu kartou v mobile. Po potvrdení 3-D Secure v bankovej appke vypadne internet. Frontend „zamrzne“, zákazník klikne späť a skúsi to znova. Výsledok? Dve autorizácie, jedno zaúčtovanie, nejasné hlášky a nahnevaný klient. Cieľ testu: systém musí byť odolný voči duplicitnému spracovaniu, správať sa predvídateľne a po obnovení pripojenia sa korektne zotaviť.…
Príklad
Predstav si, že bankár založí v CRM nový profil klienta a rovno vytvorí úverovú zmluvu. Ak sa pole „trvalý pobyt“ uloží len v CRM, ale nedostane sa do zmluvy, dokument je právne neplatný. Ešte horší scenár nastane, ak systém doplní nesprávne údaje zo starej verzie profilu.…
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:
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.…
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:
V aplikácii existuje CRON úloha, ktorá „každú noc o 02:00“ spracuje zoznam používateľov a „odosiela im sumarizačný e-mail s dennými notifikáciami“ (napr. neprečítané správy, nové úlohy, zmeny v kalendári). Úla je naplánovaná cez `cron` príkaz na serveri, volá backendový skript, ktorý pracuje s databázou a e-mailovým serverom.…
Príklad:
GET /api/products?page=2&limit=10
Očakávame odpoveď v JSON formáte s 10 produktmi na druhej stránke výsledkov.
Čo všetko je potrebné otestovať?
1. Formát odpovede
2. Počet záznamov
