Comprenons d’abord les caractéristiques d’une application bancaire :

#1) Recueil des besoins

Phase de recueil des besoins implique la documentation des exigences, soit sous forme de spécifications fonctionnelles, soit sous forme de cas d’utilisation. Les exigences sont recueillies en fonction des besoins du client et documentées par des experts bancaires ou des analystes commerciaux.

Les experts sont impliqués dans la rédaction des exigences sur plus d’un sujet, car le secteur bancaire lui-même comporte de multiples sous-domaines et une application bancaire à part entière sera l’intégration de tous ces domaines.

Par exemple, Une application bancaire peut comporter des modules distincts pour les virements, les cartes de crédit, les rapports, les comptes de prêts, les paiements de factures, les transactions, etc.

#2) Examen des besoins

Le résultat du recueil des exigences est examiné par toutes les parties prenantes, telles que les ingénieurs AQ, les responsables du développement et les analystes d’entreprise pairs.

Ils vérifient que ni les flux de travail existants ni les nouveaux flux de travail ne sont violés. Toutes les exigences sont vérifiées et validées. Des actions de suivi et des révisions du document d’exigences sont effectuées sur la base de ces dernières.

#3) Préparation du scénario d’entreprise

Au cours de cette étape, les ingénieurs AQ dérivent des scénarios d’entreprise à partir des documents d’exigences (spécifications de fonctions ou cas d’utilisation) ; les scénarios d’entreprise sont dérivés de manière à couvrir toutes les exigences d’entreprise. Les scénarios d’entreprise sont des scénarios de haut niveau sans aucune étape détaillée.

De plus, ces scénarios d’affaires sont examinés par les analystes d’affaires pour s’assurer que toutes les exigences d’affaires sont satisfaites. Il est plus facile pour les BAs 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 qui ouvre un dépôt fixe sur l’interface bancaire numérique peut constituer un scénario commercial. De même, nous pouvons avoir différents scénarios commerciaux liés à la création d’un compte net banking, aux dépôts en ligne, aux transferts en ligne, etc.

#4) Tests fonctionnels

Au cours de cette étape, les tests fonctionnels sont effectués et les activités habituelles de test de logiciels sont réalisées, notamment :

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

Revue des cas de test : Commentaires d’ingénieurs AQ pairs

Cas de test Exécution : L’exécution des cas de test peut être manuelle ou automatique, avec des outils comme QC, QTP, etc.

Les tests fonctionnels d’une application bancaire sont très différents des tests logiciels ordinaires. Comme ces applications fonctionnent avec l’argent des clients et des données financières sensibles, elles doivent être testées de manière approfondie. Aucun scénario commercial important ne doit être laissé de côté.

En outre, la ressource AQ qui teste l’application doit avoir une connaissance de base du domaine bancaire.

#5) Test des bases de données

Les applications bancaires impliquent 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 la base de données sont aussi importants que les tests fonctionnels. La base de données est compliquée &amp ; une couche entièrement séparée dans l’application et donc ses tests sont effectués par des spécialistes des bases de données. Ils utilisent des techniques telles que :

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

L’objectif principal des tests de bases de données est de s’assurer que :

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

Il existe principalement trois façons de tester les bases de données :

• Essais structurels
• Tests fonctionnels
• Tests non fonctionnels

Essais structurels

Il s’agit de tester les objets de la base de données tels que les bases de données, les schémas, 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 en phase avec les variables correspondantes dans l’application. Valider les données et l’intégrité référentielle dans les tables.

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

– Afin de se conformer aux normes, les utilisateurs doivent bénéficier de contrôles d’accès par le biais de vues.

Tests fonctionnels

Il s’agit de tester les bases de données qui répondent aux exigences des utilisateurs. Il existe 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. 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

Il implique des tests de charge, des tests de stress et l’optimisation des performances. Les tests de charge permettent d’identifier le nombre maximal de transactions pouvant être effectuées simultanément sans affecter les performances de la base de données.

Par exemple,  Sur la base des résultats des tests de charge et de stress, les applications bancaires peuvent décider d’ajouter des ressources à leur application pendant les heures de pointe et de les réduire pendant les heures creuses. La banque peut ainsi faire un usage optimal de ses ressources et économiser de l’argent.

#6) Tests 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 l’achèvement des tests fonctionnels et non fonctionnels. Le test de sécurité est l’une des principales étapes du cycle de test des applications, car il permet de s’assurer que l’application est conforme aux normes fédérales et sectorielles.

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 &amp ; les activités frauduleuses. Les tests de sécurité permettent de s’assurer que l’application ne présente aucune vulnérabilité web susceptible d’exposer des données sensibles à un intrus ou à un attaquant. Ils garantissent également que l’application est conforme à des normes telles que celles de l’OWASP.

