Prosjekt for testing av bankdomeneapplikasjoner
Thomas Hamilton
⚡ Smart oppsummering
Testing av bankdomeneapplikasjoner validerer funksjonalitet, ytelse og sikkerhet for finansiell programvare som håndterer sensitive transaksjoner. Denne veiledningen forklarer domenekunnskap, egenskaper ved bankapplikasjoner, testfaser, eksempler på testtilfeller og viktige strategier for å redusere risikoer som er unike for BFSI-sektoren.
Bankdomenetesting
Bankdomenetesting er programvaretestingsprosessen for en bankapplikasjon for funksjonalitet, ytelse og sikkerhet. Hovedformålet med å teste en bankapplikasjon er å sikre at alle aktiviteter og funksjoner i bankprogramvaren kjører problemfritt uten feil, og at programvaren forblir beskyttet.
BFSI-sektoren (bank-, finans- og forsikringssektoren) er den største forbrukeren av IT-tjenester. Bankapplikasjoner håndterer direkte konfidensielle økonomiske data, så det er obligatorisk at all aktivitet som utføres av bankprogramvare kjører pålitelig og feilfritt. Bankprogramvare utfører funksjoner som overføring og innskudd av midler, saldoforespørsler, transaksjonshistorikk og uttak. Testing av en bankapplikasjon sikrer at disse aktivitetene ikke bare utføres riktig, men også forblir beskyttet mot hackere.
Bli med på vårt Live Banking-testprosjekt gratis
Hva er domene i testing?
Domene i testing refererer til bransjen som programvaretestprosjektet er laget for. Begrepet brukes ofte når man diskuterer programvareprosjekter og -utvikling. Eksempler inkluderer forsikringsdomenet, bankdomenet, detaljhandelsdomenet og telekomdomenet.
Mens utviklingenping I ethvert domenespesifikt prosjekt søkes det vanligvis hjelp fra en domeneekspert. Domeneeksperter er mestre i faget og kjenner bruken ut og inn.
Hvorfor er domenekunnskap viktig?
Domenekunnskap er viktig for testing av ethvert programvareprodukt fordi det direkte forbedrer testdekning, feildeteksjon og interessentenes tillit. En tester som forstår bankarbeidsflyter kan oppdage kanttilfeller som en tester utenfor domenet overser fullstendig.
Bankdomenekunnskap – introduksjon
Bankdomenekonsepter er omfattende og er grovt sett underkarakterisert i to sektorer:
- Tradisjonell banksektor
- Tjenestebasert banksektor
Tabellen nedenfor viser tjenestene som disse to undersektorene omfatter.
| Sektor | Tjenester inkludert |
|---|---|
| Tradisjonell banksektor | Kjernebankvirksomhet, bedriftsbankvirksomhet, privatbankvirksomhet |
| Tjenestebasert banksektor | Kjerne, Bedrift, Detaljhandel, Lån, Handelsfinansiering, Privatbank, Forbrukerfinansiering, Islamsk bankvirksomhet, Kundeleveringskanaler / Front-end-levering |
Avhengig av omfanget av prosjektet ditt, kan det hende du må teste ett eller alle tjenestetilbudene ovenfor. Før du begynner testingen, sørg for at du har nok bakgrunnsinformasjon 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 tilpasse testarbeidet ditt for å oppnå disse egenskapene. En standard bankapplikasjon bør oppfylle følgende forventninger:
- Støtt tusenvis av samtidige brukerøkter.
- Integrer med mange andre applikasjoner, som handelskontoer, regningbetalingsverktøy og kredittkort.
- Behandle transaksjoner raskt og sikkert.
- Inkluder et massivt lagringssystem.
- Tilby høy revisjonskapasitet for å feilsøke kundeproblemer.
- Håndter komplekse forretningsarbeidsflyter.
- Støtte brukere på flere plattformer (Mac, Linux, Unix, Windows).
- Støtt brukere fra flere steder.
- Støtt flerspråklige brukere.
- Brukerstøtte på ulike betalingssystemer (VISA, AMEX, MasterCard).
- Støtte flere tjenestesektorer (lån, privatbank, osv.).
- Sørg for en idiotsikker mekanisme for katastrofehåndtering.
Typer bankapplikasjoner som skal testes
Før kartetping I testfasene er det nyttig å vite hvilke bankapplikasjoner som vanligvis er innenfor rammen av:
- Kjernebanksystemet (CBS): sentral motor for innskudd, lån og kontoer.
- Nettbank: kundevendt nettportal for overføringer og regningsbetalinger.
- Mobilbank: iOS og Android apper med biometri og varsler.
- Minibank- og kioskprogramvare: innebygd programvare på minibanker.
- Betalingsportaler: kort-, UPI- og lommeboktransaksjonsbehandlere.
- Låne- og treasury-moduler: apper for backoffice-kreditt og valutaveksling.
Testfaser i testing av bankapplikasjoner
Når applikasjonene som er omfattet er kjent, går testingen vanligvis gjennom følgende faser.
- Kravanalyse: Utføres av forretningsanalytikeren, som samler inn og dokumenterer kravene til en spesifikk bankapplikasjon.
- Krav Revse: Kvalitetsanalytikere, forretningsanalytikere og utviklingsledere gjennomgår kravdokumentet og kryssjekker det for å sikre at det ikke bryter med noen eksisterende arbeidsflyt.
- Dokumentasjon for forretningskrav: Kvalitetsanalytikere utarbeider forretningskravdokumenter som dekker alle gjennomgåtte krav.
- Databasetesting: Den viktigste delen av testing av bankapplikasjoner. Den verifiserer dataintegritet, datalasting, datamigrering, lagrede prosedyrer, funksjonsvalidering og forretningsregler.
- Integrasjonstesting: Under Integrasjonstesting, alle utviklede komponenter er integrert og validert sammen.
- Funksjonell testing: Standard testaktiviteter som f.eks. Testsak forberedelse, gjennomgang av testcase og utførelse utføres i denne fasen.
- Sikkerhetstesting: Sørger for at programvaren er fri for sikkerhetsfeil. QA-teamet bør inkludere både negative og positive scenarier for å forsøke å bryte seg inn i systemet og rapportere sårbarheter før uautoriserte parter finner dem. Banker bør også håndheve flerlags tilgangsvalidering, for eksempel engangspassord. Automatiseringsverktøy som vanligvis brukes til Sikkerhetstesting inkludere IBM AppScan og HP WebInspect, mens Manuell testing er ofte avhengig av Proxy Sniffer, Paros Proxy og HTTP Watch.
- Brukervennlighetstesting: Sørger for at brukere med funksjonsnedsettelser kan bruke systemet like enkelt som alle andre brukere – for eksempel minibanker utstyrt med lydveiledning og blindeskrifttastatur for tilgjengelighet.
- Brukeraksepttesting: Det siste trinnet, utført av sluttbrukere, for å bekrefte at applikasjonen oppfører seg riktig i virkelige scenarier.
Eksempel på testtilfelle for nettbankpåloggingsapplikasjon
Sikkerhet er avgjørende for enhver bankapplikasjon. Under testforberedelsene bør QA-teamet inkludere både negative og positive scenarier for å undersøke systemet og rapportere sårbarheter før uautoriserte personer finner dem. Dette betyr å skrive ikke bare negative testtilfeller, men også destruktive tester.
Tabellen nedenfor viser generiske testtilfeller for en bankapplikasjon.
| Område | Eksempel på testtilfeller |
|---|---|
| admin | Bekreft administratorinnlogging med gyldige og ugyldige data; administratorinnlogging uten data; alle administrator-hjemmelenker; administrator endrer passord med gyldige, ugyldige og eksisterende data; administratorlogg ut. |
| Ny gren | Opprett en ny gren med gyldige, ugyldige og eksisterende data; opprett uten data; tilbakestill og avbryt; oppdater gren med gyldige, ugyldige og eksisterende data; avbryt; slett gren med og uten avhengigheter; grensøk. |
| Ny rolle | Opprett en ny rolle med gyldige, ugyldige og eksisterende data; opprett uten data; bekreft rollebeskrivelse og -typer; avbryt og tilbakestill; slett rolle med og uten avhengigheter; bekreft lenker på rolledetaljsiden. |
| Kunde og besøkende | Bekreft alle lenker til besøkende og kunder; kundeinnlogging med gyldige, ugyldige eller ingen data; bankpålogging med gyldige, ugyldige eller ingen data. |
| Nye brukere | Opprett ny bruker med gyldige, ugyldige og eksisterende grendata; opprett uten data; avbryt og tilbakestill; oppdater bruker med gyldige, ugyldige og eksisterende data; avbryt; slett bruker. |
Utfordringer ved testing av bankvirksomheten og hvordan de kan reduseres
Selv med sterke testfaser og maler, møter testere flere tilbakevendende utfordringer i bankprosjekter. Tiltakene nedenfor har vist seg effektive i reelle engasjementer.
| Utfordring | Begrensning |
|---|---|
| Det er vanskelig å få tilgang til produksjonsdata og replikere dem som testdata. | Sørg for at testdata oppfyller regelverkskrav og opprettholder konfidensialitet gjennom datamaskering, syntetiske testdata og systemintegrasjonstesting. |
| Å migrere fra et gammelt banksystem til et nytt – inkludert rutiner, prosedyrer og dataopplastinger – er den største utfordringen. | Fullfør datamigreringstesting og kjør regresjonstester på både gamle og nye systemer, og sammenlign resultatene til de samsvarer. |
| Krav kan være dårlig dokumentert, noe som etterlater funksjonelle hull. Ikke-funksjonelle krav er ofte udokumenterte, slik at testere ikke vet om de skal teste dem. | Testere bør delta fra kravanalysefasen og aktivt gjennomgå forretningskrav. |
| Verifisere at systemet følger ønskede retningslinjer og prosedyrer. | Utfør testing av samsvars- og regelverkspolicyer. |
| Omfang og tidslinjer utvides etter hvert som bankapplikasjoner integreres med internett og Mobil bankvirksomhet. | Sett av tilstrekkelig tid i planen til integrasjonstesting når bankapplikasjonen har mange eksterne grensesnitt. |
