Le guide ultime des tests basés sur les risques: la gestion des risques dans les tests logiciels

ultimate guide risk based testing

Le guide ultime des tests fondés sur les risques, de la gestion des risques et de son approche avec des exemples:

Qu'est-ce que le test basé sur les risques?

Les tests basés sur les risques consistent à effectuer des tests ou à concevoir et exécuter les scénarios, de sorte que les principaux risques commerciaux qui auront un impact négatif sur l'entreprise tels qu'identifiés par le client sont découverts dans leur produit ou fonctionnalité au début du cycle de vie et sont atténuée par la mise en œuvre de mesures d'atténuation.

=> Cliquez ici pour une série complète de didacticiels sur le plan de test

L'impact négatif peut inclure un impact sur les coûts, un client insatisfait, une mauvaise expérience utilisateur et même la perte de clients.

En d'autres termes, l'approche RBT consiste à s'assurer que les tests sont effectués de telle manière que même si un utilisateur trouve un bug dans la production, cela ne l'empêche pas d'utiliser le logiciel ou n'affecte pas sérieusement l'entreprise.

RBT effectue des tests en fonction des risques produits. RBT consiste à se renseigner bien à l'avance, car quel est le risque de défaillance d'une fonctionnalité ou d'une fonctionnalité particulière dans la production et son impact sur l'entreprise en termes de coût et autres dommages en utilisant une technique de hiérarchisation des cas de test.

Par conséquent, les tests basés sur les risques utilisent le principe de prioriser les tests des caractéristiques, modules et fonctionnalités d'un produit ou logiciel. La hiérarchisation est basée sur le risque de la probabilité de défaillance de cette fonctionnalité ou fonctionnalité en production et son impact sur les clients.

Ce que vous apprendrez:

• Les tests basés sur les risques et leur pertinence pour Agile et DevOps
  • Approche de test basée sur les risques
    • Quand utilisons-nous l'approche RBT?
    • Exemple d'approche RBT
  • Façons de réaliser une analyse des risques
  • Procédure d'analyse des risques
  • Méthodologie d'analyse des risques
    • Étape # 1) Utilisation d'une grille 3X3
    • Étape # 2) Probabilité et impact de l'échec
    • Étape # 3) Test de la grille de priorité
    • Étape # 4) Détails du test
  • Comment RBT est-il pertinent pour Agile et DevOps?
  • Avantages de l'approche de test basée sur les risques
• Gestion des risques pendant la planification des tests
  • Processus de gestion des risques
    • # 1) Identification des risques
    • # 2) Évaluation des risques / analyse de l'impact des risques
    • # 3) Atténuation des risques
  • Conclusion
• Gestion des risques lors de la phase d'exécution des tests (avec exemple)
  • Gestion des risques - avec un accent sur l'AUT
  • Comment se déroule le test des bases de risque?
  • Conclusion
  • lecture recommandée

Les tests basés sur les risques et leur pertinence pour Agile et DevOps

Trois cents heures consacrées au développement de logiciels peuvent être rendues inutiles en seulement 30 secondes avec un seul défaut identifié en production.

Ceci, à son tour, peut ruiner l'objectif de l'ensemble du produit sans autre option que de simplement le retirer du marché. Et c’est l’importance et la nécessité des «tests de qualité».

Avec la croissance rapide de la technologie, le logiciel est hébergé sur le cloud prenant en charge plusieurs systèmes d'exploitation, plusieurs plates-formes, des infrastructures informatiques complexes, etc., les utilisateurs finaux sont de plus en plus pointilleux sur les fonctionnalités, les options et ne font jamais de compromis pour la satisfaction du client. .

De nos jours, la «qualité» devient un facteur crucial dans la livraison de logiciels, où des améliorations continues se produisent pour améliorer la qualité afin de satisfaire les clients.

Nous remarquons souvent que c'est un problème commun pour presque tous les testeurs d'être sous une pression énorme que leur fenêtre de test soit comprimée et que généralement la construction leur soit remise pour test à la dernière minute. Ils n'ont pas assez de temps et de ressources pour exécuter tous les tests qu'ils ont conçus et la couverture de l'automatisation n'est pas toujours à 100% et elle a ses propres défis.

Le délai de livraison ne peut pas être manqué et en même temps la qualité ne peut pas être compromise. Quel que soit le plan B, ajouter des ressources de test supplémentaires en se retirant des autres équipes ne fonctionne pas, le plan C, arrêter de faire toutes les autres activités et détourner l'effort vers cela seul, n'aide pas vraiment. Cependant, une grande partie de l'ajout de ressources de test, à la fin, ne fonctionne pas.

Il n'y a pas d'autre option que d'exécuter des tests limités et importants dans le temps et les ressources disponibles.

Alors, comment décider quel test est important à ce stade? Tout ce qu'un testeur considère comme important peut ne pas l'être vraiment pour les clients. Du point de vue de qui l'importance de la fonctionnalité ou d'une fonctionnalité est-elle décidée? Qui décidera quels sont les tests importants? Et beaucoup d'autres questions continuent de se poser.

