Menu

Comment tester les applications de domaine bancaire: un guide complet de test BFSI

how test banking domain applications

Essayez Notre Instrument Pour Éliminer Les Problèmes

Un guide complet pour tester les applications bancaires: processus de test BFSI (services bancaires, services financiers et assurances) et conseils

Les applications bancaires sont l’une des applications les plus complexes de l’industrie actuelle du développement et des tests de logiciels.

Qu'est-ce qui rend les applications bancaires si complexes? Quelle approche adopter pour tester les workflows complexes impliqués dans les applications bancaires?

Dans cet article, nous mettrons en évidence les différentes étapes et techniques impliquées dans le test des applications bancaires.

Comment tester les applications bancaires

Ce que vous apprendrez:

Comment tester les applications bancaires?

Les différentes fonctions exécutées par les applications bancaires sont:

Fonctions-des-banques

Voyons d'abord les caractéristiques d'une application bancaire:

  • Fonctionnalité multi-niveaux pour prendre en charge des milliers de sessions utilisateur simultanées
  • Intégration à grande échelle: généralement, une application bancaire s'intègre à de nombreuses autres applications telles que l'utilitaire Bill Pay et les comptes de trading
  • Workflows commerciaux complexes
  • Traitement en temps réel et par lots
  • Le taux élevé de transactions par seconde
  • Transactions sécurisées
  • Section de rapports robuste pour suivre les transactions quotidiennes
  • Audit solide pour résoudre les problèmes des clients
  • Système de stockage massif
  • Gestion des catastrophes / reprise.

Les dix points énumérés ci-dessus sont les caractéristiques les plus importantes d'une application bancaire.

Les applications bancaires ont plusieurs niveaux impliqués dans l'exécution d'une opération.

Par exemple , à L'application bancaire peut avoir:

  • Serveur Web pour interagir avec les utilisateurs finaux via le navigateur
  • Middle Tier pour valider l'entrée et la sortie du serveur Web
  • DataBase pour stocker des données et des procédures
  • Processeur de transaction qui pourrait être un mainframe de grande capacité ou tout autre système hérité pour effectuer des milliards de transactions par seconde.

Si l'on parle de tester les applications bancaires, cela nécessite un Méthodologie de test de bout en bout impliquant plusieurs techniques de test de logiciel pour garantir:

  • Couverture totale de tous les workflows bancaires et exigences commerciales
  • L'aspect fonctionnel de l'application
  • L'aspect sécurité de l'application
  • Intégrité des données
  • Concurrence
  • Expérience utilisateur

Qu'est-ce qui rend les applications bancaires si complexes?

  • Les logiciels bancaires traitent principalement des données financières confidentielles, de sorte que les performances des logiciels doivent être sans erreur et sécurisées.
  • Les développeurs préfèrent une conception compliquée pour développer ces applications afin de garantir que l'application s'exécute de la manière sécurisée souhaitée.
  • La banque est un monde en constante évolution. Aujourd'hui, les services bancaires sont mis à la disposition du client en utilisant différents canaux tels que les succursales physiques, les guichets automatiques, les services bancaires en ligne et le service client.
  • Avec l'avènement de la technologie, de nombreux portefeuilles ont inondé les marchés qui se connectent aux systèmes bancaires pour les transactions financières.
  • Les services bancaires devraient également être opérationnels 24 heures sur 24, 7 jours sur 7 avec des performances élevées. Les mises à niveau logicielles, les correctifs instantanés, etc. ne peuvent pas avoir un impact sur cette disponibilité.
  • Le monde bancaire est également fortement impacté par les changements constants apportés par le gouvernement sous la forme de réglementations bancaires. Tout changement dans la structure fiscale a également un impact sur le système bancaire.
  • Le système bancaire doit également se mettre à jour en ce qui concerne les nouvelles technologies. L'analyse de données comme le traitement des données volumineuses et l'extraction des instincts du big data à l'aide de la science des données est de plus en plus présente dans le monde bancaire.

Les points mentionnés ci-dessus rendent le système bancaire complexe pour que les développeurs créent une application logicielle autour de lui.

