Príklad
Vodič kamióna zistí, že mu systém naúčtoval mýto dvakrát za ten istý úsek. Podá reklamáciu cez zákaznícky portál, priloží evidenčné číslo prejazdu a čaká na vyjadrenie.
Ak systém nesprávne spáruje prejazdy, neoverí duplicitu alebo refundáciu pošle na nesprávny účet, problém sa neobmedzí len na jednu chybu v účtovaní – zasiahne účtovníctvo, reporting aj dôveru zákazníka.…
Príklad
Predstav si dopravnú spoločnosť, ktorá dostane mesačnú faktúru za prejazdy po spoplatnených úsekoch.
Faktúra obsahuje desiatky položiek – dátum, čas, úsek, sadzbu podľa hmotnosti vozidla, emisnú triedu a výslednú sumu.
Na prvý pohľad sedí celková suma.
Ale účtovníčka si všimne, že pri dvoch prejazdoch je použitá nesprávna sadzba pre nápravový počet.…
Príklad
Klient zaplatí objednávku kartou. Platobná brána zobrazí chybu „Platba zlyhala“, no suma je z účtu stiahnutá. Klient skúsi zaplatiť znova – systém prijme druhú platbu a objednávka sa vytvorí dvakrát.
Z pohľadu biznisu ide o citlivý moment: dôvera zákazníka, peniaze aj reputácia sú v hre.…
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 klienta, ktorý po rokoch využívania bankovej aplikácie požiada o zrušenie účtu a vymazanie všetkých svojich osobných údajov. Ak systém údaje nesprávne ponechá (napr. e-mail v marketingovej databáze alebo históriu prihlásení v logoch), vzniká riziko porušenia GDPR a vysokých pokút. Tester má preto overiť, že proces výmazu je konzistentný, auditovateľný a nezanecháva citlivé zvyšky.…
Príklad
Klient nahlásil, že zamestnanec pobočky upravil kontaktné údaje na účte bez súhlasu. Prišiel s tým, že operácia prebehla rýchlo, bez viditeľného auditu. Po preštudovaní záznamov sa zistilo, že pracovník mal nadlimitované práva (možnosť upravovať údaje) a systém nezaznamenal detailné kroky (kto, kedy, aké polia), čo skomplikovalo vyšetrenie a spätnú opravu.…
Príklad
Klient si všimne, že jeho účet zobrazuje -12,34 € po zaúčtovaní poplatku a súčasne mu aplikácia umožní zadať ďalšiu platbu, ktorá by mala byť zablokovaná. Takéto situácie poškodzujú dôveru zákazníka a môžu viesť k penalizáciám alebo nesprávnym účtovacím reportom. Nižšie sú praktické kroky, ako takéto prípady nájsť a otestovať pred nasadením do produkcie.…
Príklad
Predstav si klienta, ktorý požiada o spotrebný úver. Systém má presne nastavené workflow – od zadania žiadosti, cez kontrolu bonity, scoring, schválenie, až po podpis zmluvy a uvoľnenie peňazí. Ak sa niekde proces zasekne (napr. scoring sa nespustí, alebo dokumenty čakajú v schvaľovaní u nesprávneho pracovníka), klient čaká zbytočne a banka prichádza o dôveru aj príjem.…
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 klienta, ktorý doteraz používal osobný účet. Rozhodne sa založiť živnosť a banka mu ponúkne prechod na podnikateľský účet. Ak by systém nepreklopil správne všetky údaje – trvalé príkazy, limity, história transakcií či prístup do internet bankingu – klient sa môže dostať do problémov.…
Príklad
Klient si chce otvoriť účet cez mobilnú aplikáciu. Aplikácia požiada o nahratie fotografie dokladu (občiansky preukaz/pas) a selfie na overenie zhody tváre. Po úspešnom overení systém aktivuje účet; pri chybe sa žiadosť zamietne a používateľ dostane vysvetľujúcu správu. Cieľ testovania: overiť, že proces je spoľahlivý, bezpečný, používateľsky zrozumiteľný a súladný s právnymi a ochrannými požiadavkami (GDPR/KYC).…
Príklad
Predstav si, že si nový klient a chceš si založiť účet cez mobilnú aplikáciu. Stiahneš si ju, otvoríš a čakáš, že proces bude rýchly a intuitívny. Namiesto toho sa zasekneš už pri nahrávaní dokladu totožnosti – aplikácia padne a musíš začať odznova. Takéto zlé skúsenosti odradia ľudí hneď na začiatku a banka prichádza o potenciálneho zákazníka.…
Príklad
Predstav si účtovníčku, ktorá si stiahne výkaz pohybov na účte, aby spárovala bankové operácie s účtovníctvom. Očakáva, že každá platba, poplatok či úrok bude jasne viditeľný a bude sa dať priradiť k účtovnému dokladu. Ak je formát nezrozumiteľný, chýba variabilný symbol alebo sú poplatky zlúčené bez detailu, účtovníctvo sa dostáva do chaosu – výkazy strácajú význam a proces párovania sa spomaľuje.…
Príklad
Predstav si, že klient si otvorí internetbanking a chce si skontrolovať, koľko ho stál účet za posledný mesiac. V prehľade však vidí poplatok za výber z bankomatu, aj keď výber bol z vlastného bankomatu, kde mal mať výber zdarma. Alebo sa mu vygeneruje úrok z povoleného prečerpania, ktorý je vypočítaný nesprávne podľa sadzby.…
Príklad:
Klientovi neprišiel augustový výpis. Po prihlásení do internetbankingu ho síce vidí, ale v PDF chýba posledných 6 platieb a úvodný zostatok nesedí o 0,23 €. Príčina? Dávkový proces bežal ešte pred uzávierkou, cron sa kvôli letnému času posunul o hodinu a konverzia CZK→EUR zaokrúhlila inak v exporte než v účtovníctve.…
Príklad
Predstav si, že klient zadá platbu v CZK, systém ju prevedie do EUR so zlým zaokrúhlením — príjemca dostane o pár centov menej, zákazník volá na support a reputácia trpí. Testovanie zahraničných platieb nie je len o „odoslať peniaze“ — ide o kurzy, poplatky, formáty, settlement a súlad s legislatívou.…
Predstavte si klienta, ktorý si nastaví trvalý príkaz na úhradu nájmu každý mesiac k 15. dňu v sume 750 €. Po čase zmení číslo účtu prenajímateľa, no zároveň chce, aby starý príkaz zanikol a nový sa vykonával bez prerušenia. Ak systém spracuje oba príkazy súčasne alebo naopak žiadny, vznikajú vážne komplikácie – od dvojnásobnej úhrady až po omeškanie platieb.…
Predstav si situáciu: klient chce zaplatiť vysoký účet kartou v zahraničí. Transakcia presiahne jeho nastavený denný limit a platba je zamietnutá. Následne mu príde SMS aj push notifikácia, že transakcia bola zablokovaná kvôli limitu. Klient tak vie, že systém funguje správne, jeho peniaze sú v bezpečí a zároveň má informáciu, čo sa stalo.…
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.…