Afin de répondre à toutes ces questions et de gérer efficacement la situation ci-dessus, une approche de test appelée «Tests basés sur les risques» , brièvement appelé «RBT» , a vu le jour, où l’équipe a clairement planifié et identifié les scénarios de test sur la base des critères «Risque de projet».

Bien que l'équipe QA ait une image claire des tests importants, RBT est une méthode éprouvée pour identifier les tests cruciaux et importants du point de vue du client et de l'entreprise à travers un 'Analyse de risque' procédure .

Ainsi, maintenant par rapport à la manière traditionnelle d'identifier simplement les défauts du logiciel, l'approche et l'objectif d'AQ ont changé avec le temps en raison du changement de technologie, de l'augmentation de la concurrence sur le marché pour publier un logiciel de qualité, de l'introduction de «Automatisez tout», et en totalité l'introduction de la pratique Agile et DevOps de livraison du logiciel sur une période de quelques heures.

Par conséquent, la tendance actuelle du «principe de test» n’est pas simplement d’identifier les défauts, mais aussi de:

#1) Concentrez-vous sur la zone du produit où il y a un impact élevé sur l'entreprise en raison d'une défaillance ou d'une forte probabilité de défaillance dans la production.

#deux) En se concentrant sur identifier les défauts tôt et permettant à une équipe de le réparer le plus tôt possible et permettant ainsi au logiciel / produit ou fonctionnalité de «Fail Fast».

# 3) L'aspect le plus important du service de l'équipe QA est maintenant de se concentrer sur le client en apportant de la valeur au client en mettant davantage l'accent sur «Expérience client de bout en bout».

Approche de test basée sur les risques

C'est toujours comme se préparer à un examen, qu'on ne peut pas dire que les tests suffisent et qu'il n'y a plus de défauts dans le logiciel, même s'ils conçoivent et exécutent un grand nombre de tests.

Il y a un moment où la stabilité du logiciel ne sera pas doublement assurée en augmentant le nombre de cas de test uniquement. À ce stade, il ne s'agit pas seulement de se concentrer sur le nombre de tests, mais sur ce que le client attend réellement de la sortie.

Par conséquent, il est essentiel de trouver un équilibre dans l'optimisation des tests afin d'obtenir le maximum d'avantages avec l'effort raisonnable de tests. Et cela est plus important lorsque les délais de test sont très serrés et que suffisamment de ressources ne sont pas disponibles pour effectuer des tests suffisants.

Ainsi, dans ce cas, l'approche RBT joue un rôle clé dans l'optimisation de l'effort d'assurance qualité et la maximisation des avantages des tests avec un risque commercial minimum.

Donc, si nous nous concentrons sur l'aspect ci-dessus, alors le travail d'un QA sera très soulagé. Ils n'ont pas à brûler leurs week-ends au bureau, testant continuellement le logiciel et s'inquiétant de tous les défauts S4 (gravité 4) et P4 (priorité 4) qui résultent des tests.

Eh bien, 4 est considéré comme la priorité et la gravité les plus faibles des défauts de test. Ils peuvent mieux investir leur temps dans d'autres aspects utiles du projet.

Pour résumer les principaux moteurs de l’approche des «tests basés sur les risques»:

• Pour permettre de tester «ce que veulent les clients» d’un point de vue commercial.
• Pour respecter le calendrier avec la qualité attendue.
• Pour optimiser l'effort d'AQ.

Quand utilisons-nous l'approche RBT?

Ceci est utilisé dans les scénarios ci-dessous:

• L'approche RBT peut être utilisée chaque fois qu'il y a une limitation ou une contrainte sur le temps, le coût et les ressources d'un projet et chaque fois qu'il est nécessaire d'optimiser les ressources.
• L'approche RBT est utilisée lorsque le programme est plus complexe et adapte la nouvelle technologie et implique donc de nombreux défis.
• Lorsque le programme est un projet de R&D et qu'il est du premier type et qu'il existe un certain nombre d'inconnues et de risques dans le projet.

Exemple d'approche RBT

Plusieurs approches d'analyse basées sur les risques sont utilisées dans l'industrie informatique pour surmonter les risques encourus par la production et son impact.

Voici une de ces approches:

Cette approche de RBT comprend l'identification des «fonctionnalités vitales ou caractéristiques clés» du produit et l'évaluation des risques auxquels chacune de ces fonctionnalités est exposée dans la production et la mise en œuvre de mesures d'atténuation appropriées en place pour réduire ou atténuer le risque.

Par conséquent, l'approche RBT comprend le test des fonctionnalités qui ont la probabilité de défaillance et l'impact le plus élevé sur l'entreprise. Les types de pannes peuvent être opérationnels ou commerciaux, techniques, externes, etc.

Façons de réaliser une analyse des risques

Il n'y a pas de processus ou de modèle standard défini en tant que tel pour effectuer l'analyse des risques dans les tests logiciels pour chaque fonctionnalité d'un produit. Diverses organisations utilisent leur propre approche des méthodes d'analyse des risques.

