Bankdomeneapplikasjonstesting: Eksempel på testtilfeller

Bankdomenetesting

Bankdomenetesting er en programvaretestprosess for en bankapplikasjon for funksjonalitet, ytelse og sikkerhet. Hovedformålet med å teste bankapplikasjoner er å sikre at alle aktivitetene og funksjonene til en bankprogramvare kjører problemfritt uten feil, og at den forblir beskyttet.

BFSI-sektoren (Banking, Financial Services and Insurance) er den største forbrukeren av IT-tjenester. Bankapplikasjoner omhandler direkte konfidensielle økonomiske data. Det er obligatorisk at alle aktivitetene som utføres av bankprogramvare kjører problemfritt og uten feil. Bankprogramvare utfører ulike funksjoner som å overføre og sette inn midler, saldoforespørsel, transaksjonshistorikk, uttak og så videre. Testing av bankapplikasjoner sikrer at disse aktivitetene ikke bare utføres godt, men også forblir beskyttet mot hackere.

Bli med på vårt Live Banking-testprosjekt gratis

Hva er domene i testing?

Domene i testing er ingenting annet enn bransjen som programvaretestprosjektet er laget for. Når vi snakker om programvareprosjekter eller utvikling, refereres ofte til dette begrepet. For eksempel forsikringsdomene, bankdomene, detaljdomene, telekomdomene osv.

Vanligvis, mens du utvikler et spesifikt domeneprosjekt, oppsøkes domeneeksperthjelp. Domeneeksperter er mestere i faget, og han kan kanskje innsiden og ut av produktet eller applikasjonen.

Hvorfor er domenekunnskap viktig?

Domenekunnskap er viktig for å teste et hvilket som helst programvareprodukt, og det har sine egne fordeler som

Bankdomenekunnskap – introduksjon

Bankdomenekonsepter er enorme, og i utgangspunktet er det underkarakterisert i to sektorer

Tradisjonell banksektor
Tjenestebasert banksektor

Nedenfor er tabellen over tjenestene disse to undersektorene av bankvirksomhet omfatter

Tradisjonell banksektor	Kjernebank Bedriftsbank Detaljhandel
Tjenestebasert banksektor	Kjerne Samfunnsansvar Detaljhandel Lån Handelsfinans private banking Forbrukerfinansiering Islamsk bankvirksomhet Kundeleveringskanaler/Frontend-levering

Basert på omfanget av prosjektet ditt må du kanskje teste ett eller alle de ovennevnte tjenestetilbudene. Før du begynner å teste, sørg for at du har nok bakgrunn om tjenesten som testes.

Kjennetegn ved en bankapplikasjon

Før du begynner å teste, er det viktig å merke seg standardfunksjonene som forventes av enhver bankapplikasjon. Slik at du kan utstyre testinnsatsen din for å oppnå disse egenskapene.

En standard bankapplikasjon bør oppfylle alle disse egenskapene som nevnt nedenfor.

Den skal støtte tusenvis av samtidige brukerøkter
En bankapplikasjon bør integreres med en rekke andre applikasjoner som handelskontoer, Bill betalingsverktøy, kredittkort osv.
Den skal behandle raske og sikre transaksjoner
Det bør inkludere massivt lagringssystem.
For å feilsøke kundeproblemer, bør den ha høy revisjonsevne
Den skal håndtere komplekse arbeidsflyter
Trenger å støtte brukere på flere plattformer (Mac, Linux, Unix, Windows)
Det skal støtte brukere fra flere steder
Den skal støtte flerspråklige brukere
Det skal støtte brukere på ulike betalingssystemer (VISA, AMEX, MasterCard)
Den skal støtte flere tjenestesektorer (lån, detaljbank osv.)
Idiotsikker katastrofehåndteringsmekanisme

Testfaser i testing av bankapplikasjoner

For testing av bankapplikasjoner inkluderer forskjellige teststadier

Kravanalyse: Det gjøres av forretningsanalytiker; krav til en bestemt bankapplikasjon er samlet og dokumentert
Krav Revse: Kvalitetsanalytikere, forretningsanalytikere og utviklingsledere er involvert i denne oppgaven. Kravsamlingsdokumentet gjennomgås på dette stadiet, og krysssjekkes for å sikre at det ikke påvirker arbeidsflyten
Dokumentasjon for forretningskrav: Forretningskravdokumenter utarbeides av kvalitetsanalytikere der alle gjennomgåtte forretningskrav er dekket
Databasetesting: Det er den viktigste delen av testing av bankapplikasjoner. Denne testingen er gjort for å sikre dataintegritet, datalasting, datamigrering, lagrede prosedyrer og funksjonsvalidering, regeltesting, etc.
Integrasjonstesting: Under Integrasjonstesting alle komponenter som utvikles er integrert og validert
Funksjonell testing: De vanlige programvaretestingsaktivitetene som Testsak forberedelse, testcasegjennomgang og testcaseutførelse gjøres i denne fasen
Sikkerhetstesting: Det sikrer at programvaren ikke har noen sikkerhetsfeil. Under testforberedelsen må QA-teamet inkludere både negative og positive testscenarier for å bryte seg inn i systemet og rapportere det før uautoriserte personer får tilgang til det. For å forhindre hacking, bør banken også implementere et flerlags tilgangsvalidering som et engangspassord. Til Sikkerhetstesting, automatiseringsverktøy som IBM AppScan og HPWebInspect brukes mens for Manuell testing verktøy som Proxy Sniffer, Paros proxy, HTTP watch, etc. brukes
Brukervennlighetstesting: Det sikrer at ulikt dyktige personer skal kunne bruke systemet som vanlig bruker. For eksempel minibank med hørsel og punktskrift for funksjonshemmede
Brukeraksepttesting: Det er det siste stadiet av testing utført av sluttbrukerne for å sikre at applikasjonen samsvarer med det virkelige scenariet.

