Menu

Hoe bankdomeinapplicaties te testen: een complete BFSI-testgids

how test banking domain applications

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Een complete gids voor het testen van banktoepassingen: BFSI-testproces (bankieren, financiële diensten en verzekeringen) en tips

Banktoepassingen zijn een van de meest complexe toepassingen in de huidige softwareontwikkelings- en testindustrie.

Wat maakt banktoepassingen zo complex? Welke aanpak moet worden gevolgd om de complexe workflows van banktoepassingen te testen?

In dit artikel zullen we verschillende fasen en technieken belichten die betrokken zijn bij het testen van banktoepassingen.

Bankapplicaties testen

Wat je leert:

Hoe bankapplicaties te testen?

Verschillende functies die worden uitgevoerd door bankapplicaties zijn:

Functies-van-banken

Laten we eerst de kenmerken van een bankapplicatie begrijpen:

  • Meerlaagse functionaliteit om duizenden gelijktijdige gebruikerssessies te ondersteunen
  • Grootschalige integratie: doorgaans kan een banktoepassing worden geïntegreerd met tal van andere toepassingen, zoals het hulpprogramma Bill Pay en handelsaccounts
  • Complexe zakelijke workflows
  • Real-time en batchverwerking
  • Het hoge aantal transacties per seconde
  • Veilige transacties
  • Robuuste rapportagesectie om dagelijkse transacties bij te houden
  • Sterke controle om problemen van klanten op te lossen
  • Enorm opslagsysteem
  • Beheer van rampen / herstel.

De hierboven genoemde tien punten zijn de belangrijkste kenmerken van een banktoepassing.

Banktoepassingen hebben meerdere niveaus die betrokken zijn bij het uitvoeren van een bewerking.

Bijvoorbeeld , naar Bankapplicatie kan hebben:

  • Webserver voor interactie met eindgebruikers via browser
  • Middle Tier om de invoer en uitvoer voor de webserver te valideren
  • DataBase om gegevens en procedures op te slaan
  • Transactieprocessor die een mainframe met grote capaciteit of een ander legacy-systeem zou kunnen zijn om biljoenen transacties per seconde uit te voeren.

Als we het hebben over het testen van bankapplicaties, is een End-to-end testmethodologie met meerdere softwaretesttechnieken om te zorgen voor:

  • Totale dekking van alle bankworkflows en zakelijke vereisten
  • Het functionele aspect van de applicatie
  • Het beveiligingsaspect van de applicatie
  • Data-integriteit
  • Gelijktijdigheid
  • Gebruikerservaring

Wat maakt banktoepassingen zo complex?

  • Banksoftware behandelt voornamelijk vertrouwelijke financiële gegevens, dus de prestaties van software moeten foutloos en veilig zijn.
  • Ontwikkelaars geven de voorkeur aan een gecompliceerd ontwerp om deze applicaties te ontwikkelen om ervoor te zorgen dat de applicatie op een gewenste veilige manier werkt.
  • Bankieren is een constant veranderende wereld. Bankieren wordt tegenwoordig via verschillende kanalen aan de klant ter beschikking gesteld, zoals fysieke filialen, geldautomaten, online bankieren en klantenservice.
  • Met de komst van technologie hebben veel portefeuilles de markten overspoeld die verbinding maken met de banksystemen voor financiële transacties.
  • Het bankwezen zal naar verwachting ook 24 x 7 draaien met hoge prestaties. Software-upgrades, instant fixes, enz. Mogen geen invloed hebben op deze beschikbaarheid.
  • De bankwereld wordt ook sterk beïnvloed door de voortdurende veranderingen die de overheid doorvoert in de vorm van bankregelgeving. Eventuele wijzigingen in de belastingstructuur hebben ook gevolgen voor het bankwezen.
  • Het banksysteem moet ook up-to-date zijn wat betreft nieuwe technologieën. Data-analyse zoals Big Data Processing en instincten uit big data halen met behulp van Data Science is een groeiende populariteit in de bankwereld.

