Banking Domain Application Testing: Eksempel på testtilfeller

Banking Domain Testing

Banking Domain Testing er en programvaretestprosess av en banksøknad for funksjonalitet, ytelse og sikkerhet. Hovedformålet med å teste banksøknader er å sikre at alle aktiviteter og funksjoner i en bankprogramvare kjører problemfritt uten feil, og den forblir beskyttet.

BFSI (bank, finans og forsikring) er den største forbrukeren av IT-tjenester. Bankapplikasjoner håndterer konfidensielle økonomiske data direkte. Det er obligatorisk at alle aktiviteter som utføres av bankprogramvare kjører problemfritt og uten feil. Bankprogramvare utfører forskjellige funksjoner som overføring og innskudd av fond, saldohenvendelse, transaksjonshistorikk, uttak og så videre. Testing av banksøknader sikrer at disse aktivitetene ikke bare utføres godt, men også forblir beskyttet mot hackere.

I denne opplæringen vil vi lære

Hva er Domain in Testing?
Hvorfor domenekunnskap er viktig?
Introduksjon til Banking Domain
Kjennetegn ved en banksøknad
Stadier for testing av banksøknader
Eksempel på testsak for påloggingsapplikasjon for nettbank
Utfordringer i å teste banksektoren og deres begrensning

Bli med på vårt Live Banking Testing Project gratis

Hva er Domain in Testing?

Domain in Testing er ikke annet enn bransjen som programvaretestprosjektet er opprettet for. Når vi snakker om programvareprosjekter eller utvikling, blir dette begrepet ofte referert til. For eksempel forsikringsdomene, bankt domene, detaljhandel domene, telekom domene, etc.

Mens du utvikler et spesifikt domeneprosjekt, blir det vanligvis oppsøkt hjelp fra domenene. Domeneekspert er mester i emnet, og han vet kanskje innsiden av produktet eller applikasjonen.

Hvorfor domenekunnskap er viktig?

Domenekunnskap er viktig for å teste ethvert programvareprodukt, og det har sine egne fordeler som

Banking Domain Knowledge - 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 i banken omfatter

Tradisjonell banksektor	Kjernebank Bedriftsbank Detaljbank
Tjenestebasert banksektor	Kjerne Bedrift Detaljhandel Låne Handelsfinans Privatbank Forbrukerfinansiering Islamsk bankvirksomhet Kundeleveringskanaler / Frontend levering

Basert på omfanget av prosjektet, kan det hende du må teste ett eller alle ovennevnte tjenestetilbud. Før du begynner å teste, må du sørge for at du har nok bakgrunn om tjenesten som testes.

Kjennetegn ved en banksøknad

Før du begynner å teste, er det viktig å være oppmerksom på standardfunksjonene som forventes av alle bankapplikasjoner. Slik at du kan innrette testinnsatsen din for å oppnå disse egenskapene.

En standard banksøknad skal oppfylle alle disse egenskapene som nevnt nedenfor.

Den skal støtte tusenvis av samtidige brukersessioner
En banksøknad skal integreres med andre mange applikasjoner som handelskontoer, Bill-betalingsverktøy, kredittkort, etc.
Den skal behandle raske og sikre transaksjoner
Det bør inneholde massivt lagringssystem.
For å feilsøke kundeproblemer, bør den ha høy revisjonsevne
Den skal håndtere komplekse forretningsflyter
Trenger å støtte brukere på flere plattformer (Mac, Linux, Unix, Windows)
Den skal støtte brukere fra flere steder
Den skal støtte flerspråklige brukere
Den skal støtte brukere på forskjellige betalingssystemer (VISA, AMEX, MasterCard)
Den skal støtte flere tjenestesektorer (lån, detaljbank osv.)
Foolsikker katastrofehåndteringsmekanisme

Testfaser i testing av banksøknader

For testing av bankapplikasjoner inkluderer forskjellige stadier av testing

Kravsanalyse: Det gjøres av forretningsanalytiker; krav til en bestemt banksøknad blir samlet og dokumentert
Kravgjennomgang: Kvalitetsanalytikere, forretningsanalytikere og utviklingsledere er involvert i denne oppgaven. Kravsamlingsdokumentet blir gjennomgått på dette stadiet, og kryssjekket for å sikre at det ikke påvirker arbeidsflyten
Dokumentasjon for forretningskrav: Dokumenter om forretningskrav utarbeides av kvalitetsanalytikere der alle gjennomgåtte forretningskrav er dekket
Databasetesting: Det er den viktigste delen av banksøknadstesting. Denne testingen er gjort for å sikre dataintegritet, datainnlasting, datamigrering, lagrede prosedyrer og funksjonsvalidering, testing av regler, etc.
Integrasjonstesting: Under integrasjonstesting er alle komponenter som er utviklet integrert og validert
Funksjonell testing: De vanlige programvaretestaktivitetene som forberedelse av testsak, gjennomgang av testsak og gjennomføring av testsak 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 noen uvedkommende får tilgang til det. For å forhindre hacking, bør banken også implementere et flerlags tilgangsvalidering som et engangspassord. For sikkerhetstesting brukes automatiseringsverktøy som IBM AppScan og HPWebInspect, mens manuelle testverktøy som Proxy Sniffer, Paros proxy, HTTP watch osv. Brukes
Testing av brukervennlighet: Det sikrer at forskjellige mennesker som er i stand til å kunne bruke systemet som vanlig bruker. For eksempel minibank med hørsels- og blindeskrift for funksjonshemmede
Testing av brukeraksept: Det er den siste fasen av testing utført av sluttbrukerne for å sikre at applikasjonen er i samsvar med den virkelige verden.

