Meniu

Cum să testați aplicațiile domeniului bancar: un ghid complet de testare BFSI

how test banking domain applications

Încercați Instrumentul Nostru Pentru Eliminarea Problemelor

Un ghid complet pentru testarea aplicației bancare: Procesul și sfaturile de testare BFSI (servicii bancare, servicii financiare și asigurări)

Aplicațiile bancare sunt una dintre cele mai complexe aplicații din industria de dezvoltare și testare software de astăzi.

Ce face ca aplicațiile bancare să fie atât de complexe? Ce abordare ar trebui urmată pentru a testa fluxurile de lucru complexe implicate în aplicațiile bancare?

În acest articol, vom evidenția diferite etape și tehnici implicate în testarea aplicațiilor bancare.

Cum să testați aplicațiile bancare

Ce veți învăța:

Cum să testați aplicațiile bancare?

Diverse funcții îndeplinite de aplicațiile bancare sunt:

Funcțiile băncilor

Să înțelegem mai întâi caracteristicile unei aplicații bancare:

  • Funcționalitate pe mai multe niveluri pentru a susține mii de sesiuni de utilizator simultane
  • Integrare pe scară largă: de obicei, o aplicație bancară se integrează cu numeroase alte aplicații, cum ar fi utilitatea Bill Pay și conturile de tranzacționare
  • Fluxuri de lucru complexe pentru afaceri
  • Procesare în timp real și în lot
  • Rata mare de tranzacții pe secunde
  • Tranzacții sigure
  • Secțiune de raportare robustă pentru a urmări tranzacțiile de zi cu zi
  • Audit puternic pentru depanarea problemelor clienților
  • Sistem de stocare masiv
  • Managementul dezastrelor / recuperării.

Cele zece puncte enumerate mai sus sunt cele mai importante caracteristici ale unei aplicații bancare.

Aplicațiile bancare au mai multe niveluri implicate în efectuarea unei operațiuni.

De exemplu , la Aplicația bancară poate avea:

  • Server Web pentru a interacționa cu utilizatorii finali prin intermediul browserului
  • Middle Tier pentru a valida intrarea și ieșirea pentru serverul web
  • DataBase pentru a stoca date și proceduri
  • Procesor de tranzacții care ar putea fi un mainframe de mare capacitate sau orice alt sistem vechi pentru a efectua miliarde de tranzacții pe secundă.

Dacă vorbim despre testarea aplicațiilor bancare, este nevoie de un Metodologia de testare End to End care implică mai multe tehnici de testare software pentru a asigura:

  • Acoperirea totală a tuturor fluxurilor de lucru bancare și a cerințelor de afaceri
  • Aspectul funcțional al aplicației
  • Aspectul de securitate al aplicației
  • Integritatea datelor
  • Concurență
  • Experiența utilizatorului

Ce face ca aplicațiile bancare să fie atât de complexe?

  • Software-ul bancar tratează în principal datele financiare confidențiale, astfel încât performanța software-ului ar trebui să fie fără erori și sigură.
  • Dezvoltatorii preferă un design complicat pentru a dezvolta aceste aplicații pentru a se asigura că aplicația rulează într-o manieră sigură dorită.
  • Banca este o lume în continuă schimbare. Astăzi, serviciile bancare sunt puse la dispoziția clienților folosind diferite canale, cum ar fi sucursale de cărămidă și mortar, bancomate, servicii bancare online și asistență pentru clienți.
  • Odată cu apariția tehnologiei, multe portofele au inundat piețele care se conectează la sistemele bancare pentru tranzacții financiare.
  • Banca se așteaptă, de asemenea, să funcționeze 24 X 7 cu performanțe ridicate. Actualizările de software, remedierile instantanee etc. nu pot fi permise să afecteze această disponibilitate.
  • Lumea bancară este, de asemenea, puternic afectată de schimbările constante aduse de guvern sub forma reglementărilor bancare. Orice modificare a structurii fiscale afectează și sistemul bancar.
  • De asemenea, sistemul bancar trebuie să fie actualizat în ceea ce privește noile tehnologii. Analiza datelor, cum ar fi Big Data Processing și obținerea instinctelor din big data folosind Data Science, crește din ce în ce mai mult în lumea bancară.