Importance de tester une application bancaire

  • Le test de l'application bancaire garantit que toutes les activités sont non seulement bien exécutées, mais restent également protégées et sécurisées.
  • Les logiciels bancaires sont compliqués avec des milliers de dépendances, le processus de test nécessite plus de temps, de ressources et une surveillance continue.
  • Comme les finances sont impliquées ici, les directives doivent être strictement suivies. Les testeurs et les développeurs doivent avoir une bonne connaissance du domaine.
  • Plus important encore, il faut s'assurer que les lois et règlements sont correctement appliqués dans les transactions financières. Cela ne peut être garanti que par des tests.
  • Il est également important de s'assurer que l'application et l'infrastructure sur lesquelles l'application a été déployée sont capables de gérer la charge, en particulier pendant les heures de pointe, sans provoquer de perturbation. Cela peut être garanti en effectuant des tests de performance.
  • Dans le monde numérique d’aujourd’hui, la seule chose qui préoccupe tout le monde est celle de la sécurité. Les applications bancaires et les transactions financières qui y sont effectuées doivent être protégées de toute tentative d'effraction. Cela peut être garanti en effectuant des tests de sécurité. Les tests de sécurité aident à appliquer les normes de l'industrie pour sécuriser les transactions financières.
  • Il est également important de s'assurer que les différents modules d'une application bancaire et intégrés correctement et atteignent l'objectif du client. Les tests d'intégration de système aident à réaliser cette tâche.

Flux de travail de test des applications bancaires

Étapes typiques du test des applications bancaires sont présentés dans le flux de travail ci-dessous. Nous discuterons de chaque étape individuellement.

Il s'agit d'un modèle Waterfall de test d'une application.

Test des applications bancaires

# 1) Rassemblement des exigences

Phase de collecte des exigences implique la documentation des exigences sous forme de spécifications fonctionnelles ou de cas d'utilisation. Les exigences sont rassemblées selon les besoins des clients et documentées par des experts bancaires ou un analyste commercial.

Rassemblement des exigences

Les experts sont impliqués dans la rédaction des exigences sur plus d'un sujet car la banque elle-même a plusieurs sous-domaines et une application bancaire à part entière sera l'intégration de tous ces domaines.

Par exemple, Une application bancaire peut avoir des modules séparés pour les virements, les cartes de crédit, les rapports, les comptes de prêt, les paiements de factures, le trading, etc.

# 2) Examen des exigences

Le livrable de la collecte des exigences est examiné par toutes les parties prenantes telles que les ingénieurs QA, les responsables du développement et les analystes commerciaux par les pairs.

Examen des exigences

Ils vérifient que ni le flux de travail d'entreprise existant ni les nouveaux flux de travail ne sont violés. Toutes les exigences sont vérifiées et validées. Les actions de suivi et les révisions des documents d'exigences sont effectuées sur la même base.

# 3) Préparation du scénario commercial

Dans cette étape, les ingénieurs QA dérivent des scénarios commerciaux à partir des documents d'exigence (spécifications de fonctions ou cas d'utilisation); Les scénarios commerciaux sont dérivés de manière à ce que toutes les exigences commerciales soient couvertes. Les scénarios commerciaux sont des scénarios de haut niveau sans étapes détaillées.

En outre, ces scénarios commerciaux sont examinés par des analystes commerciaux pour s'assurer que toutes les exigences opérationnelles sont satisfaites. Il est plus facile pour les BA d'examiner des scénarios de haut niveau plutôt que d'examiner des cas de test détaillés de bas niveau.

Par exemple , un client ouvrant un dépôt fixe sur l'interface bancaire numérique peut être un scénario commercial. De même, nous pouvons avoir différents scénarios commerciaux liés à la création de compte bancaire net, aux dépôts en ligne, aux virements en ligne, etc.

# 4) Test fonctionnel

À cette étape, des tests fonctionnels sont effectués et les activités de test de logiciels habituelles sont effectuées telles que:

Préparation du cas de test: Dans cette étape, les cas de test sont dérivés de scénarios commerciaux, un scénario d'affaires conduit à plusieurs cas de test positifs et des cas de test négatifs. Généralement, les outils utilisés à cette étape sont Microsoft Excel, Test Director ou Quality Center.

Examen des cas de test: Avis par des ingénieurs AQ pairs

Cas de test Exécution: L'exécution de cas de test peut être manuelle ou automatique impliquant des outils tels que QC, QTP, etc.

Le test fonctionnel d'une application bancaire est assez différent du test logiciel ordinaire. Étant donné que ces applications fonctionnent avec l’argent du client et les données financières sensibles, elles doivent être testées de manière approfondie. Aucun scénario commercial important ne doit être laissé à couvert.

En outre, la ressource QA qui teste l'application doit avoir les connaissances de base du domaine bancaire.

# 5) Test de base de données