Bovengenoemde punten maken het banksysteem complex voor ontwikkelaars om er een softwareapplicatie omheen te maken.

Belang van het testen van bankapplicaties

  • Het testen van de Banking-applicatie zorgt ervoor dat alle activiteiten niet alleen goed worden uitgevoerd, maar ook beschermd en beveiligd blijven.
  • Banksoftware is gecompliceerd met duizenden afhankelijkheden, het testproces vereist meer tijd, middelen en continue monitoring.
  • Aangezien het hier om financiën gaat, moeten de richtlijnen strikt worden opgevolgd. Zowel testers als ontwikkelaars moeten een goede domeinkennis hebben.
  • Het belangrijkste is dat ervoor moet worden gezorgd dat de wet- en regelgeving correct wordt gehandhaafd bij financiële transacties. Dit kan alleen worden gegarandeerd door te testen.
  • Het is ook belangrijk om ervoor te zorgen dat de applicatie en de infrastructuur waarop de applicatie is geïmplementeerd de belasting aankunnen, vooral tijdens piekuren, zonder enige onderbreking te veroorzaken. Dit kan worden gegarandeerd door prestatietests uit te voeren.
  • In de digitale wereld van vandaag is beveiliging het enige dat iedereen zorgen baart. De bankapplicaties en de financiële transacties die erin worden uitgevoerd, moeten worden beveiligd tegen elke poging tot inbraak. Dit kan worden gegarandeerd door beveiligingstests uit te voeren. Beveiligingstests helpen bij het afdwingen van industrienormen om financiële transacties te beveiligen.
  • Het is ook belangrijk om ervoor te zorgen dat verschillende modules van een bankapplicatie goed worden geïntegreerd en het doel van de klant bereiken. System Integration Testing helpt bij het bereiken van deze taak.

Workflow voor het testen van bankapps

Typische fasen van het testen van bankapplicaties worden getoond in de onderstaande workflow. We zullen elke fase afzonderlijk bespreken.

Dit is een watervalmodel om een ​​applicatie te testen.

Bankapplicaties testen

# 1) Verzamelen van vereisten

Vereiste Verzamelfase omvat de documentatie van vereisten als functionele specificaties of als use cases. De vereisten worden verzameld volgens de behoeften van de klant en gedocumenteerd door bankexperts of bedrijfsanalist.

Verzamelen van vereisten

Deskundigen zijn betrokken bij het schrijven van vereisten over meer dan één onderwerp, aangezien het bankwezen zelf meerdere subdomeinen heeft en één volwaardige banktoepassing de integratie van al deze domeinen zal zijn.

Bijvoorbeeld, Een banktoepassing kan afzonderlijke modules hebben voor overschrijvingen, creditcards, rapporten, leningsrekeningen, factuurbetalingen, handel enz.

# 2) Beoordeling van vereisten

Het resultaat van Requirement Gathering wordt beoordeeld door alle belanghebbenden, zoals QA Engineers, Development Leaders en Peer Business Analysts.

Vereiste beoordeling

Ze controleren of de bestaande zakelijke workflow en nieuwe workflows niet worden geschonden. Alle vereisten zijn geverifieerd en gevalideerd. Opvolgacties en revisies van vereiste documenten worden op dezelfde basis uitgevoerd.

# 3) Voorbereidingen voor bedrijfsscenario's

In deze fase leiden QA Engineers bedrijfsscenario's af van de vereiste documenten (functiespecificaties of use cases); Bedrijfsscenario's worden zo afgeleid dat aan alle bedrijfsvereisten wordt voldaan. Bedrijfsscenario's zijn scenario's op hoog niveau zonder gedetailleerde stappen.

Verder worden deze bedrijfsscenario's beoordeeld door bedrijfsanalisten om ervoor te zorgen dat aan alle bedrijfsvereisten wordt voldaan. Het is gemakkelijker voor BA's om scenario's op hoog niveau te beoordelen in plaats van gedetailleerde testcases op laag niveau te bekijken.