L'analyse des risques peut être effectuée sur divers éléments du projet pour identifier les risques et mettre en œuvre une approche RBT pour l'analyse. Ces éléments comprennent,

• Fonctionnalités
• Fonctionnalités
• Histoires d'utilisateurs
• Conditions
• Cas d'utilisation
• Cas de test

Dans ce cas, concentrons-nous uniquement sur les cas de test pour comprendre l'implémentation de l'approche de test basé sur les risques.

Procédure d'analyse des risques

L'analyse des risques comprend la participation des parties prenantes concernées du programme à la fois Équipe technique et équipe commerciale » , qui comprend: le propriétaire du produit, les chefs de produit, les analystes commerciaux, les architectes, les testeurs et les représentants des clients.

Des séances de brainstorming impliquant ces parties prenantes seraient organisées pour mener la discussion afin d'identifier l'importance de chaque caractéristique d'un produit et de les hiérarchiser en fonction du risque de défaillance et de son impact sur les utilisateurs finaux en production.

Divers «documents de projet» tels que le document d'exigences, les documents de spécifications techniques, les documents d'architecture et de conception, le document de processus d'affaires, le document de cas d'utilisation, etc., deviendront les données d'entrée pour la session de brainstorming.

Les connaissances des parties prenantes sur le produit et le produit existant sur le marché seront également un facteur d’entrée pour la discussion.

Peu d'autres sources d'intrants peuvent également inclure,

• Pour recueillir des informations sur les fonctionnalités les plus utilisées.
• Contributions de la consultation d'un expert du domaine.
• Données de la version précédente du produit ou d'un produit similaire sur le marché.

Pendant le réflexion session, les risques relatifs à chacune de ces fonctionnalités sont identifiés. Les types de risques peuvent être une opération, technique ou commerciale. Les tests et les scénarios qui leur sont associés sont pondérés et les valeurs de risque sont évaluées en fonction de la probabilité d'occurrence du risque et de son impact.

La «probabilité d’occurrence du risque» peut être due à:

• Mauvaise compréhension de la fonctionnalité par l'équipe de développement produit.
• Architecture et conception incorrectes.
• Temps de conception insuffisant.
• Incompétence de l'équipe.
• Ressources inadéquates - personnes, outils et technologie.

L ’« impact du risque »est l’effet d’une défaillance sur les utilisateurs et l’entreprise si elle se produit. L'impact pourrait être,

• Impact sur les coûts, entraînant une perte.
• Impact commercial entraînant une perte d'activité ou de part de marché, poursuites judiciaires, perte de licence.
• Impact sur la qualité, entraînant une sortie de produit de qualité inférieure ou incompétente.
• Mauvaise expérience utilisateur, entraînant une insatisfaction et la perte d'un client.

Le domaine d'intervention de l'évaluation du risque d'une fonctionnalité ou d'un produit peut être:

• Domaine d'activité Criticité de la fonctionnalité.
• Fonctionnalités les plus utilisées et fonctionnalités importantes.
• Zones sujettes aux défauts
• Fonctionnalité ayant l'impact sur la sûreté et la sécurité.
• Domaine de la conception et de l'architecture complexes.
• Modifications apportées à partir des versions précédentes.

Méthodologie d'analyse des risques

Voyons maintenant en détail la «méthodologie de test basée sur les risques».

L'approche de test basée sur les risques utilise RISK comme critère à toutes les phases de test du cycle de test, c'est-à-dire, planification des tests , conception de tests, implémentation de tests, exécution de test et rapport de test. Idéalement, on peut concevoir un grand nombre de combinaisons de scénarios de test possibles.

Ainsi, l'approche RBT comprend un classement des tests en fonction de la gravité des risques pour identifier la zone de défaillance la plus défectueuse ou la plus risquée, ce qui a un impact important sur l'entreprise.

Le principal objectif de l'analyse des risques est de faire la distinction entre les 'Haute valeur' des éléments tels que les caractéristiques du produit, les fonctionnalités, les exigences, Histoires d'utilisateurs , et des cas de test, et « Faible valeur » et donc plus tard pour se concentrer davantage sur les cas de test de «valeur élevée», en se concentrant moins sur les cas de test de «faible valeur». Il s'agit de la première étape de l'analyse des risques avant de commencer les tests basés sur les risques.

La tâche principale de catégorisation ou de regroupement des cas de test en valeur élevée et faible et l'attribution de la valeur de priorité à chacun de ces cas de test comprend les étapes suivantes:

Étape # 1) Utilisation d'une grille 3X3

L'analyse des risques est effectuée à l'aide d'une grille 3X3, où chaque fonctionnalité, non-fonctionnalité et ses cas de test associés sont évalués par une équipe de parties prenantes pour son 'Probabilitéde l'échec »et« Impact de l'échec ».

La probabilité de défaillance de chaque fonctionnalité de la production est généralement consultée par un groupe d ’« experts techniques »et est classée comme« susceptible de tomber en panne, assez probable et improbable »le long de l’axe vertical de la grille.

meilleur éditeur de texte pour les fenêtres python