Punctele menționate mai sus fac ca sistemul bancar să fie complex pentru dezvoltatori să creeze o aplicație software în jurul acestuia.

Importanța testării aplicației bancare

  • Testarea aplicației bancare asigură faptul că toate activitățile nu sunt doar executate bine, ci și rămân protejate și securizate.
  • Software-ul bancar este complicat cu mii de dependențe, procesul de testare necesită mai mult timp, resurse și monitorizare continuă.
  • Deoarece finanțele sunt implicate aici, orientările trebuie respectate cu strictețe. Atât testerii, cât și dezvoltatorii ar trebui să aibă cunoștințe bune despre domeniu.
  • Cel mai important, trebuie să se asigure că legile și reglementările sunt aplicate corect în tranzacțiile financiare. Acest lucru poate fi asigurat numai cu testarea.
  • De asemenea, este important să vă asigurați că aplicația și infrastructura pe care a fost implementată aplicația sunt capabile să facă față sarcinii, în special în timpul orelor de lucru de vârf, fără a provoca nicio întrerupere. Acest lucru poate fi asigurat prin efectuarea de teste de performanță.
  • În lumea digitală de astăzi, singurul lucru care îi preocupă pe toți este cel al securității. Aplicațiile bancare și tranzacțiile financiare care sunt efectuate în cadrul acesteia trebuie să fie sigure de orice încercare de intrare. Acest lucru poate fi asigurat prin efectuarea de teste de securitate. Testarea securității ajută la aplicarea standardelor din industrie pentru securizarea tranzacțiilor financiare.
  • De asemenea, este important să vă asigurați că diferite module ale unei aplicații bancare și integrate în mod corespunzător și să atingă obiectivul clientului. Testarea integrării sistemului ajută la realizarea acestei sarcini.

Fluxul de lucru pentru testarea aplicațiilor bancare

Etape tipice implicate în testarea aplicațiilor bancare sunt prezentate în fluxul de lucru de mai jos. Vom discuta fiecare etapă individual.

Acesta este un model Waterfall de testare a unei aplicații.

Testarea aplicațiilor bancare

# 1) Adunarea cerințelor

Cerință Faza de adunare implică documentarea cerințelor fie ca specificații funcționale, fie ca cazuri de utilizare. Cerințele sunt colectate conform nevoilor clienților și sunt documentate de experți bancari sau de analist de afaceri.

Adunarea cerințelor

Experții sunt implicați în redactarea cerințelor pentru mai multe subiecte, deoarece serviciile bancare în sine au mai multe subdomenii, iar o aplicație bancară completă va fi integrarea tuturor acestor domenii.

De exemplu, O aplicație bancară poate avea module separate pentru transferuri, carduri de credit, rapoarte, conturi de împrumut, plăți de facturi, tranzacționare etc.

# 2) Revizuirea cerințelor

Livrabilul de colectare a cerințelor este revizuit de toți părțile interesate, cum ar fi inginerii de asigurare a calității, liderii de dezvoltare și analiștii peer business.

Revizuirea cerințelor

Verifică încrucișat faptul că nu sunt încălcate nici fluxurile de lucru ale afacerii existente, nici fluxurile de lucru noi. Toate cerințele sunt verificate și validate. Acțiunile de urmărire și revizuirile documentelor de cerințe se fac pe baza acelorași.

# 3) Pregătiri pentru scenariul de afaceri

În această etapă, inginerii QA derivă scenarii de afaceri din documentele cerințelor (specificații funcționale sau cazuri de utilizare); Scenariile de afaceri sunt derivate în așa fel încât toate cerințele de afaceri sunt acoperite. Scenariile de afaceri sunt scenarii la nivel înalt, fără pași detaliați.