Bijvoorbeeld kan een klant die een vaste storting opent op de digitale bankinterface een zakelijk scenario zijn. Evenzo kunnen we verschillende bedrijfsscenario's hebben met betrekking tot het maken van een netto bankrekening, online stortingen, online overschrijvingen, enz.

# 4) Functioneel testen

In deze fase worden functionele testen uitgevoerd en worden de gebruikelijke softwaretestactiviteiten uitgevoerd, zoals:

Voorbereiding van de testcase: In deze fase worden testcases afgeleid van bedrijfsscenario's, één bedrijfsscenario leidt tot meerdere positieve testcases en negatieve testcases. Over het algemeen zijn de tools die in deze fase worden gebruikt Microsoft Excel, Test Director of Quality Center.

Testcaseoverzicht: Beoordelingen door collega-QA-ingenieurs

Testgeval Uitvoering: De uitvoering van testcases kan handmatig of automatisch zijn met tools zoals QC, QTP, enz.

Het functioneel testen van een bankapplicatie verschilt nogal van het testen van gewone software. Aangezien deze applicaties werken met het geld en gevoelige financiële gegevens van de klant, moeten ze grondig worden getest. Er mag geen belangrijk bedrijfsscenario worden afgedekt.

De QA-resource die de applicatie test, moet ook de basiskennis van het bankdomein hebben.

# 5) Database testen

Bankapplicatie omvat een complexe transactie die zowel op UI-niveau als op databaseniveau wordt uitgevoerd. Daarom is databasetesten net zo belangrijk als functioneel testen. De database is gecompliceerd en een volledig aparte laag in de applicatie en daarom wordt het testen uitgevoerd door databasespecialisten. Het gebruikt technieken als:

  • Gegevens laden
  • Database-migratie
  • Testen van DB-schema's en datatypes
  • Regels testen
  • Opgeslagen procedures en functies testen
  • Triggers testen
  • Data-integriteit

Het belangrijkste doel van databasetests is ervoor te zorgen dat:

  • De applicatie kan gegevens uit de database opslaan en ophalen zonder verlies van gegevens.
  • Voltooide transacties moeten worden vastgelegd en afgebroken transacties worden teruggedraaid om te voorkomen dat de opgeslagen gegevens niet overeenkomen.
  • Alleen geautoriseerde applicaties en gebruikers hebben toegang tot de database en de onderliggende tabellen.

Er zijn in de eerste plaats drie manieren van databasetesten:

  • Structurele testen
  • Functioneel testen
  • Niet-functionele testen

Structurele testen

Het omvat het testen van de database-objecten zoals databases, schema's, tabellen, views, triggers, toegangscontroles, enz. Ervoor zorgen dat datatypes in tabellen synchroon lopen met de corresponderende variabelen in de applicatie. Valideren van gegevens en referentiële integriteit in de tabellen.

Bijvoorbeeld, Een bedragveld in de toepassing moet het gegevenstype decimaal / zwevend in de tabel hebben.

- Om aan de normen te voldoen, moeten gebruikers toegangscontrole krijgen via views.

Functioneel testen

Het omvat het testen van de databases die voldoen aan de gebruikersvereisten. Er zijn twee manieren om dit te bereiken: Black box-testen en White box-testen.

Bijvoorbeeld, Wanneer we een online geldoverboeking doen, moet de afzenderrekening worden gedebiteerd en de ontvangersrekening moet exact hetzelfde bedrag worden gecrediteerd. Als de transactie mislukt, moeten hele transacties worden teruggedraaid en mag de afzenderrekening niet worden gedebiteerd of gecrediteerd.

Niet-functionele testen

Het omvat load & stresstests en prestatieoptimalisatie. Load testing helpt bij het identificeren van het grootste aantal transacties dat gelijktijdig kan worden uitgevoerd zonder de databaseprestaties te beïnvloeden.

Bijvoorbeeld, Op basis van de input van load- en stresstests kunnen bankapplicaties besluiten om tijdens piekuren meer resources aan hun applicatie toe te voegen en de resources buiten kantooruren te verminderen. Dit helpt de bank om optimaal gebruik te maken van middelen en geld te besparen.