De même, «l'impact de l'échec» de ces caractéristiques et fonctionnalités en production est ressenti par le client final, s'il n'est pas testé est évalué par un groupe de ' Business Specialists »et sont classés dans les catégories« Mineure, Visible et Interruption »le long de l'axe horizontal de la grille.

Étape # 2) Probabilité et impact de l'échec

Tous les cas de test sont positionnés dans les quadrants de la grille 3 X 3 sur la base des valeurs identifiées de la probabilité de défaillance et de l'impact de la défaillance qui sont représentées sous forme de points dans l'image ci-dessous.

De toute évidence, une probabilité élevée de défaillance et un impact élevé de défaillance (interruption) sont regroupés dans le coin supérieur droit de la grille, ce qui est d'une grande importance et il est donc identifié que les tests de `` haute valeur '' et les tests de `` faible valeur '' sont regroupés dans le coin inférieur gauche qui est de moindre ou pas d'importance pour le client, où une attention mineure peut être accordée à ces fonctionnalités ou cas de test.

Étape # 3) Test de la grille de priorité

Sur la base du positionnement ci-dessus des cas de test dans la grille, les tests sont classés par ordre de priorité et étiquetés avec les priorités 1, 2, 3, 4 et 5 et sont marqués par rapport à chacun d'eux. Les tests les plus importants sont positionnés dans un 1^stLes grilles qui ont la priorité 1 et les moins importantes de la même manière sont classées 2, 3, 4 et 5.

Enfin, tous les cas de test sont triés en fonction de leurs numéros de priorité et sont sélectionnés pour exécution dans l'ordre de priorité. Ceux de haute priorité sont sélectionnés en premier pour être exécutés et ceux de faible priorité sont exécutés plus tard ou dé-cadrés.

Étape # 4) Détails du test

L'étape suivante consiste à décider du niveau de détails des tests pour la portée définie des tests. La profondeur de la portée du test peut être décidée en fonction du classement ci-dessus selon la grille ci-dessous.

Les tests de haute priorité classés 1 sont testés de manière «plus approfondie» et, par conséquent, des experts sont déployés pour tester ces fonctionnalités de haute criticité et les scénarios de test associés. De même, les cas de test avec les priorités 2, 3 et 4. Il est possible de décider de retirer le champ d'application des fonctionnalités et des tests de priorité 5 en fonction du temps et des ressources disponibles.

Par conséquent, l'approche de niveau de détail des tests consistant à prioriser les fonctionnalités et ses cas de test aide non seulement les testeurs à identifier les `` tests de haute valeur '', mais les guide également pour décider de leur `` niveau de détail des tests '' en fonction de ces classements de priorité et les aide à effectuer de meilleurs tests et réduit les coûts de test grâce à un processus d'optimisation.

Comment RBT est-il pertinent pour Agile et DevOps?

Maintenant, après avoir compris l'approche des tests basés sur les risques consistant à effectuer les tests en fonction de la hiérarchisation des tests en fonction du `` risque d'échec '' d'une fonctionnalité particulière et de son `` impact sur le client '' en direct, on soulèverait évidemment la question de la pertinence de l'approche des tests basés sur les risques dans les pratiques Agile et DevOps.

«Automatiser tout», «Tout tester», «Tester en continu», «Tester à plusieurs reprises» sont les concepts clés de ces pratiques.

Chaque fois, lorsqu'il y a un changement dans le code ou qu'il y a une version, tous les tests conçus sont exécutés via le système automatisé Intégration continue (CI) / Livraison continue (CD) pipeline rapidement et à plusieurs reprises, indépendamment de leur hiérarchisation.

Alors, quelle est la relation entre RBT et DevOps? Où RBT s'intégrerait-il et deviendrait pertinent dans Agile et DevOps ???

#1) Oui, comme je l'ai dit plus tôt, ce n'est pas que chaque industrie et chaque produit ont une couverture d'automatisation à 100% pour leurs exécutions de tests. Ainsi, si l'équipe doit faire le choix de la hiérarchisation de l'exécution des tests à partir du choix des cas de test manuels et souhaite économiser l'énergie et les efforts des ressources de test vers d'autres activités, alors RBT est le meilleur choix.

L'approche basée sur les risques est également un meilleur choix pour exécuter des tests automatisés avec des tests hautement prioritaires et des tests au plus tôt.

#deux) L'équipe d'AQ peut adopter l'approche RBT plus efficacement pendant l'analyse des exigences en analysant les exigences et en fournissant un rapport préalable sur les risques probables des produits et des fonctionnalités afin que des mesures appropriées puissent être prises de manière proactive par l'équipe du programme pour les atténuer.

# 3) L'approche RBT peut être utilisée efficacement dans la conception des cas de test et des scénarios basés sur un risque élevé afin que davantage d'attention puisse être accordée aux fonctionnalités et fonctionnalités à haut risque.

# 4) L’identification des zones «à haut risque» permet à l’équipe d’assurance qualité de concentrer ses efforts de test sur ces zones pour tester de manière «plus approfondie» à l’aide de «testeurs hautement qualifiés».