Mai mult, aceste scenarii de afaceri sunt revizuite de analisti de afaceri pentru a se asigura că sunt îndeplinite toate cerințele de afaceri. Este mai ușor pentru BA să revizuiască scenarii la nivel înalt, mai degrabă decât să revizuiască cazurile de test detaliate la nivel scăzut.

De exemplu , un client care deschide un depozit fix pe interfața bancară digitală poate fi un scenariu de afaceri. În mod similar, putem avea diferite scenarii de afaceri legate de crearea de conturi bancare nete, depozite online, transferuri online etc.

# 4) Testarea funcțională

În această etapă, se efectuează testarea funcțională și se efectuează activitățile obișnuite de testare a software-ului, cum ar fi:

Pregătirea cazului de testare: În această etapă, cazurile de testare sunt derivate din scenarii de afaceri, un scenariu de afaceri duce la mai multe cazuri de testare pozitive și cazuri de testare negative. În general, instrumentele utilizate în această etapă sunt Microsoft Excel, Director de testare sau Quality Center.

Revizuirea cazului de testare: Recenzii ale inginerilor QA de la egal la egal

Caz de testare Execuţie: Execuția cazului de testare poate fi manuală sau automată, implicând instrumente precum QC, QTP etc.

Testarea funcțională a unei aplicații bancare este destul de diferită de testarea software obișnuită. Întrucât aceste aplicații funcționează cu banii clienților și cu date financiare sensibile, trebuie să fie testate temeinic. Nici un scenariu important de afaceri nu trebuie lăsat să fie acoperit.

De asemenea, resursa QA care testează aplicația ar trebui să aibă cunoștințele de bază despre domeniul bancar.

# 5) Testarea bazei de date

Aplicația bancară implică tranzacții complexe care se efectuează atât la nivelul interfeței de utilizare, cât și la nivelul bazei de date, prin urmare, testarea bazei de date este la fel de importantă ca testarea funcțională. Baza de date este complicată și un strat complet separat în aplicație și, prin urmare, testarea acesteia este efectuată de specialiști în baze de date. Folosește tehnici precum:

  • Încărcarea datelor
  • Migrarea bazei de date
  • Testarea schemei și tipurilor de date DB
  • Testarea regulilor
  • Testarea procedurilor și funcțiilor stocate
  • Testarea declanșatoarelor
  • Integritatea datelor

Scopul principal al testării bazelor de date este de a se asigura că:

  • Aplicația este capabilă să stocheze și să recupereze date din baza de date fără a pierde date.
  • Tranzacțiile finalizate ar trebui să fie angajate, iar tranzacțiile avortate sunt returnate înapoi pentru a evita orice nepotrivire în datele stocate.
  • Doar aplicațiile și utilizatorii autorizați au acces la baza de date și tabelele de bază.

Există în principal trei moduri de testare a bazelor de date:

  • Testarea structurală
  • Testarea funcțională
  • Testare nefuncțională

Testarea structurală

Aceasta implică testarea obiectelor bazei de date, cum ar fi baze de date, schemă, tabele, vizualizări, declanșatoare, controale de acces etc. Asigurarea faptului că tipurile de date din tabele sunt sincronizate cu variabilele corespunzătoare din aplicație. Validarea datelor și integritatea referențială în tabele.

De exemplu, Un câmp de sumă din aplicație trebuie să aibă un tip de date zecimal / plutitor în tabel.

- Pentru a respecta standardele, utilizatorii ar trebui să primească controale de acces prin intermediul vizualizărilor.

Testarea funcțională

Aceasta implică testarea bazelor de date care satisfac cerințele utilizatorilor. Există două modalități de realizare: testarea cutiei negre și testarea cutiei albe.

De exemplu, Când facem un transfer de bani online, contul expeditorului ar trebui să fie debitat, iar contul destinatarului să fie creditat cu exact aceeași sumă. În cazul în care tranzacția eșuează, atunci tranzacțiile întregi ar trebui anulate, iar contul expeditorului nu ar trebui să fie debitat sau creditat înapoi.