L'application bancaire implique des transactions complexes qui sont effectuées à la fois au niveau de l'interface utilisateur et au niveau de la base de données.Par conséquent, les tests de bases de données sont aussi importants que les tests fonctionnels. La base de données est compliquée et une couche entièrement séparée dans l'application et ses tests sont donc effectués par des spécialistes de la base de données. Il utilise des techniques telles que:

  • Chargement des données
  • Migration de base de données
  • Test du schéma de base de données et des types de données
  • Test des règles
  • Test des procédures et fonctions stockées
  • Tester les déclencheurs
  • Intégrité des données

Le principal objectif des tests de bases de données est de garantir que:

  • L'application est capable de stocker et de récupérer des données de la base de données sans aucune perte de données.
  • Les transactions terminées doivent être validées et les transactions annulées sont annulées pour éviter toute incohérence dans les données stockées.
  • Seuls les utilisateurs et applications autorisés sont autorisés à accéder à la base de données et aux tables sous-jacentes.

Il existe principalement trois méthodes de test de base de données:

  • Essais structurels
  • Test fonctionel
  • Tests non fonctionnels

Essais structurels

Cela implique de tester les objets de la base de données tels que les bases de données, le schéma, les tables, les vues, les déclencheurs, les contrôles d'accès, etc. S'assurer que les types de données dans les tables sont synchronisés avec les variables correspondantes dans l'application. Valider les données et l'intégrité référentielle dans les tableaux.

Par exemple, Un champ de montant dans l'application doit avoir un type de données décimal / flottant dans la table.

- Afin de se conformer aux normes, les utilisateurs doivent bénéficier de contrôles d'accès via des vues.

Test fonctionel

Il s'agit de tester les bases de données qui répondent aux besoins des utilisateurs. Il y a deux façons d'y parvenir: les tests en boîte noire et les tests en boîte blanche.

Par exemple, Lorsque nous effectuons un transfert d'argent en ligne, le compte de l'expéditeur doit être débité et le compte du destinataire doit être crédité du même montant exact. Si la transaction échoue, toutes les transactions doivent être annulées et le compte de l'expéditeur ne doit pas être débité ou crédité.

Tests non fonctionnels

Cela implique des tests de charge et de stress et une optimisation des performances. Les tests de charge aident à identifier le plus grand nombre de transactions pouvant être effectuées simultanément sans affecter les performances de la base de données.

Par exemple, Sur la base des données provenant des tests de charge et de stress, les applications bancaires peuvent décider d'ajouter plus de ressources à leur application pendant les heures de pointe et de réduire les ressources en dehors des heures de bureau. Cela aide la banque à utiliser au mieux ses ressources et à économiser de l'argent.

# 6) Test de sécurité

Les tests de sécurité constituent généralement la dernière étape du cycle de test. Une condition préalable au début des tests de sécurité est la réalisation des tests fonctionnels et non fonctionnels. Les tests de sécurité sont l'une des étapes majeures de l'ensemble du cycle de test des applications, car cette étape garantit que l'application est conforme aux normes fédérales et industrielles.

En raison de la nature des données qu'elles transportent, les applications bancaires sont très sensibles et constituent une cible de choix pour les pirates informatiques et les activités frauduleuses. Les tests de sécurité garantissent que l'application ne présente aucune vulnérabilité Web susceptible d'exposer des données sensibles à un intrus ou à un attaquant. Il garantit également que l'application est conforme aux normes telles que OWASP.

À ce stade, la tâche principale est l'analyse complète de l'application qui est effectuée à l'aide d'outils comme IBM AppScan ou HP WebInspect (ce sont les outils les plus populaires).

Une fois l'analyse terminée, le rapport d'analyse est publié. Dans ce rapport, les faux positifs sont filtrés et le reste des vulnérabilités est signalé à l'équipe de développement afin qu'elle commence à résoudre les problèmes en fonction de la gravité de chaque problème.

Des tests de pénétration sont également effectués à cette étape pour révéler la propagation des erreurs. Des tests de sécurité rigoureux doivent être effectués sur les plates-formes, les réseaux et le système d'exploitation.

Quelques autres Outils manuels pour les tests de sécurité utilisés sont Proxy de Paros , Montre Http , Suite Burp , et Fortifier.

Le but principal des tests de sécurité est d'identifier les vulnérabilités que l'application logicielle peut avoir.