À ce stade, la tâche principale est l’analyse de l’ensemble de l’application, qui est effectuée à l’aide d’outils comme les suivants IBM AppScan or HP WebInspect (voici 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 à corriger les problèmes en fonction de leur gravité.

Les 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 l’ensemble des plateformes, des réseaux et des systèmes d’exploitation.

Autre Outils manuels pour les tests de sécurité used are Paros Proxy, Http Watch, Burp Suite, and Fortify.

L’objectif principal des tests de sécurité est de mettre en évidence les vulnérabilités que l’application logicielle, peut avoir.

.

Les tests de sécurité testent l’application contre :

• Toute attaque externe ou tentative de piratage de l’application avec une intention malveillante.
• Toute faille dans l’application logicielle peut être exploitée et entraîner des pertes de données ou d’argent.
• Toute vulnérabilité dans le réseau, les serveurs et les 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 vérifier les différentes vulnérabilités.

Scanning de sécurité : Cette variante consiste à étudier les vulnérabilités des réseaux et des systèmes et à proposer des solutions pour réduire les risques associés.

Test 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 auraient pu permettre d’accéder à la base de données ou aux données de l’application.

Audit de sécurité : Il s’agit d’un audit de l’application et des réseaux associés pour détecter toute faille de sécurité.

Évaluation des risques : Cette variante effectue une analyse pour évaluer le niveau de risque, dans le cas où une vulnérabilité ou une faille est exploitée à des fins malveillantes. Ce risque peut être classé en trois catégories : 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 : Cette opération est effectuée par une organisation sur ses systèmes afin d’identifier les failles qui pourraient être exploitées dans son application ou son réseau. L’intention de ce type de piratage n’est pas de voler ou de causer des dommages à l’application ou au réseau.

Évaluation de la posture : Il s’agit d’une évaluation globale qui comprend l’analyse de la sécurité, l’évaluation des risques et le piratage éthique.

SQL Injection: L’injection SQL peut être utilisée pour accéder à la base de données du serveur. Les tests sont effectués pour s’assurer que le code fonctionne correctement, qu’il exécute des requêtes sur la base de données en fonction des entrées suivantes de l’utilisateur :

• Supports
• Apostrophes
• Virgules
• Guillemets

Other Stages In Testing BFSI App

Outre les principales étapes mentionnées ci-dessus, il peut y avoir d’autres étapes telles que les tests d’intégration, les tests de convivialité, les tests d’acceptation par les utilisateurs et les tests de performance.

Parlons aussi brièvement de ces étapes.

Tests d’intégration

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

Test d’utilisabilité

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

Ainsi, l’application bancaire doit être testée pour sa conception simple et efficace afin de la rendre utilisable par différents groupes de clients. Plus l’interface est simple &amp ; facile à utiliser, plus le nombre de clients qui bénéficieront de l’application bancaire sera élevé.

It’s about examining the level of ease, business users or bank customers have in using the application. This testing is not performed by the developer or tester but is performed by the business users.

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

Types de tests d’utilisabilité

Test comparatif d’utilisabilité : Il s’agit de tests basés sur la comparaison, 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 possible.

Test d’utilisabilité exploratoire : L’objectif de ce test est d’identifier les caractéristiques que devrait posséder la nouvelle application ou le nouveau logiciel afin de répondre aux exigences des clients de la banque.

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

Avantages :

• Les utilisateurs finaux de l’application sont généralement impliqués dans les tests, ce qui permet d’obtenir des informations de première main.
• Plutôt que de passer du temps à analyser et à discuter d’une fonctionnalité qu’un produit devrait avoir ou non, il est préférable d’obtenir les informations directement de l’utilisateur final.
• Nous pouvons détecter tout problème potentiel à l’avance.

Inconvénients :

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

Test de performance

Certaines périodes comme les jours de paie, la fin de l’année financière, les fêtes de fin d’année peuvent entraîner des changements ou des pics dans le trafic habituel de l’application. Il convient donc de procéder à des tests de performance approfondis afin que les clients ne soient pas affectés par des défaillances de performance.

Un exemple significatif du passé où les clients des banques ont été personnellement affectés par des défaillances de performance est la panne informatique du cyber-lundi de NatWest et RBS, au cours de laquelle les clients ont vu leurs transactions par carte de débit et de crédit refusées dans tous les magasins du pays.

Test d’acceptation par l’utilisateur

Pour ce faire, on implique les utilisateurs finaux afin de 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 service.

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

Comme nous l’avons mentionné plus haut à propos de RUP, RUP est l’abréviation de Rational Unified Process, qui est une méthodologie itérative de développement de logiciels 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) Inception
ii) Collaboration
iii) Construction and
iv) Transition

RUP widely involves IBM Rational tools.

Exemples de cas de test pour une application bancaire

Cas de test pour la nouvelle branche