Testare nefuncțională

Aceasta implică testarea sarcinii și stresului și optimizarea performanței. Testarea încărcării ajută la identificarea celui mai mare număr de tranzacții care pot fi efectuate simultan fără a afecta performanța bazei de date.

De exemplu, Pe baza informațiilor din testarea sarcinii și a stresului, aplicațiile bancare pot decide să adauge mai multe resurse aplicației lor în timpul orelor de lucru de vârf și să reducă resursele în afara orelor de lucru. Acest lucru ajută banca să utilizeze optim resursele și să economisească bani.

# 6) Testarea securității

Testarea de securitate este de obicei ultima etapă a ciclului de testare. O condiție prealabilă pentru începerea testării de securitate este finalizarea testării funcționale și nefuncționale. Testarea securității este una dintre etapele majore ale întregului ciclu de testare a aplicațiilor, deoarece această etapă asigură respectarea standardelor federale și industriale.

Datorită naturii datelor pe care le transportă, aplicațiile bancare sunt foarte sensibile și sunt o țintă principală pentru hackeri și activități frauduloase. Testarea securității asigură faptul că aplicația nu are o astfel de vulnerabilitate web care poate expune date sensibile unui intrus sau unui atacator. De asemenea, asigură că aplicația respectă standarde precum OWASP.

În această etapă, sarcina majoră este scanarea întregii aplicații care se realizează folosind instrumente precum IBM AppScan sau HP WebInspect (acestea sunt cele mai populare instrumente).

După finalizarea scanării, se publică Raportul de scanare. În acest raport, falsurile pozitive sunt filtrate, iar restul vulnerabilităților sunt raportate echipei de dezvoltare, astfel încât să înceapă să remedieze problemele în funcție de gravitatea fiecărei probleme.

Testarea penetrării se face, de asemenea, la acest pas pentru a releva propagarea erorilor. Testarea riguroasă a securității ar trebui făcută pe platforme, rețele și sisteme de operare.

Unele altele Instrumente manuale pentru testarea securității utilizate sunt Paros Proxy , Ceas Http , Suită Burp , și Fortifica.

Scopul principal al testării securității este de a identifica orice vulnerabilități pe care le poate avea aplicația software.

Testarea securității testează aplicația împotriva:

  • Orice atac extern sau încercare de piratare a aplicației cu intenție rău intenționată.
  • Orice lacună din aplicația software ar putea fi exploatată cauzând pierderi de date sau monetare.
  • Orice vulnerabilitate din rețea, servere și stații de lucru care găzduiește aplicația.

Următoarele sunt diferitele tipuri de teste de securitate:

Testarea vulnerabilității: Un program automat este dezvoltat și executat pentru a verifica diferitele vulnerabilități.

Scanare de securitate: Această variantă se învârte în jurul investigării vulnerabilităților rețelei și a sistemului, oferind soluții pentru a reduce riscul asociat.

Test de penetrare: Această variantă de testare a securității imită o încercare de hacking de a capta vulnerabilități și lacune, care altfel ar fi putut obține acces la baza de date sau la datele aplicației.

Audit de securitate: Aceasta implică auditul aplicației și a rețelelor asociate pentru orice deficiențe de securitate.

Evaluare a riscurilor: Această variantă face o analiză pentru a evalua nivelul de risc, într-un caz în care o vulnerabilitate sau o lacună este exploatată în scop intenționat. Un astfel de risc ar putea fi clasificat în scăzut, mediu și ridicat. Pe baza nivelului de risc, echipa de testare recomandă măsuri adecvate pentru a reduce sau preveni riscul.

Hacking etic: Aceasta este realizată de o organizație pe sistemele sale pentru a identifica lacune care ar putea fi exploatate în aplicația sau rețeaua sa. Intenția acestui tip de hacking nu este de a fura sau provoca daune aplicației sau rețelei.