Le test de sécurité teste l'application contre:

  • Toute attaque externe ou tentative de piratage de l'application avec une intention malveillante.
  • Toute faille dans l'application logicielle pourrait être exploitée entraînant des pertes de données ou d'argent.
  • Toute vulnérabilité du réseau, des serveurs et des postes de travail qui hébergent l'application.

Voici les différents types de tests de sécurité:

Test de vulnérabilité: Un programme automatisé est développé et exécuté pour rechercher diverses vulnérabilités.

Analyse de sécurité: Cette variante tourne autour de l'étude des vulnérabilités du réseau et du système, fournit des solutions pour réduire le risque associé.

Tests de pénétration: Cette variante des tests de sécurité imite une tentative de piratage pour capturer les vulnérabilités et les failles, qui autrement auraient pu accéder à la base de données ou aux données de l'application.

Audit de sécurité: Il implique l'audit de l'application et des réseaux associés pour détecter d'éventuelles défaillances de sécurité.

L'évaluation des risques: Cette variante effectue une analyse pour évaluer le niveau de risque, dans un événement où une vulnérabilité ou une faille est exploitée à des fins malveillantes. Un tel risque peut être classé en faible, moyen et élevé. En fonction du niveau de risque, des mesures appropriées sont conseillées par l'équipe de test pour réduire ou éviter le risque.

Piratage éthique: Ceci est effectué par une organisation sur ses systèmes pour identifier les failles qui pourraient être exploitées dans son application ou son réseau. Le but de ce type de piratage n'est pas de voler ou d'endommager l'application ou le réseau.

Évaluation de la posture: Il s'agit d'une évaluation globale comprenant l'analyse de la sécurité, les évaluations des risques et le piratage éthique.

Injection SQL: L'injection SQL peut être utilisée pour accéder à la base de données du serveur. Le test est effectué pour s'assurer que le code fonctionne correctement, ce qui exécute des requêtes sur la base de données en fonction des entrées suivantes de l'utilisateur:

  • Supports
  • Apostrophes
  • Virgules
  • Guillemets

Autres étapes du test de l'application BFSI

Outre les étapes principales ci-dessus, il peut y avoir différentes étapes impliquées, telles que les tests d'intégration, les tests d'utilisabilité, les tests d'acceptation des utilisateurs et les tests de performances.

Parlons également brièvement de ces étapes:

Test d'intégration

Comme vous le savez, dans une application bancaire, il peut y avoir plusieurs modules différents comme les virements, les paiements de factures, les dépôts, etc. Et donc, de nombreux composants sont développés. Dans les tests d'intégration, tous les composants et intégrés ensemble et validés.

Tests d'utilisation

Tests d

Une application bancaire sert une grande variété de clients. Certains de ces clients peuvent ne pas avoir les compétences et la sensibilisation nécessaires pour effectuer les tâches bancaires via l'application.

Ainsi, l'application bancaire doit être testée pour une conception simple et efficace afin de la rendre utilisable par différents groupes de clients. L'interface la plus simple et la plus facile à utiliser est, plus le nombre de clients bénéficiera de l'application bancaire.

Il s'agit d'examiner le niveau de facilité d'utilisation de l'application par les utilisateurs professionnels ou les clients de la banque. Ce test n'est pas effectué par le développeur ou le testeur, mais est effectué par les utilisateurs professionnels.

Par exemple, De nos jours, tout le monde utilise des applications mobiles. L'application bancaire doit être conviviale et facile à comprendre et à utiliser par l'utilisateur final.

Types de tests d'utilisabilité

Test d'utilisabilité comparatif: Il s'agit de tests basés sur des comparaisons, où la facilité d'utilisation d'un site Web ou d'une application avec un autre. L'objectif de ces tests est de fournir la meilleure expérience utilisateur.

Test d'utilisabilité exploratoire: L’objectif de ces tests est d’identifier les fonctionnalités que la nouvelle application ou le nouveau logiciel doit posséder pour répondre aux besoins des clients de la banque.

Voici les avantages et les inconvénients des tests d'utilisabilité

comment utiliser eclipse pour c

Avantages:

  • Les utilisateurs finaux de l'application sont généralement impliqués dans les tests, d'où une rétroaction de première main.
  • Plutôt que de passer du temps sur l'analyse et la discussion sur une fonctionnalité qu'un produit devrait avoir ou non, il est préférable d'obtenir les entrées directement de l'utilisateur final.
  • Nous pouvons détecter à l'avance tout problème potentiel.