# 6) Beveiligingstests

Beveiligingstests zijn meestal de laatste fase in de testcyclus. Een eerste vereiste om met beveiligingstests te beginnen, is de voltooiing van functionele en niet-functionele tests. Beveiligingstests zijn een van de belangrijkste fasen in de volledige applicatietestcyclus, aangezien deze fase ervoor zorgt dat de applicatie voldoet aan de federale en industriële normen.

Vanwege de aard van de gegevens die ze bevatten, zijn bank-apps erg gevoelig en vormen ze een belangrijk doelwit voor hackers en frauduleuze activiteiten. Beveiligingstests zorgen ervoor dat de applicatie niet zo'n webkwetsbaarheid heeft die gevoelige gegevens aan een indringer of aanvaller kan blootstellen. Het zorgt er ook voor dat de applicatie voldoet aan standaarden zoals OWASP.

In deze fase is de belangrijkste taak de volledige toepassingsscan die wordt uitgevoerd met behulp van tools zoals IBM AppScan of HP WebInspect (dit zijn de meest populaire tools).

Zodra de scan is voltooid, wordt het scanrapport gepubliceerd. Over dit rapport worden valse positieven weggefilterd en de rest van de kwetsbaarheden worden gerapporteerd aan het ontwikkelingsteam, zodat ze de problemen beginnen op te lossen, afhankelijk van de ernst van elk probleem.

Bij deze stap wordt ook penetratietest uitgevoerd om de voortplanting van fouten aan het licht te brengen. Er moeten rigoureuze beveiligingstests worden uitgevoerd op platforms, netwerken en besturingssystemen.

Een andere Handmatige tools voor beveiligingstests gebruikt zijn Paros-proxy ​ Http Kijk ​ Burp Suite , en Versterken.

Het belangrijkste doel van beveiligingstests is om eventuele kwetsbaarheden van de softwareapplicatie op te sporen.

De beveiligingstest test de applicatie op:

  • Elke externe aanval of poging om de applicatie te hacken met kwaadaardige bedoelingen.
  • Elke maas in de softwaretoepassing kan worden misbruikt en gegevens- of geldverlies veroorzaken.
  • Elke kwetsbaarheid in het netwerk, servers en werkstations waarop de applicatie wordt gehost.

Hieronder volgen de verschillende soorten beveiligingstests:

Kwetsbaarheidstesten: Er wordt een geautomatiseerd programma ontwikkeld en uitgevoerd om te controleren op verschillende kwetsbaarheden.

Beveiligingsscannen: Deze variant draait om het onderzoeken van netwerk- en systeemkwetsbaarheden, oplossingen bieden om het bijbehorende risico te verkleinen.

Penetratietesten: Deze variant van beveiligingstests imiteert een hackpoging om kwetsbaarheden en mazen op te sporen die anders toegang hadden kunnen krijgen tot de database of de applicatiedata.

Beveiligingsaudits: Het omvat het controleren van de applicatie en de bijbehorende netwerken op eventuele beveiligingslekken.

Risicobeoordeling: Deze variant voert een analyse uit om het risiconiveau te beoordelen in het geval dat een kwetsbaarheid of maas in de wet wordt misbruikt voor kwaadwillende bedoelingen. Een dergelijk risico kan worden onderverdeeld in laag, gemiddeld en hoog. Op basis van het risiconiveau worden gepaste maatregelen geadviseerd door het testteam om het risico te verminderen of af te wenden.

Ethisch hacken: Dit wordt uitgevoerd door een organisatie op haar systemen om mazen in de wet te identificeren die kunnen worden misbruikt in haar applicatie of netwerk. De bedoeling van dit soort hacken is niet om de applicatie of het netwerk te stelen of schade toe te brengen.

Houdingsbeoordeling: Dit is een overkoepelende beoordeling die bestaat uit beveiligingsscans, risicobeoordelingen en ethisch hacken.