Eksempel på testtilfelle for nettbankpåloggingsapplikasjon

Sikkerhet er det viktigste for enhver bankapplikasjon. Derfor, under testforberedelsen, bør QA-teamet inkludere både negative og positive testscenarier for å snike seg inn i systemet og rapportere for eventuelle sårbarheter før uautoriserte personer får tilgang til det. Det innebærer ikke bare å skrive negative testtilfeller, men kan også inkludere destruktiv testing.

Følgende er generiske testtilfeller for å sjekke enhver bankapplikasjon

Eksempel på testtilfeller
For Admin	Bekreft Admin-pålogging med gyldige og ugyldige data Bekreft admin pålogging uten data Bekreft alle lenker til administratorhjemmesiden Bekreft administratorendre passord med gyldige og ugyldige data Bekreft at admin endre passord uten data Bekreft administratorendre passord med eksisterende data Bekreft avlogging av admin
For ny filial	Opprett en ny filial med gyldige og ugyldige data Opprett en ny filial uten data Opprett en ny filial med eksisterende filialdata Bekreft tilbakestilling og avbryt alternativet Oppdater filial med gyldige og ugyldige data Oppdater filial uten data Oppdater filial med eksisterende filialdata Bekreft kanselleringsalternativet Bekreft sletting av grener med og uten avhengigheter Bekreft alternativ for grensøk
For ny rolle	Opprett en ny rolle med gyldige og ugyldige data Opprett en ny rolle uten data Bekreft ny rolle med eksisterende data verifisere rollebeskrivelse og rolletyper Bekreft avbryt og tilbakestill alternativet Bekreft sletting av rolle med og uten avhengighet bekrefte koblinger på siden med rolledetaljer
For kunder og besøkende	Bekreft alle besøkende eller kundekoblinger Bekreft kundenes pålogging med gyldige og ugyldige data Bekreft kundenes pålogging uten data Bekreft bankmannens pålogging uten data Bekreft bankmannens pålogging med gyldige eller ugyldige data
For nye brukere	Opprett en ny bruker med gyldige og ugyldige data Opprett en ny bruker uten data Opprett en ny bruker med eksisterende filialdata Bekreft avbryt og tilbakestill alternativet Oppdater brukeren med gyldige og ugyldige data Oppdater bruker med eksisterende data Bekreft kanselleringsalternativet Bekreft sletting av brukeren

Utfordringer med å teste bankdomener og deres avgrensning

Utfordringer som testeren kan møte under testing av bankdomene er

Utfordring	Begrensning
Å få tilgang til produksjonsdata og replikere dem som testdata for testing er utfordrende	Sørg for at testdata oppfyller regulatoriske krav og retningslinjer Oppretthold datakonfidensialitet ved å følge teknikker som datamaskering, syntetiske testdata, testing av systemintegrasjon, etc.
Den største utfordringen med å teste banksystem er under migreringen av systemet fra det gamle systemet til det nye systemet som testing av alle rutiner, prosedyrer og planer. Også hvordan dataene vil bli hentet, lastet opp og overført til det nye systemet etter migrering	Sørg for at datamigreringstesting er fullført Sørg for at regresjonstesttilfeller blir utført på gamle og nye systemer, og at resultatene stemmer overens.
Det kan være tilfeller der krav ikke er godt dokumentert og kan føre til funksjonshull i testplanen Mange ikke-funksjonelle krav er ikke fullt ut dokumentert, og testerne vet ikke om de skal teste det eller ikke	Testeren bør delta i prosjektet rett fra kravanalysefasene og bør aktivt gjennomgå forretningskravene
Det viktigste punktet er å sjekke om nevnte system følger de ønskede retningslinjene og prosedyrene	Testing av samsvar eller regulatoriske retningslinjer må utføres
Omfanget og tidslinjene øker ettersom bankapplikasjoner integreres med andre applikasjoner som internett eller Mobil bank	Sørg for at tidsbudsjettet for integrasjonstesting blir tatt med hvis bankapplikasjonen din har mange eksterne grensesnitt

Sammendrag

Bankdomene er det mest sårbare området for cybertyveri, og sikring av programvaren krever nøyaktig testing. Denne opplæringen gir en klar ide om hva som kreves for bankdomenetesting og hvor viktig det er. Man må forstå at -

Flertallet av bankprogramvare er utviklet på Hovedramme og Unix
Testing bidrar til å redusere mulige feil som kan oppstå under programvareutvikling
Riktig testing og samsvar med bransjestandarder sparer bedrifter fra straffer
God praksis bidrar til å utvikle gode resultater, omdømme og mer forretning for bedrifter
Både manuell og automatisert testing har respektive fordeler og brukervennlighet

Bli med i vår Live Banking Domain Testing Project