Désavantages:

  • Comme plusieurs utilisateurs finaux sont impliqués dans les tests, leurs opinions, si elles ne sont pas précises, peuvent affecter l'exigence.
  • Le flux des utilisateurs finaux peut être influencé.

Test de performance

Certaines périodes comme le jour de paie, la fin de l'exercice financier, les périodes de fêtes peuvent apporter des changements ou augmenter le trafic habituel sur l'application. Par conséquent, des tests de performances approfondis doivent être effectués afin que les clients ne soient pas affectés par des défaillances de performances.

Un exemple significatif du passé où les clients des banques ont été personnellement affectés en raison de défaillances de performances est la panne informatique de NatWest et RBS cyber Monday dans laquelle les clients ont eu leur carte de débit et les transactions refusées dans les magasins du pays.

Test d'acceptation des utilisateurs

Cela se fait en impliquant les utilisateurs finaux pour s'assurer que l'application est conforme aux scénarios du monde réel et qu'elle sera acceptée par les utilisateurs si elle est mise en ligne.

Dans le scénario d'aujourd'hui la majorité des projets bancaires utilisent : Méthodologies Agile / Scrum, RUP et d'intégration continue, et packages d'outils tels que VSTS et Rational Tools de Microsoft.

Comme nous l'avons mentionné à propos de RUP ci-dessus, RUP signifie Rational Unified Process, qui est une méthodologie de développement logiciel itérative introduite par IBM et qui comprend quatre phases dans lesquelles les activités de développement et de test sont effectuées.

Quatre phases sont
i) Création
ii) Collaboration
iii) Construction et
iv) Transition

RUP implique largement les outils IBM Rational.

Exemples de cas de test pour une application bancaire

Cas de test pour New Branch

  • Créez une nouvelle branche avec des données de test valides et non valides.
  • Créez une nouvelle branche sans données.
  • Créez une nouvelle branche avec des données de branche existantes.
  • Vérifiez les options de réinitialisation et d'annulation.
  • Mettez à jour les détails de la branche avec des données de test valides et non valides.
  • Mettez à jour les détails de la branche avec les données de test de branche existantes.
  • Vérifiez si la nouvelle branche peut être enregistrée.
  • Vérifiez que l'option d'annulation fonctionne.
  • Vérifiez la suppression de la branche avec et sans dépendances.
  • Vérifiez si l'option de recherche de branche fonctionne.

Cas de test pour un nouveau rôle

  • Créez un nouveau rôle avec des données de test valides et non valides.
  • Créez un nouveau rôle sans données.
  • Vérifiez qu'un nouveau rôle peut être créé avec les données de test existantes.
  • Vérifiez la description du rôle et les types de rôle.
  • Vérifiez que l'option d'annulation et de réinitialisation fonctionne.
  • Vérifiez le processus de suppression de rôle avec et sans dépendance.
  • Vérifiez les liens dans la page des détails du rôle.
  • Vérifiez la connexion administrateur sans données de test.
  • Vérifiez tous les liens d'accueil pour le rôle d'administrateur.
  • Vérifiez que l'administrateur peut modifier le mot de passe avec des données de test valides et non valides.
  • Vérifiez la déconnexion de l'administrateur avec succès.

Cas de test pour le client et le banquier

  • Vérifiez si tous les liens visiteurs et clients fonctionnent correctement.
  • Vérifiez la connexion du client avec des données de test valides et non valides.
  • Vérifiez la connexion du client sans aucune donnée.
  • Vérifiez la connexion bancaire sans aucune donnée.
  • Vérifiez la connexion bancaire avec des données de test valides ou non valides.
  • Vérifiez que le client ou le banquier peut se déconnecter avec succès.

Cas de test pour les nouveaux utilisateurs

  • Vérifiez si le nouvel utilisateur peut être créé avec des données de test valides et non valides.
  • Créer un nouvel utilisateur avec les données de test de branche existantes
  • Vérifiez si l'option d'annulation et de réinitialisation fonctionne correctement.
  • Mettez à jour les détails de l'utilisateur avec des données de test valides et non valides.
  • Vérifiez la suppression du nouvel utilisateur.
  • vérifier si le nouvel utilisateur peut être vérifié.
  • Vérifiez les paramètres d'entrée obligatoires.
  • Vérifiez les paramètres d'entrée facultatifs.
  • Vérifiez si un utilisateur peut être créé sans paramètres facultatifs.