SQL injectie: SQL Injection kan worden gebruikt om toegang te krijgen tot de serverdatabase. De tests worden uitgevoerd om ervoor te zorgen dat de code correct werkt, die query's op de database uitvoert op basis van de volgende invoer van de gebruiker:

  • Beugels
  • Apostrofen
  • Komma's
  • Aanhalingstekens

Andere fasen in het testen van de BFSI-app

Afgezien van de bovenstaande hoofdfasen, kunnen er verschillende fasen zijn, zoals integratietests, bruikbaarheidstests, gebruikersacceptatietests en prestatietests.

Laten we het ook kort hebben over deze fasen:

Integratietesten

Zoals u weet, kunnen er in een banktoepassing verschillende modules zijn, zoals overschrijvingen, betalingen van rekeningen, deposito's, enz. En dus zijn er veel componenten ontwikkeld. Bij integratietesten worden alle componenten samen geïntegreerd en gevalideerd.

Bruikbaarheidstesten

Bruikbaarheidstesten

Een bankapplicatie bedient een grote verscheidenheid aan klanten. Sommige van deze klanten missen mogelijk de vaardigheden en het bewustzijn die nodig zijn om de banktaken via de app uit te voeren.

Daarom moet de banktoepassing worden getest op een eenvoudig en efficiënt ontwerp om deze bruikbaar te maken voor verschillende groepen klanten. De eenvoudigere en gemakkelijk te gebruiken interface is dat het grotere aantal klanten zal profiteren van de banktoepassing.

Het gaat erom het gemak te onderzoeken dat zakelijke gebruikers of bankklanten hebben bij het gebruik van de applicatie. Deze test wordt niet uitgevoerd door de ontwikkelaar of tester, maar door de zakelijke gebruikers.

Bijvoorbeeld, Iedereen gebruikt tegenwoordig mobiele apps. De bank-app moet gebruiksvriendelijk zijn en gemakkelijk te begrijpen en te gebruiken door de eindgebruiker.

Soorten bruikbaarheidstests

Vergelijkende bruikbaarheidstests: Dit zijn op vergelijking gebaseerde tests, waarbij het gebruiksgemak van de ene website of applicatie met een andere wordt gemaakt. Het doel van dergelijke tests is om de beste gebruikerservaring te bieden.

Exploratieve bruikbaarheidstests: Het doel van deze tests is om te bepalen over welke functies de nieuwe applicatie of software moet beschikken om aan de klantvereisten van de bank te voldoen.

Hieronder volgen de voor- en nadelen van bruikbaarheidstests

beste software om videobestanden te converteren

Voordelen:

  • De eindgebruikers van de applicatie zijn meestal betrokken bij het testen, waardoor feedback uit de eerste hand wordt verkregen.
  • In plaats van tijd te besteden aan analyse en discussie over een functie die een product wel of niet zou moeten hebben, is het beter om de input rechtstreeks van de eindgebruiker te krijgen.
  • We kunnen eventuele problemen op voorhand opvangen.

Nadelen:

  • Aangezien er meerdere eindgebruikers bij het testen betrokken zijn, kan hun mening, zo niet nauwkeurig, van invloed zijn op de vereiste.
  • De feed van eindgebruikers kan worden beïnvloed.

Prestatietests

Bepaalde periodes, zoals betaaldag, einde van het financiële jaar, feestelijke seizoenen kunnen zorgen voor verandering of piek in het gebruikelijke verkeer op de app. Daarom moeten er grondige prestatietests worden uitgevoerd, zodat klanten niet worden beïnvloed door prestatiestoringen.

Een belangrijk voorbeeld uit het verleden waarbij bankklanten persoonlijk werden getroffen door prestatiestoringen, is de IT-storing van NatWest en RBS cyber Monday, waarbij de klanten met hun bankpas en creditcard transacties tussen winkels in het land geweigerd kregen.

Testen van gebruikersacceptatie

Dit wordt gedaan door de eindgebruikers te betrekken om ervoor te zorgen dat de applicatie voldoet aan de real-world scenario's en door gebruikers wordt geaccepteerd als deze live gaat.