# 5) `` Fail Fast '', comme nous le savons tous, est le concept `` Agile '' et `` DevOps '', pour lesquels l'approche RBT aide à identifier les zones `` à haut risque '' dans le logiciel, à identifier les défauts à un stade précoce et à leur permettre d'échouer rapidement et d'échouer d'abord et laissez l'équipe le réparer.

# 6) L’objectif ultime d’Agile / DevOps est la «concentration sur le client» et, par conséquent, l’approche RBT permet à l’assurance qualité de se concentrer sur l’expérience client plutôt que sur la recherche de défauts.

Avantages de l'approche de test basée sur les risques

Nous avons déjà compris le but et l'utilisation de l'approche RBT pour analyser les exigences, concevoir et exécuter les scénarios de test. La RBT présente plusieurs avantages.

Nous pouvons consolider et lister les avantages des tests basés sur les risques comme:

• Aide à une utilisation plus efficace et optimisée des ressources de test.
• Aide à faciliter le travail d'AQ, les tests, la conception et le développement de tests et les activités de préparation des tests en hiérarchisant.
• Aide à mieux gérer les ressources d'AQ en allouant les ressources clés aux domaines prioritaires.
• Cela aide à l'utilisation efficace des ressources et détourne leur temps et leur énergie sur de meilleures choses dans le projet.
• Aide l'équipe d'assurance qualité à planifier les efforts de test en fonction de l'évaluation des risques et de l'identification des zones volatiles et à haut risque.
• Il aide l'équipe à optimiser les tests à réaliser en fonction de l'importance et donc à dé-périmètre des tests de faible valeur en accord avec les parties prenantes.
• Dans l'ensemble, il contribue à la réduction des coûts grâce à des activités de test optimisées et réduites.
• L’approche RBT permet à l’équipe d’assurance qualité de tester d’abord les zones à haut risque et permet au produit «d’échouer rapidement» et de se réparer rapidement.
• L’approche RBT contribue à clarifier les Couverture de test' et la «portée du test» à l’ensemble du groupe de parties prenantes.
• L'équipe peut se concentrer davantage sur les zones à haut risque et moins se concentrer sur la zone à faible risque.
• RBT permet à l'équipe de décider longtemps à l'avance de la mise en œuvre du moyen le plus efficace d'atténuation des risques liés au produit.
• RBT aide à éviter les effets de la mise en œuvre inappropriée des mesures d'atténuation.
• Les tests basés sur les risques permettent à l'équipe de prendre les mesures appropriées pour atténuer ou planifier les contingences ou pour positionner toute solution de contournement pour surmonter l'échec ou réduire son impact si le risque se produit dans Live.
• RBT aide à minimiser le risque résiduel dans la libération.
• Il aide à atteindre la «qualité améliorée» grâce à des défauts moins coûteux dans la production.
• Aide en fin de compte à «une expérience client améliorée» et à un «client satisfait».

Ensuite, nous apprendrons à gérer les risques lors des phases de planification des tests et d'exécution des tests du cycle de vie des tests logiciels.

Gestion des risques pendant la planification des tests

Comment gérer les risques pendant la phase de planification des tests:

java questions et réponses d'entretien de base

La vie est pleine de risques, tout comme un projet logiciel. Tout peut mal tourner à tout moment. Nous sommes toujours sur nos gardes pour arranger les choses - mais qu'en est-il de nous assurer que rien ne va pas et que lorsque nous savons exactement quoi faire? Entrez dans la gestion des risques - il s'agit d'une partie d'un projet de test logiciel qui nous prépare à prévenir, comprendre, détecter et surmonter les risques.

Un risque est simplement un problème susceptible de se produire et, lorsqu'il survient, il entraînera une perte.

La perte peut être n'importe quoi - argent, temps, effort ou compromis de qualité. La perte n'est jamais bonne. Quel que soit le tour que nous lui donnons, ce n’est pas positif et ne le sera jamais. Par conséquent Gestion des risques fait partie intégrante des projets logiciels pour nous assurer de gérer les risques et de prévenir / réduire les pertes.

Tests basés sur les risques : Puisque nous sommes une communauté d'AQ, restons spécifiques aux risques et aux processus qui y sont liés dans notre monde d'AQ exclusivement. Les risques sont évalués et gérés approximativement en 2 phases de notre Cycle de vie des tests logiciels . Le STLC peut être classé en 3 phases: planification des tests, conception des tests et exécution des tests.

Le processus de gestion des risques se déroule deux fois, pendant:

1. Planification des tests
2. Conception de cas de test (fin) ou parfois en phase d'exécution de test

Il est obligatoire dans le cas 1, mais dans le cas 2, il s’agit davantage d’une situation «fondée sur les besoins».

Série d'articles en deux parties:

Même si le processus sous-jacent est le même, le types de risques abordés dans ces deux domaines sont complètement différents. Afin de leur rendre justice individuellement, nous allons les traiter différemment en une série en deux parties.

Cette section portera sur 'Gestion des risques pendant la planification des tests».

Processus de gestion des risques

Le processus générique de gestion des risques comporte 3 étapes importantes:

1. Identification des risques
2. Analyse de l'impact des risques
3. Atténuation des risques