• Créez une nouvelle branche avec des données de test valides et invalides.
• Créer une nouvelle branche sans données.
• Créer une nouvelle branche avec les données de la branche existante.
• Vérifiez les options de réinitialisation et d’annulation.
• Mettre à jour les détails de la branche avec les données de test valides et invalides.
• Mettre à jour les détails de la branche avec les données de test de la branche existante.
• Vérifier si la nouvelle branche peut être sauvegardée.
• Vérifiez que l’option d’annulation fonctionne.
• Vérifier la suppression de la branche avec et sans les dépendances.
• Vérifier si l’option de recherche de branche fonctionne.

Cas de test pour le nouveau rôle

• Créez un nouveau rôle avec des données de test valides et invalides.
• Créer 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érifier le processus de suppression de rôle avec et sans dépendance.
• Vérifier les liens dans la page de détails du rôle.
• Vérifier la connexion de l’administrateur sans données de test.
• Vérifier tous les liens d’accueil pour le rôle d’administrateur.
• Vérifiez que l’administrateur peut changer le mot de passe avec des données de test valides et invalides.
• Vérifiez que l’administrateur se déconnecte avec succès.

Cas de test pour le client et le banquier

• Vérifiez que tous les liens vers les visiteurs et les clients fonctionnent correctement..
• Vérifier la connexion du client avec des données de test valides et invalides..
• Vérifier le login du client sans aucune donnée.
• Vérifier le login du banquier sans aucune donnée.
• Vérifier le login du banquier avec des données de test valides ou non..
• 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 invalides.
• Créer un nouvel utilisateur avec les données de test de la branche existante
• Vérifiez si l’option d’annulation et de réinitialisation fonctionne correctement..
• Mettre à jour les détails de l’utilisateur avec les données de test valides et invalides.
• Vérifier la suppression du nouvel utilisateur.
• vérifier si le nouvel utilisateur peut être vérifié.
• Vérifier les paramètres d’entrée obligatoires.
• Vérifier les paramètres d’entrée optionnels.
• Vérifier si un utilisateur peut être créé sans paramètres optionnels.

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

• Créer un nouveau compte avec des données utilisateur valides et invalides.
• Vérifier si les détails de l’utilisateur peuvent être mis à jour.
• Vérifier si un nouvel utilisateur peut être enregistré.
• Créer un nouveau compte avec les données de l’utilisateur existant.
• Vérifiez que l’utilisateur peut déposer le montant sur le compte nouvellement créé (et mettre à jour le solde).
• Vérifier que l’utilisateur peut retirer un montant du nouveau compte (après le dépôt et la mise à jour du solde)..
• Dans le cas d’un salaire, le compte est vérifié, le nom de l’entreprise et d’autres détails sont fournis par l’utilisateur..
• Vérifiez si le numéro de compte primaire est fourni dans le cas d’un compte secondaire.
• Vérifier les détails de l’utilisateur fournis dans le cas du compte courant.
• Vérifiez les preuves fournies pour le compte joint en cas de compte joint..
• Vérifiez si vous êtes capable de maintenir un solde nul sur le compte salaire.
• Vérifiez si vous êtes en mesure de 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érifier si l’utilisateur est en mesure de créer un nouveau compte.
• Vérifier si l’utilisateur est capable de se connecter avec un nom d’utilisateur et un mot de passe valides et invalides..
• Vérifier 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 est affiché.
• Vérifiez si l’utilisateur est autorisé à changer le mot de passe..
• Si un utilisateur ou un mot de passe invalide est saisi, un message d’erreur approprié est affiché..
• Les utilisateurs dont le mot de passe n’est pas valide ne doivent pas être autorisés à se connecter..
• Vérifiez qu’après des tentatives répétées 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 capable d’ajouter un bénéficiaire avec des détails valides et invalides.
• Vérifier si l’utilisateur peut supprimer le bénéficiaire.
• Vérifiez que l’utilisateur est en mesure d’effectuer des transactions au profit du 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érifier si l’utilisateur est capable de saisir le montant en nombre décimal.
• Vérifiez si l’utilisateur ne peut pas saisir de nombres négatifs dans le champ du montant.
• Vérifier si l’utilisateur est autorisé à effectuer des transactions avec ou sans solde minimum.
• Vérifier si l’utilisateur peut faire un nouveau RD.
• Vérifiez que le message approprié est affiché en cas de transaction effectuée avec un solde insuffisant..
• Vérifier si une confirmation est demandée à l’utilisateur avant toute transaction..
• Vérifier si un accusé de réception est fourni pour chaque transaction réussie..
• Vérifiez si l’utilisateur peut transférer de l’argent sur 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 temporisation est mise en œuvre.
• vérifier qu’en cas de dépassement du temps de session, l’utilisateur doit se reconnecter.
• vérifiez que le délai d’expiration de la session est respecté 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 abordé la complexité d’une application bancaire et quels sont les les phases typiques des tests de l’application. En outre, nous avons également discuté des tendances actuelles suivies par les industries informatiques, notamment 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 !