Evaluarea posturii: Aceasta este o evaluare umbrelă care cuprinde scanarea securității, evaluări ale riscurilor și hacking etic.

Injecție SQL: SQL Injection ar putea fi utilizat pentru a obține acces la baza de date a serverului. Testarea se face pentru a se asigura că codul funcționează corect, care execută interogări pe baza de date pe baza următoarelor intrări de la utilizator:

  • Suporturi
  • Apostrofe
  • Virgule
  • Ghilimele

Alte etape în testarea aplicației BFSI

În afară de etapele principale de mai sus, ar putea exista diferite etape implicate, cum ar fi testarea integrării, testarea utilizabilității, testarea acceptării utilizatorilor și testarea performanței.

Să vorbim pe scurt și despre aceste etape:

Testarea integrării

După cum știți, într-o aplicație bancară, ar putea exista mai multe module diferite, cum ar fi transferurile, plățile facturilor, depozitele etc. Astfel, există o mulțime de componente dezvoltate. În testarea integrării, toate componentele și integrate împreună și validate.

Testarea utilizabilității

Testarea utilizabilității

O aplicație bancară servește o mare varietate de clienți. Unii dintre acești clienți ar putea să nu aibă abilitățile și cunoștințele necesare pentru a îndeplini sarcinile bancare prin intermediul aplicației.

Astfel, aplicația bancară ar trebui testată pentru o concepție simplă și eficientă pentru a o face utilizabilă în diferite grupuri de clienți. Cu cât interfața este mai simplă și mai ușor de utilizat, cu atât numărul mai mare de clienți va fi beneficiat de aplicația bancară.

Este vorba despre examinarea nivelului de ușurință pe care îl au utilizatorii de afaceri sau clienții băncii în utilizarea aplicației. Această testare nu este realizată de dezvoltator sau tester, ci este efectuată de utilizatorii de afaceri.

De exemplu, În prezent, toată lumea folosește aplicații mobile. Aplicația bancară ar trebui să fie ușor de utilizat și ușor de înțeles și de utilizat de către utilizatorul final.

Tipuri de teste de utilizare

Testarea comparativă a utilizabilității: Acesta este testarea bazată pe comparație, în cazul în care ușurința de utilizare a unui site web sau a unei aplicații cu altul. Ținta pentru astfel de testări este de a oferi cea mai bună experiență de utilizare.

Testarea explorabilității de utilizare: Scopul acestor teste este de a identifica ce caracteristici ar trebui să aibă noua aplicație sau software pentru a satisface cerințele clienților băncii.

Următoarele sunt avantajele și dezavantajele testării de utilizare

cum se scrie un exemplu de caz de testare

Avantaje:

  • Utilizatorii finali ai aplicației sunt de obicei implicați în testare, prin urmare se obține feedback direct.
  • În loc să petreceți timp pe analize și discuții despre o caracteristică pe care un produs ar trebui să o aibă sau nu, este mai bine să obțineți intrările de la utilizatorul final direct.
  • Putem prinde orice probleme potențiale în prealabil.

Dezavantaje:

  • Deoarece mai mulți utilizatori finali sunt implicați în testare, opiniile lor, dacă nu sunt precise, pot afecta cerința.
  • Feedul de la utilizatorii finali poate fi influențat.

Test de performanta

Anumite perioade de timp, cum ar fi ziua de plată, sfârșitul anului financiar, anotimpurile festive pot aduce schimbări sau creșteri ale traficului obișnuit din aplicație. Prin urmare, ar trebui efectuate teste amănunțite de performanță, astfel încât clienții să nu fie afectați de eșecurile de performanță.

Un exemplu semnificativ din trecut, în care clienții băncii au fost afectați personal din cauza eșecurilor de performanță, este întreruperea IT a Cyber ​​Monday de la NatWest și RBS, în care clienții au avut tranzacții refuzate pe cardurile de debit și credit în magazinele din țară.