Risques de test et exemples d'atténuation:

# 1) Identification des risques

Comme on dit, la première étape pour résoudre un problème est de l'identifier. Cette étape consiste à faire une liste de tout ce qui pourrait potentiellement survenir et perturber le flux normal des événements.

Le principal résultat de cette étape est une liste de risques.

Cette étape de test basée sur les risques est généralement dirigée par le responsable / responsable / représentant QA. Cependant, le responsable seul ne sera pas en mesure de fournir la liste complète - l’apport de toute l’équipe d’assurance qualité a un impact énorme. Nous pouvons dire qu'il s'agit d'une activité collective dirigée par le chef de l'assurance qualité.

De plus, les risques identifiés lors de la phase de planification des tests ont une orientation plus `` managériale '' - ce qui signifie que nous allons examiner tout ce qui pourrait avoir un impact sur le calendrier, les efforts, le budget, les changements d'infrastructure du projet d'AQ, etc. pas l'AUT, mais la manière dont la phase d'AQ se déroulera.

Risques lors de la planification des tests: exemples de tests basés sur les risques

Voici un exemple de liste de risques qui peuvent être répertoriés pendant la phase de planification des tests. Veuillez noter que l'AUT et ses fonctionnalités ne sont pas au centre ici.

1. Le calendrier des tests est serré. Si le début du test est retardé en raison de tâches de conception, le test ne peut pas être prolongé au-delà de la date de début prévue de l'UAT.
2. Ressources insuffisantes, intégration trop tardive des ressources (le processus prend environ 15 jours).
3. Les défauts se trouvent à un stade tardif du cycle ou à un cycle tardif; Les défauts découverts tardivement sont très probablement dus à des spécifications peu claires et prennent du temps à résoudre.
4. Portée non définie complètement définie
5. Catastrophes naturelles
6. Non-disponibilité d'indépendant Environnement de test et accessibilité
7. Test retardé en raison de nouveaux problèmes

À ce stade, vous pouvez choisir d'être aussi minutieux que vous le souhaitez, en fonction du temps disponible.

Une fois que tous les risques sont répertoriés, nous progressons vers l'évaluation des risques / l'analyse de l'impact des risques.

# 2) Évaluation des risques / analyse de l'impact des risques

Votre analyse des risques est-elle quelque chose comme ça? :)