Eksempel på testsak for påloggingsapplikasjon for nettbank

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

Følgende er generiske testtilfeller for å sjekke bankapplikasjoner

Eksempel på testtilfeller
For administrator	Bekreft administratorinnlogging med gyldige og ugyldige data Bekreft administratorinnlogging uten data Bekreft alle admin-hjemmekoblinger Bekreft administratorendringspassord med gyldige og ugyldige data Bekreft administratorendringspassord uten data Bekreft administratorendringspassord med eksisterende data Bekreft administratoravlogging
For ny gren	Opprett en ny gren med gyldige og ugyldige data Opprett en ny gren uten data Opprett en ny gren med eksisterende grendata Bekreft tilbakestill og avbryt alternativet Oppdater gren med gyldige og ugyldige data Oppdater gren uten data Oppdater gren med eksisterende grendata Bekreft avbrytingsalternativet Bekreft sletting av grenen med og uten avhengigheter Bekreft gransøkalternativet
For ny rolle	Opprett en ny rolle med gyldige og ugyldige data Lag en ny rolle uten data Bekreft ny rolle med eksisterende data verifisere rollebeskrivelse og rolletyper Bekreft alternativet avbryt og tilbakestill Bekreft sletting av roller med og uten avhengighet bekrefte lenker på siden med rolleinformasjon
For kunder og besøkende	Bekreft alle lenker til besøkende eller kunder Bekreft innlogging av kunder med gyldige og ugyldige data Bekreft pålogging av kunder uten data Bekreft bankmanns pålogging uten data Bekreft bankmanns 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 grendata Bekreft alternativet avbryt og tilbakestill Oppdater brukeren med gyldige og ugyldige data Oppdater brukeren med eksisterende data Bekreft avbrytingsalternativet Bekreft sletting av brukeren

Utfordringer i å teste Banking-domene og deres begrensning

Utfordringer som tester kan møte når de tester bankdomene

Utfordring	Skadebegrensning
Å få tilgang til produksjonsdata og replikere dem som testdata for testing er utfordrende	Sørg for at testdata oppfyller forskrifter og retningslinjer for samsvar Oppretthold datakonfidensialiteten ved å følge teknikker som datamaskering, syntetiske testdata, testing av systemintegrasjon, etc.
Den største utfordringen med å teste banksystemet er under overføringen av systemet fra det gamle systemet til det nye systemet, som testing av alle rutiner, prosedyrer og planer. Også hvordan dataene blir hentet, lastet opp og overført til det nye systemet etter overføring	Sørg for at datamigreringstesting er fullført Sørg for at regresjonstest tilfeller blir utført på gamle og nye systemer, og resultatene stemmer overens.
Det kan være tilfeller der kravene ikke er dokumentert godt og kan føre til funksjonelle hull i testplanen Mange ikke-funksjonelle krav er ikke fullstendig dokumentert, og testere vet ikke om de skal teste det eller ikke	Testen skal delta i prosjektet rett fra faser om kravanalyse og bør aktivt gjennomgå forretningskravene
Det viktigste poenget er å sjekke om nevnte system følger de ønskede retningslinjene og prosedyrene	Testing av samsvar eller regelverk må gjøres
Omfanget og tidslinjene øker ettersom banksøknader er integrert med andre applikasjoner som internett eller mobilbank	Sørg for at tidsbudsjett for integrasjonstesting blir regnskapsført hvis banksøknaden din har mange eksterne grensesnitt

Sammendrag

Bankdomene er det mest sårbare området for cyber-tyveri, og å beskytte programvaren krever presis testing. Denne opplæringen gir en klar ide om hva som skal til for banktest og hvordan viktig det er. Man må forstå det -

Flertallet av bankprogramvare er utviklet på Mainframe og Unix
Testing bidrar til å redusere mulige feil som oppstår under programvareutvikling
Riktig testing og overholdelse av bransjestandarder, redder selskaper 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 på vårt Live Banking Domain Testing Project