In het scenario van vandaag de meeste bancaire projecten gebruiken : Agile / Scrum-, RUP- en Continuous Integration-methodologieën, en Tools-pakketten zoals Microsoft's VSTS en Rational Tools.

Zoals we hierboven vermeldden over RUP, staat RUP voor Rational Unified Process, een iteratieve softwareontwikkelingsmethodologie die door IBM is geïntroduceerd en die bestaat uit vier fasen waarin ontwikkelings- en testactiviteiten worden uitgevoerd.

Vier fasen zijn
i) Oprichting
ii) Samenwerking
iii) Constructie en
iv) Overgang

RUP maakt op grote schaal gebruik van IBM Rational-tools.

Voorbeeldtestcases voor banktoepassingen

Testcases voor New Branch

  • Maak een nieuwe branch met geldige en ongeldige testgegevens.
  • Maak een nieuwe branch zonder gegevens.
  • Maak een nieuw filiaal met bestaande filiaalgegevens.
  • Controleer de reset- en annuleringsopties.
  • Werk filiaalgegevens bij met geldige en ongeldige testgegevens.
  • Werk filiaaldetails bij met bestaande branchetestgegevens.
  • Controleer of de nieuwe branch kan worden opgeslagen.
  • Controleer of de annuleringsoptie werkt.
  • Controleer de verwijdering van de vertakking met en zonder afhankelijkheden.
  • Controleer of de zoekoptie voor filialen werkt.

Testcases voor nieuwe rol

  • Maak een nieuwe rol met geldige en ongeldige testgegevens.
  • Maak een nieuwe rol zonder gegevens.
  • Controleer of er een nieuwe rol kan worden gemaakt met bestaande testgegevens.
  • Controleer de rolbeschrijving en roltypen.
  • Controleer of de optie annuleren en opnieuw instellen werkt.
  • Verifieer het rolverwijderingsproces met en zonder afhankelijkheid.
  • Controleer de links op de pagina met roldetails.
  • Verifieer de admin-login zonder testgegevens.
  • Controleer alle homelinks voor de beheerdersrol.
  • Controleer of de beheerder het wachtwoord kan wijzigen met geldige en ongeldige testgegevens.
  • Controleer of de beheerder is uitgelogd.

Testcases voor klant en bankier

  • Controleer of alle bezoekers- en klantlinks correct werken.
  • Verifieer de login van de klant met geldige en ongeldige testgegevens.
  • Verifieer de login van de klant zonder enige gegevens.
  • Verifieer de login van de bankier zonder enige gegevens.
  • Verifieer de login van de bankier met geldige of ongeldige testgegevens.
  • Controleer of de klant of bankier succesvol kan uitloggen.

Testcases voor nieuwe gebruikers

  • Controleer of de nieuwe gebruiker kan worden gemaakt met geldige en ongeldige testgegevens.
  • Maak een nieuwe gebruiker met bestaande testgegevens van filialen
  • Controleer of de optie Annuleren en resetten correct werkt.
  • Werk gebruikersgegevens bij met geldige en ongeldige testgegevens.
  • Controleer of de nieuwe gebruiker is verwijderd.
  • controleer of de nieuwe gebruiker kan worden geverifieerd.
  • Controleer de verplichte invoerparameters.
  • Controleer optionele invoerparameters.
  • Controleer of een gebruiker kan worden gemaakt zonder optionele parameters.