Analyse des risques dans les tests logiciels : Tous les risques sont quantifiés et hiérarchisés dans cette étape. La probabilité (la probabilité d'occurrence) et l'impact (montant de la perte qu'il causerait lorsque ce risque se matérialiserait) de chaque risque sont systématiquement déterminés.

Élevé - moyen-faible , des valeurs sont attribuées à la fois à la probabilité et à l'impact de chaque risque. Les risques avec une probabilité «élevée» et un impact «élevé» sont d'abord pris en charge, puis l'ordre suit.

Tableau d'analyse de l'impact des risques:

Après ces étapes, le tableau d'analyse de l'impact des risques pour les risques énumérés ci-dessus ressemblerait à ceci (toutes les valeurs sont hypothétiques et uniquement à des fins de compréhension):

# 3) Atténuation des risques

La dernière étape de ce processus de test basé sur les risques (RBT) consiste à trouver des solutions pour planifier comment gérer chacune de ces situations. Ces plans peuvent différer d'une entreprise à l'autre, d'un projet à l'autre et même d'une personne à l'autre.

Techniques d'atténuation des risques:

Voici un exemple de ce en quoi le tableau des risques se transforme lorsque cette phase est terminée:

Quelques points à noter:

1. Plus tôt la gestion des risques commence dans une phase de planification de projet d'AQ, mieux c'est.
2. Sur les 3 étapes, L'identification des risques est la plus importante . Si quelque chose n'est pas répertorié et pris en compte pour les étapes suivantes, le risque n'est pas géré.
3. Essayez de trouver un calendrier idéal pour cette activité. Souvenez-vous que trop de planification laisse trop peu de temps pour faire.
4. De plus, après le processus de gestion des risques, si une nouvelle situation se présente, le plan de gestion des risques peut être modifié ou mis à jour pour refléter la situation la plus actuelle.
5. Données historiques peut être très utile pour la réussite de ce processus.

Conclusion

Cela nous amène à la fin de la gestion des risques dans la phase de planification des tests. Même si les étapes et principes sous-jacents sont similaires, le processus de gestion des risques est plus concentré vers l'AUT lorsqu'il se déroule dans la phase de conception / exécution des tests.

Dans notre prochaine section, nous couvrirons - Gestion des risques dans la phase d'exécution des tests.

Gestion des risques lors de la phase d'exécution des tests (avec exemple)

Dans notre parcours vers la compréhension du processus de gestion des risques, nous avons expliqué comment il se déroule exclusivement dans le Phase de planification des tests des tests basés sur les risques . Nous avons également compris le processus générique qui implique - l'identification des risques, l'évaluation des risques et le plan d'atténuation des risques.

Comment gérer les risques lors de la conception des tests ou lors de la phase d'exécution des tests:

Il existe une autre forme de Gestion des risques (également parfois appelé, Tests basés sur les risques ) qui se produit pendant la phase de conception du test ou d'exécution du test, selon la situation. Maintenant, de quelle situation parlons-nous? Essayons de comprendre cela d'abord.

Nous savons tous que notre travail de test est réactif. Aucune exigence (ni champ d'application défini), nous ne pouvons pas effectuer une analyse de faisabilité et rédiger des scénarios de test ou un plan d'activités de test.

De même, lorsque le code n'est pas prêt, nous n'avons rien à tester, quelle que soit la quantité de travail de préparation que nous aurions pu être prêt en termes de cas de test, de données de test, etc. De plus, le test est la seule étape qui reste avant que le produit ne disparaisse. habitent.

Gestion des risques - avec un accent sur l'AUT

Comprenons mieux cela avec un exemple:

Si les tests devaient commencer à ladite date, le 1er janvier^stet a dû continuer jusqu'au 14 janvier^e- lorsque le test est terminé, la date de mise en service du produit est généralement fixée immédiatement. Disons le 15 janvier^epar souci de simplicité. Maintenant, dans un monde parfait, les choses se dérouleraient exactement comme prévu. Mais nous connaissons tous la réalité.

Dans ce cas, supposons que pour une raison quelconque, les tests n'ont commencé que le 7 janvier^e, ce qui signifie que nous avons perdu la moitié de notre temps de test. Mais nous avons besoin de 14 jours pour tester le produit à fond. Nous pourrions toutefois reporter la date de mise en service de 7 jours plus loin; ce n'est généralement pas une option. Parce que le produit est promis d'arriver sur le marché à une certaine date et que tout retard n'est pas bon pour l'entreprise.

Donc, généralement, nous, les équipes de test, devons absorber les retards, compenser d'une manière ou d'une autre, travailler avec le temps disponible et nous assurer que le produit est bien testé. Un travail difficile, n'est-ce pas?

C'est là que le processus de gestion des risques est à nouveau utilisé.

• Maintenant si les retards sont anticipés à l'avance avant même le début des tests, le processus se déroule dans la phase de conception des tests.
• Si des retards se produisent pendant un Phase d'exécution du test qui a démarré normalement - le processus est suivi pendant la phase d'exécution du test.
• Les étapes et la méthode sont les mêmes quelle que soit l'étape.

Quel est le processus?

La gestion des risques a lieu pour déterminer les domaines de l'AUT (Application Under Test) qui nécessitent une attention maximale. Ce sont généralement les domaines fonctionnels (modules ou composants) qui sont essentiels au succès du produit final et qui sont les plus susceptibles de tomber en panne.

Lire aussi=> L'analyse des modes de défaillance et des effets (AMDEC) est une technique de gestion des risques

Qui le fait?

Puisqu'il s'agit de l'AUT, la connaissance à ce sujet n'est pas seulement avec le QA mais avec toutes les autres équipes - Dev, BA, Client, équipes de gestion de projet, etc. Il s'agit donc d'un effort collectif, porté par l'équipe de test.

Comment se déroule le test des bases de risque?

Étape 1) Identification des risques

Identifiez tous les domaines fonctionnels de l'AUT. Cela comprendra simplement la création d'une liste.

Étape 2) L'évaluation des risques

Tous les risques sont quantifiés et hiérarchisés dans cette étape. La quantification consiste simplement à attribuer un numéro à chaque risque de la liste qui donnera une indication de la priorité avec laquelle il doit être traité.

La probabilité (la probabilité d'occurrence) et l'impact (montant de la perte qu'il causerait lorsque ce risque se matérialiserait) de chaque risque sont décidés.

La méthode typique consiste à attribuer les notes. Par exemple, La probabilité peut prendre des valeurs de 1 à 5. 1 étant la probabilité d'occurrence étant faible (peu probable du tout) et 5 étant élevée (se produira très certainement).

De même, Impact peut également se voir attribuer une note de 1 à 5. 1 étant à faible impact (même si ce risque se matérialise, la perte est minimale) et 5 étant à fort impact (pertes énormes lorsque cela se produit).

Étape 3)

Créez un format de tableau et diffusez-le à tous les représentants de l'équipe - Dev, BA, Client, PM, QA et toute autre personne pertinente.

Étape 4)

Demandez à chaque équipe de remplir les valeurs en fonction de leur cote de probabilité et d'impact.

Étant donné que les valeurs de probabilité et d'impact sont numériques, cela facilitera le calcul de la valeur du «facteur de risque».

Facteur de risque = Probabilité X Impact. Plus le facteur de risque est élevé, plus le problème est grave.

Un exemple:

Veuillez noter qu'à ce stade, il s'agit simplement du résultat de la notation d'une équipe. Pour un projet où 5 équipes différentes sont impliquées, l'équipe QA se retrouverait avec 5 tables différentes.

Étape # 5)

Prenez une moyenne des valeurs du facteur de risque. Par exemple, s'il y a 5 équipes, pour chaque module, additionnez toutes les valeurs des facteurs de risque et divisez-les par 5. Ce sont les valeurs finales que nous allons traiter. Dites, ce sont les facteurs de risque moyens:

Plus le facteur de risque est élevé, plus ce module doit être testé.

Ainsi, les modules 5 et 2 sont les plus cruciaux pour le succès de l'entreprise. Partagez les résultats avec toutes les équipes.

Étape # 6)

Plan d'atténuation des risques : Maintenant, c'est l'étape qui passe du projet au projet. Nous avons identifié que les modules 5 et 2 sont ceux sur lesquels il faut le plus se concentrer.

Exemplesdu plan pourrait être:

1. Les modules 5 et 2 seront testés de manière approfondie en s'assurant que tous les cas de test qui leur sont liés sont testés. Les autres modules seront testés sur une base exploratoire.
2. Les modules 5 et 2 vont être testés en premier, puis en fonction du temps disponible, les autres seront pris en charge.

Une fois le plan établi, toutes les équipes parviennent à un accord et le suivent pour tester le produit en tenant compte du facteur de risque.

C'est tout!

Quelques points importants à noter:

• Puisqu'il s'agit d'une activité collective qui prend l’opinion de chacun en considération ; les chances qu'elle soit précise et efficace sont plus élevées.
• C'est pas une méthode formelle et n'a pas à faire partie de chaque projet d'AQ.
• Parfois, même si l'équipe choisit de ne pas dessiner de tableaux et d'attribuer des valeurs - un séance de brainstorming simple toutes les personnes présentes peuvent donner à l'équipe d'assurance qualité une bonne direction sur la façon de procéder.
• Le contribution de l'équipe de développement est très important car ce sont eux qui créent le produit, ils sauront donc ce qui pourrait fonctionner et ce qui pourrait nécessiter une vérification supplémentaire. Soyez sûr d'être à l'affût de cela.
• Même s'il y a plusieurs étapes dans le processus, il ne faut pas beaucoup de temps pour les exécuter . Surtout si toutes les équipes peuvent s'asseoir ensemble et travailler simultanément.
• Rappelez-vous ce processus et son résultat est seulement l'alternative . Obtenir autant de temps que prévu pour les tests est le meilleur moyen d'effectuer l'activité d'assurance qualité.

Conclusion

L'approche des tests basés sur les risques indique clairement que l'objectif du testeur n'est pas seulement de continuer à explorer les défauts, indépendamment de leur gravité et de leur priorité. Maintenant, les choses ont changé et les testeurs doivent travailler intelligemment et ils doivent comprendre clairement le «besoin du client et les désirs de l'utilisateur».

Ils doivent étudier le produit en profondeur et comprendre quelle est la fonctionnalité la plus fréquemment utilisée dans la production, quelle est la voie la plus critique pour la génération de revenus et comment protéger et protéger les clients contre les problèmes de production et les menaces commerciales.

Par conséquent, l'approche RBT informe clairement les testeurs3 que le simple fait de tout tester ou de tester de manière approfondie ne signifie pas que le test est terminé ou qu'il n'y a aucun défaut dans le produit. Tester efficacement dans un temps imparti et s'assurer que les impacts critiques et majeurs sur l'entreprise sont annulés, ce qui est très important pour le testeur.

Ainsi, les tests basés sur les risques sont l'outil le plus efficace pour l'équipe d'AQ pour guider les parties prenantes du projet en fonction des risques du projet. L'approche RBT aide l'équipe d'assurance qualité dans l'identification continue des risques et sa résolution qui pourraient mettre en danger la réalisation des buts et objectifs globaux du projet et aide à atteindre l'objectif ultime du groupe d'assurance qualité.

P.S. Les mots QA et Testing ont été utilisés de manière interchangeable dans tout le document.

A propos de l'auteur: Cet article est rédigé par plusieurs membres de l'équipe STH - Gayathri Subrahmanyam et Swati S.

Gayathri est une PME de tests logiciels avec plus de 2 décennies d'expérience dans les tests logiciels et a largement adopté l'approche «Test basé sur les risques» dans le cadre de l'industrialisation des tests dans plusieurs engagements et a réalisé les avantages de l'optimisation des ressources de test et des tests de qualité.

Les tests basés sur les risques ont-ils été difficiles pour vous? Avez-vous des faits intéressants à ajouter à notre tutoriel? N'hésitez pas à exprimer vos pensées dans la section commentaires ci-dessous !!

=> Visitez ici pour une série complète de didacticiels sur le plan de test

lecture recommandée

• Processus d'intégration continue: comment améliorer la qualité des logiciels et réduire les risques
• Analyse des modes de défaillance et des effets (FMEA) - Comment analyser les risques pour une meilleure qualité logicielle et des clients satisfaits!
• Le guide ultime des tests basés sur les risques: la gestion des risques dans les tests logiciels
• Top 10 des outils et techniques d'évaluation et de gestion des risques
• Types de risques dans les projets logiciels
• Quelques questions d'entretien intéressantes sur les tests de logiciels
• Choisir les tests de logiciels comme carrière
• Commentaires et évaluations du cours de test de logiciels