Pour garantir la qualité du produit d'information dans les domaines de la médecine, des assurances, des banques et d'autres secteurs, ainsi que d'autres méthodes de test, il est important d'utiliser des tests basés sur les risques. Pour vérification, les zones les plus risquées du logiciel en cours de création sont sélectionnées. Cela nous permet d'anticiper les scénarios négatifs et de mettre en œuvre avec succès les objectifs commerciaux du client.
Dans l'article, nous expliquerons comment nous, chez SimbirSoft, avons travaillé avec les risques (en utilisant le système d'acquisition Internet et d'autres projets à titre d'exemple) et quelles méthodes d'évaluation et de gestion des risques nous utilisons dans les projets clients.
Risques en début de projet
Pour commencer, nous donnons un exemple de notre pratique dans le développement du secteur bancaire.
Proposition du client: se concentrer sur la version web de la banque pour les particuliers.
Le risque que nous avons identifié: une éventuelle perte d'audience due à la faible demande de la version web pour les particuliers, contrairement à la banque client-mobile.
Nos arguments: statistiques des préférences des utilisateurs basées sur les avis et la répartition de l'audience par versions mobile et web.
Conclusions: pour les particuliers, la version mobile est plus pratique, car le téléphone est toujours à portée de main. Les opérations sont rapides, le système d'autorisation vous permet d'accéder à tous les services pratiques. Dans ce cas, un accès rapide à un ensemble limité des fonctions les plus populaires est important.
Pour les personnes morales, l'exhaustivité des fonctions fournies, la possibilité de télécharger, d'imprimer et de travailler avec une grande quantité d'informations sont importantes. Pour cela, la version web est plus pratique.
Notre solution: se concentrer sur la banque mobile client pour les particuliers.
Au début du travail avec un projet, il est important de choisir correctement la stratégie de test. Regardons des exemples de pourquoi il est important et comment le choisir.
La stratégie de test doit répondre aux objectifs commerciaux
Tôt ou tard, toutes les entreprises sont confrontées à la nécessité d'organiser le processus de test et en viennent à comprendre que l'élaboration de sa stratégie est une étape importante dans le développement de logiciels. Parfois - à travers leur propre expérience amère. Il est particulièrement dangereux de sous-estimer le rôle des tests et de la sélection de stratégies dans le développement de projets à grande échelle. Le processus de test doit être sélectionné en fonction des objectifs commerciaux et des spécificités du projet, sinon il ne conduira à des résultats positifs ni dans un mois ni dans un an.
Par exemple, envisagez de tester des applications mobiles et Web pour une banque. Au début du projet, nous avons sélectionné une stratégie basée sur des exigences avec un faible niveau de détail. Nous avons utilisé des listes de contrôle pour réduire le temps de test et soutenir la base de test. Avec la croissance des fonctionnalités, l'ajout d'acquisitions, l'autorisation et la notification par SMS, les systèmes plus complexes, les listes de contrôle ne font plus face à leur tâche. Au fil du temps, de plus en plus de spécialistes QA ont rejoint l'équipe, il a fallu transmettre des informations et coordonner leurs actions. Avec la complication du produit, tout changement peut affecter les fonctions associées, c'est-à-dire que le risque de régression augmente. Le besoin d'automatisation des tests de régression se préparait, nous sommes donc passés aux cas de test.
Conclusion: selon le projet, ses spécificités ou son stade de développement, la stratégie de test évolue.
La stratégie doit être sélectionnée pour les objectifs du projet afin d'assurer la meilleure qualité de produit. Elle répond aux questions «quoi», «où» et «quand» seront testées. À tout moment, vous savez à quel moment vous êtes et où vous viendrez à l'avenir - selon la stratégie.
Un objectif commercial peut être d'assurer la sécurité des données client, ainsi que du logiciel lui-même au stade de la production. La sécurité commence par le processus de développement et se poursuit tout au long de la phase de test.
Par exemple, dans l'un des projets, nous avons créé un environnement sûr pour le développement et les tests, déployé une infrastructure répondant à toutes les exigences et aidé à protéger les données. Nous avons demandé des jetons certifiés et des clés USB basées sur le nom pour que chaque spécialiste QA puisse accéder à l'infrastructure de test. Ainsi, nous avons assuré l'objectif commercial du projet en matière de sécurité logicielle et gardé confidentiels les données client et utilisateur.
En raison de la stratégie de test, l'accent peut être mis sur des aspects vraiment importants pour un projet particulier. Il est logique que la sortie d'un jeu mobile ou d'un système CRM bancaire complexe nécessite différentes approches de test.
Stratégie de test bancaire
Dans notre pratique, chez SimbirSoft, nous avons utilisé toute la gamme des méthodologies de développement, mais les technologies flexibles restent toujours notre priorité. Et même lorsque, pour plusieurs raisons, il n'est pas possible de les utiliser, l'équipe adopte les meilleures pratiques et les applique au quotidien. Les tests deviennent une partie intégrante de l'ensemble du processus et fusionnent dans le flux de travail global. Dans ce cas, il est responsable non seulement de la qualité du produit, mais également de la qualité de l'ensemble du processus de travail.
Quelles technologies utilisons-nous:
- planification et préparation flexibles des versions internes;
- préparation de la user story;
- tenue de rassemblements;
- effectuer des rétrospectives.
En force, la stratégie de test se révèle dans des projets à la logique métier complexe. Par exemple, un logiciel d'aide à l'information des banques, la construction d'un système d'acquisition Internet, une plateforme de trading automatisée. Dans de tels projets, il est important d'appliquer une stratégie de test appropriée, car le prix de certaines erreurs peut entraîner de réelles pertes et nuire considérablement à la réputation de l'entreprise.
De plus, les principaux objectifs des tests - recherche de défauts et vérification de conformité logicielle - peuvent être ajoutés en plus. Par exemple, il est important que les banques mettent rapidement en œuvre les nouvelles exigences de la Banque centrale. Cela signifie que des tests opportuns avec la qualité requise pour les tâches critiques seront ajoutés à l'objectif principal.
Récemment, dans un projet bancaire, nous avons été confrontés à une modification de la loi fédérale - une augmentation du taux de TVA de 18% à 20%. De nombreux travaux préliminaires ont été effectués pour s'adapter au changement de législation, puisque le changement concernait non seulement le remplacement des formulaires, des interfaces, mais aussi la modification de la logique de plusieurs formules de calcul. Il était nécessaire d'assurer un affichage correct sur de nombreuses plateformes. De plus, dans la fonction de paiement différé, il fallait tenir compte de la période de transition avec des taux de 18% et 20%.
Nous allons maintenant parler plus en détail de la manière dont nous élaborons notre stratégie et des raisons pour lesquelles nous choisissons souvent des tests basés sur les risques.
Avantages des tests basés sur les risques
Il existe plusieurs stratégies de test sélectionnées à des fins spécifiques:
- en fonction des besoins;
- méthodique;
- stratégies réactives;
- stratégies de conseil.
Dans le cas de projets avec une logique métier complexe, il est nécessaire de déterminer des exigences strictes dans la conception des systèmes sur lesquels les tests sont basés. Un outil approprié est le test basé sur les exigences.
Un type de stratégie basée sur les exigences est le test basé sur le risque. De plus, les parties des fonctionnalités du système les plus exposées aux risques sont testées en premier. Le risque est une conséquence négative possible d'un système défectueux. La conséquence est un risque en présence de deux composantes, comme l'opportunité et la négativité.
Il existe deux types de risques:
1. Risque produitIl peut être géré et non géré. Dans l'exemple ci-dessus, nous étions confrontés à un risque gérable: croissance rapide et complexité des fonctionnalités, ce qui augmentait la probabilité de régression. Ici, nous avons résolu le problème en ayant une base de test compréhensible et une automatisation ultérieure. Le risque que nous ne pouvons pas affecter est la dépendance des systèmes externes et leur échec dans le processus d'intégration. Ici, nous posons les mesures qui réduiront leur impact sur notre système. Par exemple, utiliser la sauvegarde, gérer des cas exceptionnels, afficher des avertissements pour l'utilisateur.
2. Risque lié au projetPar exemple, sur un projet, nous étions confrontés au fait que le client n'avait pas auparavant travaillé avec une équipe distribuée, et donc le workflow utilisé ne répondait pas aux exigences et créait des problèmes de communication supplémentaires: manque de compréhension, duplication de tâches, exécution de tâches s'excluant mutuellement, etc. Nous nous sommes mis d'accord sur la restructuration et l'amélioration du processus - révisé le flux de travail, présenté tous les membres de l'équipe, organisé des rassemblements, des présentations et des rétrospectives. En conséquence, le travail est allé dans la bonne direction.
L'approche basée sur les risques vous permet de composer un certain nombre de risques, pendant une courte période pour tester les risques avec une priorité élevée et de fournir au client des mesures sur la façon dont ils ont été testés, en montrant le nombre de cas planifiés et terminés et le nombre de défauts.
La mise en œuvre d'une approche basée sur le risque sur un projet se déroule en quatre étapes:
Identification des risques - à ce stade, vous devez identifier les risques et obtenir une liste de ceux-ci.
Évaluation des risques - ici, nous analysons la liste et la classons par priorité.
Atténuation des risques - à ce stade, nous déterminons dans quelle mesure nous testerons les risques.
Gestion des risques - ici, nous décidons comment nous allons continuer à travailler avec eux et à les parcourir, à identifier de nouveaux risques.
Les risques sont identifiés et évalués par un groupe de parties prenantes lors des sessions de brainstorming. L'équipe doit comprendre des analystes commerciaux ou des porteurs de connaissances sur le système provenant du client, des développeurs, du gestionnaire ou du chef de projet, des architectes et des spécialistes de l'assurance qualité. Nous impliquons des spécialistes de la sécurité de l'information, des employés qui travaillent directement avec le système actuel et des analystes commerciaux qui sont plongés dans des processus pour identifier et évaluer les risques.
Considérez l'approche basée sur les risques par l'exemple du test du système d'acquisition Internet.
Travailler avec des risques (sur l'exemple d'un système d'acquisition Internet)
Nous distinguons les exigences suivantes:
D1.Fournissez 1000 connexions simultanées au système par seconde.
D2. Sécurité des transactions.
D3. L'accès à la transaction ne devrait être accessible qu'à la personne effectuant la transaction.
D4. Fournir et soutenir la norme SET (Secure Electronic Transaction).
En tant que risque produit, nous pouvons distinguer:
RP1. Crash du système avec connexions simultanées.
RP2. Utilisation de l'injection SQL lors de la transaction.
RP3. Accès à la transaction de quelqu'un d'autre lors de la modification des paramètres dans l'URL.
RP4. Perte de données lorsque la connexion avec la banque est perdue au moment de la transaction.
RP5. L'utilisation de certificats invalides lors de la fourniture du système SET (Secure Electronic Transaction).
Comme risques organisationnels:
RO1. La chute du système développé en raison de l'inaccessibilité des systèmes externes.
RO2. La présence de cas difficiles à reproduire qui ne peuvent pas être détectés dans un environnement de test.
Ainsi, chaque risque découle logiquement des exigences qui sont dans le système, mais ne s'y limite pas. Les risques complètent les exigences et identifient les cas supplémentaires pouvant survenir lors de l'utilisation du système.
Les risques peuvent être réduits ou compensés en fonction des objectifs du projet et des exigences du système. Il est admis que le risque est couvert par le scénario de test au moins une fois:
1. Pour chaque risque produit, un ensemble de cas de test RP1-RP4 est préparé à la condition que chaque exigence et chaque risque soient couverts par au moins un cas de test. En fonction des objectifs des tests, l'ensemble des cas de test est étendu à un certain niveau de détail.
2. Pour chaque risque organisationnel, une liste d'activités est préparée pour réduire l'impact du risque sur le produit en cours de développement.
Techniques d'évaluation et de gestion des risques
Il existe plusieurs méthodes pour évaluer et gérer les risques: des méthodes légères (PRAM, PRISMA) et plus formelles (FMEA, FTA).
Avec le modèle FMEA, l'équipe de projet identifie tous les processus, composants et modules du système dans lesquels une défaillance ou une erreur du système peut se produire et entraîner une dégradation de la qualité du produit. Lors du brainstorming, les risques du système sont déterminés par trois indicateurs: gravité, priorité, probabilité. Ensuite, le numéro de priorité du risque est calculé pour chaque risque et, en fonction des indicateurs, la profondeur de test est définie.
Avec le modèle FTA, toutes les causes pouvant entraîner des défauts dans les processus métier du système sont déterminées par étapes. L'analyse passe du niveau le plus élevé au niveau le plus bas. La différence entre FMEA et FTA est que la première approche se concentre sur la fonctionnalité du système et la seconde sur les processus métier.
En plus de ces approches formelles et lourdes, il existe des approches plus flexibles et informelles. Par exemple, les méthodes PRAM (analyse pragmatique et gestion des risques) et PRISMA (gestion des risques produits). Ils combinent avec succès et facilement des stratégies basées sur les risques et les exigences. Fondamentalement, ces approches utilisent des spécifications d'exigences en entrée, mais les parties prenantes peuvent également être impliquées.
Les méthodes légères d'analyse des risques sont très similaires aux méthodes formelles. Ils se concentrent sur les risques techniques ou commerciaux, en pesant la probabilité d'occurrence du risque et les facteurs affectant cette probabilité.
Cependant, les deux seuls facteurs utilisés par ces méthodes sont la probabilité du risque et son impact. De plus, ces approches utilisent des jugements qualitatifs et des échelles simplifiés pour prendre des décisions.
Nos équipes utilisent des méthodes flexibles et légères et adaptent les approches PRAM et PRISMA à leurs objectifs.
Comment nous travaillons avec les tests basés sur les risques
Par exemple, sur l'un des projets, nous identifions les risques de projet et de produit qui peuvent fonctionner. Pour ce faire, les analystes, les développeurs et l'AQ participent à l'analyse - un représentant de l'équipe.
Un tableau des risques est formé avec les produits. Ils déterminent l'évaluation de la probabilité de survenance d'un risque et de son impact possible sur le système sur une échelle de cinq points. Dans le tableau 1 - l'influence la plus forte, 5 - la plus faible. Également pour la probabilité 1 - probabilité élevée, 5 - probabilité faible.
Comment nous continuons à travailler avec les risques produits
De plus, pour chacun d'eux, la couverture des risques du produit est tracée avec des cas de test.
Nous sélectionnons les contrôles suivants:
TC1. Vérification de la charge avec plus de 1000 connexions au système
TC2. Test de charge avec 1000 connexions système
TC3. Entrez l'injection SQL pendant la transaction
TC4. Entrez l'injection SQL sur la page de transaction réussie, en remplaçant d'autres données
TC5. Saisie de scripts XSS (Cross-Site Scripting) dans les champs disponibles pour la saisie lors d'une transaction
TC6. Simulation d'une connexion Internet déconnectée lors d'une transaction
TC7. Quitter une session de transaction à l'étape de vérification
TC8. Validation des certificats expirés lors de la transaction
Ainsi, les contrôles de priorité sont TC2, TC4, TC5.
TC6 et TC8 ont un impact élevé, mais moins de probabilité, donc la priorité de vérification pour eux est plus faible, mais des vérifications sont également requises.
TC7 ne s'applique à aucune des exigences, mais étend le test pour un scénario négatif, ce qui est possible avec un fonctionnement stable du système.
Comment nous continuons à travailler avec les risques du projet
Nous déterminons également les actions pour les risques du projet, par lesquelles nous attribuons des mesures et des décisions supplémentaires.
Sur le risque «RO2. La présence de cas difficiles à reproduire qui ne peuvent pas être détectés dans l'environnement de test », vous pouvez prendre les mesures suivantes:
- Préparer un stand de pré-production, le plus proche possible de l'environnement d'application réel, en liaison avec tous les systèmes externes;
- écrire des scripts de test de bout en bout qui traversent tous les systèmes adjacents et fournissent une vérification des transactions;
- après avoir effectué toutes les vérifications de priorité, utilisez les techniques de devinette d'erreur selon les exigences de base du système et des scripts pour des vérifications supplémentaires dans le rôle d'un «pirate de système».
Plan d'urgence
Il est important d'avoir un plan d'action au cas où l'un des risques du produit ou du projet fonctionne. Parfois, cela peut sauver la configuration d'un système de sauvegarde du projet. Il n'est pas toujours possible de réduire le risque à un niveau minimum, mais il devrait être possible de réduire au moins ses conséquences. Notre article
«Christmas Story» était sur ce sujet: comment un risque peut fonctionner, dont la probabilité tend vers zéro.
Par exemple, nous devons éliminer complètement la perte de données lors d'une transaction, mais considérer tous les cas trop laborieux. Par conséquent, vous devez avoir des moyens de gérer de tels cas. L'une des options de sécurité est le développement d'une journalisation plus détaillée. Cela fournira un point de restauration permanent à l'action précédente si quelque chose s'est mal passé pendant la transaction.
Conclusion
Les tests basés sur les risques vous permettent de couvrir les zones les plus risquées avec des cas de test, réduisant ainsi leur impact et leur probabilité de déclenchement. Il s'agit de la stratégie la plus gagnante pour les systèmes à logique métier complexe et à coût d'erreur élevé. La solution convient au secteur bancaire, aux compagnies d'assurance, aux systèmes CRM internes complexes d'un profil médical. Avec une approche basée sur le risque, nous travaillons également avec les risques du projet, ce qui améliore le processus global de test et de gestion de projet.