Testcases voor het aanmaken van een nieuw account

  • Maak een nieuw account aan met geldige en ongeldige gebruikersgegevens.
  • Controleer of gebruikersgegevens kunnen worden bijgewerkt.
  • Controleer of een nieuwe gebruiker kan worden opgeslagen.
  • Maak een nieuw account met de gegevens van de bestaande gebruiker.
  • Controleer of de gebruiker het bedrag kan storten op het nieuw aangemaakte account (en het saldo kan bijwerken).
  • Controleer of de gebruiker een bedrag van de nieuwe rekening kan opnemen (na storting en het saldo bijwerken).
  • In het geval van salaris, account verifieer de bedrijfsnaam en andere details worden verstrekt door de gebruiker.
  • Controleer of het primaire accountnummer is opgegeven in het geval van een secundair account.
  • Controleer de gebruikersgegevens die zijn verstrekt in gevallen van de huidige account.
  • Controleer de verstrekte bewijzen voor gezamenlijke rekening in geval van een gezamenlijke rekening.
  • Controleer of het saldo van nul op de salarisrekening kan worden gehandhaafd.
  • Controleer of u het saldo van nul of het minimum kunt behouden voor de niet-salarisrekening.
  • Controleer of de nieuwe gebruiker succesvol kan uitloggen.

Testcases voor Net Banking-toepassing

  • Controleer of de gebruiker de banksite kan openen.
  • Controleer of alle links op de site werken.
  • Controleer of de gebruiker een nieuw account kan aanmaken.
  • Controleer of de gebruiker kan inloggen met een geldige en ongeldige gebruikersnaam en wachtwoord.
  • Controleer of de gebruikersnaam of het wachtwoord leeg is tijdens het inloggen. De gebruiker mag niet inloggen en er wordt een waarschuwingsbericht weergegeven.
  • Controleer of de gebruiker het wachtwoord mag wijzigen.
  • Als een ongeldige gebruiker of wachtwoord wordt ingevoerd, wordt de juiste foutmelding weergegeven.
  • Gebruikers met een ongeldig wachtwoord mogen niet inloggen.
  • Controleer of na herhaalde pogingen om in te loggen met een onjuist wachtwoord, de gebruiker een foutmelding moet krijgen en moet worden geblokkeerd.
  • Controleer of de gebruiker enkele basistransacties kan uitvoeren.
  • Controleer of de gebruiker een begunstigde met geldige en ongeldige gegevens kan toevoegen.
  • Controleer of de gebruiker de begunstigde kan verwijderen.
  • Controleer of de gebruiker transacties kan uitvoeren naar de nieuw toegevoegde begunstigde.
  • Controleer na de transactie of de rekeningen van zowel de gebruiker als de begunstigde zijn bijgewerkt.
  • Controleer of de gebruiker het bedrag in decimalen kan invoeren.
  • Controleer of de gebruiker geen negatieve getallen kan invoeren in het bedragveld.
  • Controleer of de gebruiker transacties mag doen met of zonder minimum saldo.
  • Controleer of de gebruiker een nieuwe RD kan maken.
  • Controleer of het juiste bericht wordt weergegeven in het geval van een transactie met onvoldoende saldo.
  • Controleer of de gebruiker om bevestiging wordt gevraagd voordat een transactie wordt uitgevoerd.
  • Controleer of er voor elke geslaagde transactie een ontvangstbevestiging wordt verstrekt.
  • Controleer of de gebruiker geld naar meerdere accounts kan overboeken.
  • controleer of de gebruiker de transactie kan annuleren.
  • Controleer of de accountgegevens ook de financiële transacties weerspiegelen.
  • Controleer of de time-outfunctie is geïmplementeerd.
  • controleer of een gebruiker in het geval van een sessietime-out opnieuw moet inloggen.
  • controleer of de juiste sessietime-out is verstreken in het geval van inactiviteit.
  • controleer of de gebruiker tijdens het uitvoeren van de transactie naar de beveiligde modus wordt gebracht.
  • Controleer of de gebruiker zich succesvol kan afmelden.
  • Controleer de zoek- en resetopties.

Gevolgtrekking

In dit artikel hebben we besproken hoe complex een banktoepassing kan zijn en wat zijn de typische fasen die betrokken zijn bij het testen van de applicatie ​Afgezien daarvan bespraken we ook de huidige trends, gevolgd door IT-industrieën, inclusief methoden voor softwareontwikkeling en tools.

Deel gerust uw ervaringen of vragen over dit onderwerp!

Aanbevolen literatuur

^