Testarea acceptării utilizatorului

Acest lucru se realizează prin implicarea utilizatorilor finali pentru a se asigura că aplicația respectă scenariile din lumea reală și va fi acceptată de utilizatori dacă va fi activată.

În scenariul de astăzi majoritatea proiectelor bancare folosesc : Agile / Scrum, RUP și metodologii de integrare continuă și pachete de instrumente precum VSTS și Rational Tools de la Microsoft.

Așa cum am menționat mai sus despre RUP, RUP reprezintă Rational Unified Process, care este o metodologie iterativă de dezvoltare software introdusă de IBM care cuprinde patru faze în care se desfășoară activități de dezvoltare și testare.

Patru faze sunt
i) Incepere
ii) Colaborare
iii) Construcții și
iv) Tranziție

RUP implică pe scară largă instrumentele IBM Rational.

Exemple de cazuri de testare pentru aplicații bancare

Cazuri de testare pentru filiala nouă

  • Creați o ramură nouă cu date de testare valide și nevalide.
  • Creați o ramură nouă fără date.
  • Creați o nouă sucursală cu datele de sucursală existente.
  • Verificați opțiunile de resetare și anulare.
  • Actualizați detaliile sucursalei cu date de test valide și nevalide.
  • Actualizați detaliile sucursalei cu datele existente de testare a sucursalei.
  • Verificați dacă noua ramură poate fi salvată.
  • Verificați dacă opțiunea de anulare funcționează.
  • Verificați ștergerea sucursalei cu și fără dependențe.
  • Verificați dacă opțiunea de căutare a sucursalelor funcționează.

Cazuri de testare pentru rol nou

  • Creați un rol nou cu date de testare valide și nevalide.
  • Creați un rol nou fără date.
  • Verificați dacă un nou rol poate fi creat cu datele de testare existente.
  • Verificați descrierea rolului și tipurile de roluri.
  • Verificați dacă opțiunea de anulare și resetare funcționează.
  • Verificați procesul de ștergere a rolului cu și fără dependență.
  • Verificați linkurile în pagina cu detalii despre rol.
  • Verificați datele de conectare ale administratorului fără date de testare.
  • Verificați toate linkurile principale pentru rolul de administrator.
  • Verificați dacă administratorul poate schimba parola cu date de testare valide și nevalide.
  • Verificați deconectarea administratorului cu succes.

Testează cazuri pentru clienți și bancher

  • Verificați dacă toate linkurile pentru vizitatori și clienți funcționează corect.
  • Verificați datele de conectare ale clienților cu date de testare valide și nevalide.
  • Verificați datele de conectare ale clienților fără date.
  • Verificați datele de conectare ale bancherului fără date.
  • Verificați datele de conectare ale bancherului cu date de testare valide sau nevalide.
  • Verificați dacă clientul sau bancherul se poate deconecta cu succes.

Testează cazuri pentru utilizatori noi

  • Verificați dacă noul utilizator poate fi creat cu date de testare valide și nevalide.
  • Creați un utilizator nou cu datele de testare a ramurilor existente
  • Verificați dacă opțiunea de anulare și resetare funcționează corect.
  • Actualizați detaliile utilizatorului cu date de test valide și nevalide.
  • Verificați ștergerea noului utilizator.
  • verificați dacă noul utilizator poate fi verificat.
  • Verificați parametrii de intrare obligatorii.
  • Verificați parametrii de intrare opționali.
  • Verificați dacă un utilizator poate fi creat fără parametri opționali.