Cas de test pour la création d'un nouveau compte

  • Créez un nouveau compte avec des données utilisateur valides et non valides.
  • Vérifiez si les détails de l'utilisateur peuvent être mis à jour.
  • Vérifiez si un nouvel utilisateur peut être enregistré.
  • Créez un nouveau compte avec les données de l'utilisateur existant.
  • Vérifiez que l'utilisateur peut déposer le montant dans le compte nouvellement créé (et mettre à jour le solde).
  • Vérifiez que l'utilisateur peut retirer un montant du nouveau compte (après le dépôt et mettre à jour le solde).
  • Dans le cas du salaire, vérifiez le compte du nom de l'entreprise et d'autres détails sont fournis par l'utilisateur.
  • Vérifiez si le numéro de compte principal est fourni dans le cas d'un compte secondaire.
  • Vérifiez les détails de l'utilisateur fournis dans les cas du compte actuel.
  • Vérifiez les preuves fournies pour un compte joint dans le cas d'un compte joint.
  • Vérifiez s'il est en mesure de maintenir un solde nul dans le compte de salaire.
  • Vérifiez si vous pouvez maintenir un solde nul ou un solde minimum pour le compte non salarial.
  • Vérifiez que le nouvel utilisateur peut se déconnecter avec succès.

Cas de test pour l'application Net Banking

  • Vérifiez si l'utilisateur est en mesure d'ouvrir le site de la banque.
  • Vérifiez si tous les liens du site fonctionnent.
  • Vérifiez si l'utilisateur est en mesure de créer un nouveau compte.
  • Vérifiez si l'utilisateur est capable de se connecter avec un nom d'utilisateur et un mot de passe valides et non valides.
  • Vérifiez si le nom d'utilisateur ou le mot de passe est vide lors de la connexion, l'utilisateur ne doit pas être autorisé à se connecter et un message d'alerte s'affiche.
  • Vérifiez si l'utilisateur est autorisé à modifier le mot de passe.
  • Si un utilisateur ou un mot de passe non valide est entré, un message d'erreur approprié s'affiche.
  • Les utilisateurs avec un mot de passe non valide ne doivent pas être autorisés à se connecter.
  • Vérifiez qu'après plusieurs tentatives de connexion avec un mot de passe incorrect, l'utilisateur doit recevoir un message d'erreur et être bloqué.
  • Vérifiez si l'utilisateur est capable d'effectuer certaines transactions de base.
  • Vérifiez que l'utilisateur est en mesure d'ajouter un bénéficiaire avec des détails valides et non valides.
  • Vérifiez si l'utilisateur peut supprimer le bénéficiaire.
  • Vérifiez que l'utilisateur est en mesure d'effectuer des transactions avec le bénéficiaire nouvellement ajouté.
  • Après la transaction, vérifiez si les comptes de l'utilisateur et du bénéficiaire sont mis à jour.
  • Vérifiez si l'utilisateur est en mesure de saisir le montant en nombre décimal.
  • Vérifiez si l'utilisateur n'est pas en mesure de saisir des nombres négatifs dans le champ montant.
  • Vérifiez si l'utilisateur est autorisé à effectuer des transactions avec ou sans solde minimum.
  • Vérifiez si l'utilisateur peut créer un nouveau RD.
  • Vérifiez que le message approprié est affiché en cas de transaction effectuée avec un solde insuffisant.
  • Vérifiez si l'utilisateur est invité à confirmer avant toute transaction.
  • Vérifiez si un accusé de réception est fourni à chaque transaction réussie.
  • Vérifiez si l'utilisateur est en mesure de transférer de l'argent vers plusieurs comptes.
  • vérifier si l'utilisateur peut annuler la transaction.
  • Vérifiez que les détails du compte reflètent également les transactions financières effectuées.
  • Vérifiez que la fonction de délai d'expiration est implémentée.
  • vérifiez qu'en cas d'expiration de la session, un utilisateur doit se reconnecter.
  • Vérifiez que le délai d'expiration de la session est effectué en cas d'inactivité.
  • vérifiez que lors de la transaction, l'utilisateur passe en mode sécurisé.
  • Vérifiez si l'utilisateur peut se déconnecter avec succès.
  • Vérifiez les options de recherche et de réinitialisation.

Conclusion

Dans cet article, nous avons discuté la complexité d'une application bancaire et quels sont les phases typiques impliquées dans le test de l'application . En dehors de cela, nous avons également discuté des tendances actuelles suivies par les industries informatiques, y compris les méthodologies et les outils de développement de logiciels.

N'hésitez pas à partager votre expérience ou vos questions sur ce sujet!

lecture recommandée

^