Testează cazuri pentru crearea unui cont nou

  • Creați un cont nou cu date de utilizator valide și nevalide.
  • Verificați dacă detaliile utilizatorului pot fi actualizate.
  • Verificați dacă un utilizator nou poate fi salvat.
  • Creați un cont nou cu datele utilizatorului existent.
  • Verificați dacă utilizatorul poate depune suma în contul nou creat (și să actualizeze soldul).
  • Verificați dacă utilizatorul poate retrage o sumă din noul cont (după depunere și actualiza soldul).
  • În cazul salariului, verificarea contului numele companiei și alte detalii sunt furnizate de utilizator.
  • Verificați dacă numărul de cont principal este furnizat în cazul unui cont secundar.
  • Verificați detaliile utilizatorului furnizate în cazul contului curent.
  • Verificați dovezile furnizate pentru contul comun în cazul unui cont comun.
  • Verificați dacă puteți menține soldul zero în contul salarial.
  • Verificați dacă este capabil să mențină soldul zero sau soldul minim pentru contul non-salarial.
  • Verificați dacă noul utilizator se poate deconecta cu succes.

Cazuri de testare pentru aplicația de Net Banking

  • Verificați dacă utilizatorul poate deschide site-ul băncii.
  • Verificați dacă toate linkurile de pe site funcționează.
  • Verificați dacă utilizatorul este capabil să creeze un cont nou.
  • Verificați dacă utilizatorul este capabil să se conecteze cu un nume de utilizator și o parolă valide și nevalide.
  • Verificați dacă oricare dintre numele de utilizator sau parola este gol în timpul conectării, utilizatorul nu ar trebui să aibă permisiunea de a se autentifica și este afișat un mesaj de alertă.
  • Verificați dacă utilizatorul are voie să schimbe parola.
  • Dacă este introdus un utilizator sau o parolă invalidă, este afișat mesajul de eroare corespunzător.
  • Utilizatorilor cu o parolă nevalidă nu ar trebui să li se permită să se conecteze.
  • Verificați dacă după încercări repetate de a vă conecta cu o parolă incorectă, utilizatorului trebuie să i se afișeze un mesaj de eroare și să fie blocat.
  • Verificați dacă utilizatorul este capabil să efectueze unele tranzacții de bază.
  • Verificați dacă utilizatorul poate adăuga un beneficiar cu detalii valide și nevalide.
  • Verificați dacă utilizatorul poate șterge beneficiarul.
  • Verificați dacă utilizatorul este capabil să efectueze tranzacții către noul beneficiar adăugat.
  • După tranzacție, verificați dacă conturile utilizatorului și ale beneficiarului sunt actualizate.
  • Verificați dacă utilizatorul poate introduce suma în număr zecimal.
  • Verificați dacă utilizatorul nu poate introduce numere negative în câmpul sumă.
  • Verificați dacă utilizatorul are voie să efectueze tranzacții cu sau fără sold minim.
  • Verificați dacă utilizatorul poate face un RD nou.
  • Verificați dacă mesajul corect este afișat în cazul tranzacției efectuate cu sold insuficient.
  • Verificați dacă utilizatorului i se solicită confirmarea înainte de efectuarea oricărei tranzacții.
  • Verificați dacă primirea confirmării este furnizată la fiecare tranzacție reușită.
  • Verificați dacă utilizatorul poate transfera bani în mai multe conturi.
  • verificați dacă utilizatorul poate anula tranzacția.
  • Verificați dacă detaliile contului reflectă și tranzacțiile financiare efectuate.
  • Verificați dacă funcția de expirare este implementată.
  • verificați dacă, în cazul expirării sesiunii, un utilizator trebuie să se conecteze din nou.
  • verificați dacă timpul de expirare a sesiunii se face în caz de inactivitate.
  • verificați dacă în timpul tranzacției utilizatorul este dus în modul securizat.
  • Verificați dacă utilizatorul se poate deconecta cu succes.
  • Verificați opțiunile de căutare și resetare.

Concluzie

În acest articol, am discutat cât de complexă ar putea fi o aplicație bancară și care sunt fazele tipice implicate în testarea aplicației . În afară de aceasta, am discutat și despre tendințele actuale urmate de industriile IT, inclusiv metodologii și instrumente de dezvoltare software.

Simțiți-vă liber să împărtășiți experiența sau întrebările dvs. cu privire la acest subiect!

Lectură recomandată

^