Tests basés sur les risques : approche, matrice, processus et exemples

⚡ Résumé intelligent

Les tests basés sur les risques classent chaque fonctionnalité en fonction de la probabilité qu'elle tombe en panne et des dommages que cette panne pourrait causer, puis consacrent les efforts de test disponibles aux éléments ayant le score le plus élevé en premier, par ordre de priorité.

  • (I.e. Formule de base : L'évaluation du risque correspond à la probabilité multipliée par la gravité, ce qui convertit une inquiétude subjective en un nombre comparable.
  • ☑️ Registre des risques : Une seule feuille de calcul recense tous les risques identifiés, leur responsable, leur niveau d'exposition, l'objectif du test et l'étape qui le traite.
  • Numéro de priorité du test : La probabilité, les conséquences et l'efficacité du test se multiplient pour donner un score compris entre 1 et 125 qui détermine l'ordre d'exécution.
  • 🧪 Processus en cinq phases : Identification des risques, analyse des risques, réponse aux risques, score de testping et la définition du processus de test s'exécute en séquence.
  • Chaque niveau de test : Cette approche s'applique aux tests de composants, d'intégration, de système et d'acceptation, et pas seulement aux tests système.
  • (I.e. Risque résiduel : Mesurer ce qui reste non testé après l'exécution permet de transformer les résultats des tests en une décision de mise en production éclairée.

Carte matricielle des tests basés sur les risquesping Évaluer la probabilité en fonction de la gravité pour prioriser les efforts de dépistage

Tests basés sur les risques

Tests basés sur les risques (RBT) Il s'agit d'un type de test logiciel basé sur la probabilité de risque. Il consiste à évaluer le risque en fonction de la complexité du logiciel, de sa criticité pour l'entreprise, de sa fréquence d'utilisation et des zones les plus susceptibles de contenir un risque. défautLes tests basés sur les risques privilégient les tests des fonctionnalités de l'application logicielle qui ont le plus d'impact et qui sont les plus susceptibles de présenter des défauts.

Le risque est la survenue d'un événement incertain ayant un impact positif ou négatif sur les critères de réussite mesurables d'un projet. Il peut s'agir d'un événement passé, actuel ou futur. Ces événements incertains peuvent affecter les objectifs de coût, commerciaux, techniques et de qualité d'un projet.

Les risques peuvent être positifs ou négatifs.

  • Risques positifs sont considérées comme des opportunités et contribuent à la pérennité de l'entreprise. Par exemple, investir dans un nouveau projet, modifier les processus métier et développer…ping Nouveaux produits.
  • Risques négatifs sont considérées comme des menaces, et les recommandations visant à les minimiser ou à les éliminer doivent être mises en œuvre pour assurer le succès du projet.

Puisque cette technique répartit les efforts plutôt que d'ajouter un nouveau niveau de test, elle se superpose aux autres. types de tests logiciels plutôt que de remplacer l'un d'entre eux.

Quand mettre en œuvre les tests basés sur les risques

Les tests basés sur les risques peuvent être mis en œuvre dans

  • Projets soumis à des contraintes de temps, de ressources ou de budget.
  • Projets où l'analyse basée sur les risques peut être utilisée pour détecter les vulnérabilités Attaques par injection SQL.
  • Tests de sécurité dans les environnements de cloud computing.
  • Les nouveaux projets présentant des facteurs de risque élevés, tels qu'un manque d'expérience avec les technologies utilisées ou un manque de connaissances du domaine d'activité.
  • Modèles de livraison incrémentaux et itératifs.

Processus de Management du Risque

Examinons maintenant les étapes du processus de gestion des risques.

Identification des risques

L'identification des risques peut se faire par le biais d'ateliers sur les risques, de listes de contrôle, de séances de brainstorming, d'entretiens, de la technique Delphi, de diagrammes de causes et effets, des leçons tirées de projets antérieurs, de l'analyse des causes profondes et en contactant des experts du domaine et des experts en la matière.

Un registre des risques est un tableur qui répertorie les risques identifiés, les réponses potentielles et leurs causes profondes. Il sert à surveiller et à gérer les risques. tracIdentifier les risques (menaces et opportunités) tout au long du cycle de vie du projet. Des stratégies de réponse aux risques permettent de gérer les risques positifs et négatifs.

La structure de répartition des risques joue un rôle essentiel dans la planification des risques. Elle permet d'identifier les zones à risque et facilite l'évaluation et le suivi efficaces des risques tout au long du projet. Elle contribue à allouer suffisamment de temps et de ressources aux activités de gestion des risques et à catégoriser les nombreuses sources potentielles de risques liés au projet.

L'exemple ci-dessous montre comment une structure de répartition des risques regroupe les risques liés au projet en catégories afin qu'aucune source de risque ne soit négligée.

Exemple de structure de répartition des risquesping Les risques du projet sont classés par catégories pour la planification des risques.

Analyse des risques (comprend une analyse quantitative et qualitative)

Une fois la liste des risques potentiels établie, l'étape suivante consiste à les analyser et à les classer par ordre d'importance. Parmi les techniques d'analyse qualitative des risques figure la matrice des risques (présentée ultérieurement). Cette technique permet de déterminer la probabilité et l'impact du risque.

Planification de la réponse aux risques

Cette analyse nous permettra de déterminer si les risques nécessitent une intervention. Par exemple, certains risques exigeront une prise en compte dans le plan de projet, d'autres dans le cadre du suivi du projet, et d'autres encore n'en requièrent aucune.

Le propriétaire du risque est chargé d'identifier les options permettant de réduire la probabilité et l'impact des risques attribués.

L'atténuation des risques est une méthode de réponse aux risques visant à réduire les effets néfastes des menaces potentielles. Elle consiste à éliminer les risques ou à les ramener à un niveau acceptable. Le schéma ci-dessous situe la planification des réponses aux risques dans le cadre plus large de la gestion des risques.

étape de planification de la réponse aux risques intégrée au processus de gestion des risques

Contingence des risques

On peut définir la contingence comme la possibilité d'un événement incertain dont l'impact est inconnu ou imprévisible. Un plan de contingence, également appelé plan d'action ou plan de secours pour les scénarios les plus défavorables, détermine les mesures à prendre lorsqu'un événement imprévisible survient.

Surveillance et contrôle des risques

Le processus de contrôle et de surveillance des risques est utilisé pour tracLes risques identifiés sont traités en détail, les risques résiduels sont surveillés, les nouveaux risques sont identifiés, le registre des risques est mis à jour, les raisons de tout changement sont analysées, le plan de réponse aux risques est exécuté et les déclencheurs de risques sont surveillés. Leur efficacité en matière de réduction des risques est ensuite évaluée.

Ceci peut être réalisé par des réévaluations des risques, des audits des risques, des analyses des écarts et des tendances, des mesures des performances techniques, des réunions de mise à jour de l'état et des réunions rétrospectives.

Le tableau ci-dessous fournit des informations sur les intrants, les outils et les extrants du suivi et du contrôle des risques.

Contributions à la surveillance et au contrôle des risques Outils et techniques de surveillance et de contrôle des risques Résultats de la surveillance et du contrôle des risques
Plan de gestion des risques Audits de réponse aux risques du projet Plans de contournement
Plan de réponse aux risques Examens périodiques des risques du projet Mesures correctives
Plan de communication du projet Analyse de la valeur acquise Demandes de modification de projet
Identification et analyse supplémentaires des risques Mesure des performances techniques Mises à jour du plan de réponse aux risques et de la liste de contrôle d'identification des risques
Modifications de la portée Planification supplémentaire de réponse aux risques Base de données des risques

Il faut garder à l'esprit que le risque augmente avec l'évolution technologique, la taille du projet, sa durée (un calendrier de projet plus long), le nombre d'organismes commanditaires, les estimations du projet, les efforts déployés et la pénurie de compétences appropriées.

Approche de test fondée sur les risques

Le processus de gestion décrit ci-dessus alimente l'approche de test ci-dessous. Chaque étape numérotée produit une entrée que l'étape suivante utilise.

  1. Analysez les besoins.
    • Les documents (SRS, FRS, cas d'utilisation) sont examinés. Cette activité a pour but de déceler et d'éliminer les erreurs et les ambiguïtés.
    • La validation des exigences est une technique de réduction des risques permettant d'éviter l'introduction de modifications tardives dans le projet. Toute modification d'une exigence après la validation du document de référence implique un processus de contrôle des changements et des approbations ultérieures.
  2. Évaluer les risques en calculant la probabilité et l'impact que chaque exigence pourrait avoir sur le projet, en tenant compte des critères définis tels que le coût, le calendrier, les ressources, la portée, les performances techniques, la sécurité, la fiabilité et la complexité.
    • Identifiez la probabilité de défaillance et les zones à haut risque. Ceci peut être réalisé à l'aide d'une matrice d'évaluation des risques.
    • Utilisez un registre des risques pour répertorier l'ensemble des risques identifiés. Mettez à jour, surveillez et track les risques périodiquement à intervalles réguliers.
    • Un profilage des risques doit être effectué à ce stade pour comprendre la capacité de risque et les niveaux de tolérance au risque.
  3. Hiérarchisez les exigences en fonction de la note.
    • Le processus de test basé sur les risques est défini.
    • Les risques critiques et modérés peuvent être pris en compte dans la planification, la mise en œuvre et le suivi des mesures d'atténuation. Les risques faibles peuvent faire l'objet d'une surveillance accrue.
    • L'évaluation de la qualité des données sur les risques est effectuée pour analyser la qualité des données.
  4. Planifiez et définissez les tests en fonction de la notation.
    • Appliquez une approche de test et des techniques de conception de test appropriées afin de tester en priorité les éléments présentant le risque le plus élevé. Ces éléments peuvent être testés par une ressource possédant une solide connaissance du domaine et une grande expérience en la matière.
    • Différentes techniques de conception de tests peuvent être utilisées — par exemple, table de décision technique sur les questions à haut risque, et seulement partitionnement d'équivalence pour les éléments de test à faible risque.
    • Cas de test sont également conçues pour couvrir de multiples fonctionnalités et des scénarios d'entreprise de bout en bout.
    • Préparer les données de test, les conditions de test et le banc d'essai.
  5. Revconsulter la documentation de test — les plans de test, la stratégie de test, les cas de test, les rapports de test et tout autre document créé par l'équipe de test.
    • L’examen par les pairs est une étape importante dans l’identification des défauts et la réduction des risques.
  6. Effectuez des essais à blanc et des contrôles de qualité sur les résultats.
    • Les cas de test sont exécutés en fonction de la priorité de l'élément de risque.
    • Maintenir tracIl est essentiel d'établir un lien entre les éléments à risque, les tests qui les couvrent, les résultats de ces tests et les défauts constatés lors des tests. Toute stratégie de test correctement mise en œuvre permettra de réduire les risques liés à la qualité.
    • Les tests basés sur les risques peuvent être utilisés à tous les niveaux de test. composant, l'intégration, Système et les tests d'acceptation.
    • Au niveau du système, il convient de se concentrer sur les éléments les plus importants de l'application. Cela peut être déterminé en analysant la visibilité des fonctions, la fréquence d'utilisation et le coût potentiel d'une défaillance.
    • Évaluation des critères de sortie : tous les domaines à haut risque ont été entièrement testés, seuls des risques résiduels mineurs subsistent.
  7. Signalez les résultats des tests basés sur les risques et analyser les indicateurs.
    • Réévaluer les événements à risque existants et les nouveaux événements à risque en fonction des indicateurs de risque clés.
    • Mettre à jour le registre des risques.
    • Les plans de contingence servent de solution de repli ou de plan d'urgence pour les risques d'exposition élevés.
    • L'analyse et la prévention des défauts permettent d'éliminer ces derniers.
    • Retest et Les tests de régression Valider les correctifs de défauts sur la base de l'analyse des risques précalculée, et les zones à haut risque doivent être couvertes de manière plus intensive.
    • Tests d'automatisation basés sur les risques, si possible.
    • Calcul du risque résiduel.
  8. Surveiller et contrôler les risques.
    • Les critères de sortie ou d'achèvement peuvent être définis séparément pour différents niveaux de risque. Tous les risques majeurs ont été traités par des actions appropriées ou des plans de contingence, et l'exposition au risque est égale ou inférieure au niveau jugé acceptable pour le projet.
    • Réévaluation du profil de risque et retours clients.

Approche de test basée sur les risques pour le test du système

  1. Test du système technique — On parle alors de tests d'environnement et de tests d'intégration. Les tests d'environnement comprennent les tests effectués dans les environnements de développement, de test et de production.
  2. Test du système fonctionnel — Tests de toutes les fonctionnalités, caractéristiques, programmes et modules. L’objectif de ces tests est d’évaluer si le système répond aux exigences spécifiées.
  3. Test du système non fonctionnel — Tests des exigences non fonctionnelles : performances, tests de charge, tests de stress, tests de configuration, tests de sécurité, sauvegarde et récupération procédures et documentation (documentation système, d'exploitation et d'installation).

Le schéma ci-dessous donne un aperçu clair du processus mentionné ci-dessus.

L'approche de test basée sur les risques pour les tests système est divisée en tests techniques, fonctionnels et non fonctionnels.

Les tests système comprennent à la fois des tests fonctionnels et des tests non fonctionnels.

Test fonctionel garantit que le produit ou l'application répond aux exigences des clients et de l'entreprise. D'autre part, tests non fonctionnels Ce test est réalisé afin de vérifier si le produit répond aux attentes du client en termes de qualité, de fiabilité, de facilité d'utilisation, de performance et de compatibilité.

Comment réaliser des tests basés sur les risques : processus complet

Cette section décrit le processus de test basé sur les risques, qui se déroule en cinq phases.

  1. Identification des risques
  2. Analyse de risque
  3. Réponse au risque
  4. Test Scoping
  5. Définition du processus de test

Les cinq phases s'alimentent les unes les autres comme indiqué ci-dessous.

Les cinq phases du processus de test basé sur les risques, de l'identification des risques à la définition du processus de test

  1. Dans ce processus, les risques sont identifiés et catégorisés, un registre provisoire des risques est établi, et un tri des risques est effectué afin d'identifier les risques significatifs.
  2. La réponse aux risques consiste à formuler les objectifs de test à partir des risques et à sélectionner les techniques appropriées afin que l'activité ou la technique de test réponde à ces objectifs.
  3. Les dépendances documentées, les exigences, les coûts et le temps nécessaire aux tests logiciels sont pris en compte pour calculer le score d'efficacité des tests.
  4. Score de testping Il s'agit d'une activité d'examen qui requiert la participation de toutes les parties prenantes et du personnel technique. Il est important de respecter le périmètre des risques convenu. Ces risques doivent être traités par des tests, et tous les membres doivent approuver les responsabilités qui leur sont attribuées ainsi que le budget alloué à ces activités.
  5. Une fois le périmètre des tests finalisé, les objectifs, les hypothèses et les dépendances de chaque étape de test doivent être compilés au format standard.

L'exemple détaillé ci-dessous associe chaque exigence à son risque associé et à l'objectif de test correspondant.

Exigences fonctionnelles F1 à F3 et exigences non fonctionnelles N1 et N2 associées à leurs risques et objectifs de test respectifs

Considérons les exigences fonctionnelles F1, F2 et F3, et les exigences non fonctionnelles N1 et N2.

F1 — Exigence fonctionnelle, R1 — Risque associé à F1

  • Objectif du test 1 — Démontrer à l’aide d’un test que les caractéristiques et fonctionnalités attendues du système fonctionnent correctement et que le risque R1 peut être traité par des tests fonctionnels.
  • Test — Les tests de page du navigateur sont effectués pour exécuter des tâches importantes de l'utilisateur et vérifier que R1 (le risque associé à F1) pourrait être traité dans une gamme de scénarios.

F2 — Exigence fonctionnelle, R2 — Risque associé à F2

  • Objectif du test 2 — Démontrer à l’aide d’un test que les caractéristiques et fonctionnalités attendues du système fonctionnent correctement et que le risque R2 peut être traité par des tests fonctionnels.
  • Test — Les tests de page du navigateur sont effectués pour exécuter des tâches importantes de l'utilisateur et vérifier que R2 pourrait être pris en charge dans une gamme de scénarios.

F3 — Exigence fonctionnelle, R3 — Risque associé à F3

  • Objectif du test 3 — Démontrer à l’aide d’un test que les caractéristiques et fonctionnalités attendues du système fonctionnent correctement et que le risque R3 peut être traité par des tests fonctionnels.
  • Test — Les tests de page du navigateur sont effectués pour exécuter des tâches importantes de l'utilisateur et vérifier que R3 pourrait être pris en charge dans une gamme de scénarios.

N1 — Exigence non fonctionnelle, NR1 — Risque associé à N1

  • Objectif de test N1 — Démontrer à l’aide d’un test que les caractéristiques opérationnelles du système fonctionnent correctement et que le risque NR1 peut être traité par des tests non fonctionnels.
  • Test — Les tests d'utilisabilité sont une technique utilisée pour évaluer la facilité d'utilisation des interfaces utilisateur et pour vérifier que la NR1 pourrait être prise en compte par les tests d'utilisabilité.

N2 — Exigence non fonctionnelle, NR2 — Risque associé à N2

  • Objectif de test N2 — Démontrer à l’aide d’un test que les caractéristiques opérationnelles du système fonctionnent correctement et que le risque NR2 peut être traité par des tests non fonctionnels.
  • Test - Tests de sécurité est une technique utilisée pour vérifier si l'application est sécurisée ou vulnérable aux attaques, s'il y a des fuites d'informations et pour vérifier que NR2 pourrait être traité par des tests de sécurité.

Objectifs spécifiques du test : Les risques et les objectifs des tests énumérés sont spécifiques aux types de tests, comme résumé ci-dessous.

Des objectifs de test spécifiques sont associés au type de test qui traite chaque risque individuel.

Procédure de conception du processus de test basé sur les risques

  • Élaborez un registre des risques. Celui-ci recense les risques issus d'une liste de risques générique, d'une liste de contrôle existante et de séances de brainstorming.
  • Inclure les risques associés aux exigences fonctionnelles et non fonctionnelles du système (utilisabilité, sécurité, performance).
  • Chaque risque se voit attribuer un identifiant unique.

Les colonnes 1 et 2 de ce registre contiennent l'identifiant et la description du risque. Les autres colonnes sont décrites ci-dessous.

Numéro de col. En-tête de colonne Description
3 Probabilité Probabilité que le système soit sujet à ce mode de défaillance
4 Conséquences Impact de ce mode de défaillance
5 Exposition Produit de la probabilité et des conséquences (colonnes 3 et 4)
6 Efficacité des tests Dans quelle mesure les testeurs sont-ils convaincus de pouvoir gérer ce risque ?
7 Numéro de priorité du test Produit de la probabilité, des conséquences et de l'efficacité du test (colonnes 3, 4 et 6)
8 Objectif(s) du test Quel objectif de test sera utilisé pour traiter ce risque ?
9 Techniques d'essai Quelle méthode ou technique est utilisée pour gérer ce risque ?
10 Dépendances Ce que les testeurs supposent et sur quoi ils s'appuient
11 Effort Quel effort est nécessaire pour ce test ?
12 Echelle de temps Combien de temps faut-il pour effectuer ce test ?
13 Étape de test A — Tests unitaires, Étape de test B — Tests d'intégration, Étape de test C — Tests système Nom de la personne ou du groupe effectuant cette activité

La probabilité (1 faible, 5 élevée) et les conséquences (1 faible, 5 élevée) de chaque risque sont évaluées, comme le montrent les deux registres extracts ci-dessous s'affiche.

Les colonnes « probabilité » et « conséquences » du registre des risques sont notées de 1 (faible) à 5 (élevé).

La colonne « exposition au risque » est calculée comme le produit de la probabilité et des conséquences.

  • L'exposition testée est calculée.
  • Le testeur analyse chaque risque et évalue s'il est testable ou non.
  • Des objectifs de test sont définis pour les risques testables.
  • Le testeur spécifie l'activité de test qui doit être réalisée de manière planifiée pour atteindre l'objectif du test (revues statiques, inspections, tests système, tests d'intégration, tests d'acceptation, validation HTML, tests de localisation, etc.).
  • Ces activités de test peuvent être classées en étapes (tests de composants ou tests unitaires, tests d'intégration, tests système, tests d'acceptation).
  • Il peut parfois arriver qu'un risque soit traité par plusieurs phases de test.
  • Identifier les dépendances et les hypothèses (disponibilité des compétences, des outils, des environnements de test et des ressources).
  • L'efficacité du test est calculée. Elle correspond au niveau de confiance du testeur quant à la résolution définitive du risque grâce au test. Le score d'efficacité du test est un nombre compris entre un et cinq (5 = confiance élevée, 1 = confiance faible).
  • Évaluez l'effort, le temps nécessaire et le coût de la préparation et de l'exécution de ces tests.

Les deux prochains extracLes ts affichent les colonnes de registre restantes et le score d'efficacité du test en place.

Colonnes du registre des risques pour les objectifs des tests, les techniques de test, les dépendances, l'effort et le calendrier.

Un score d'efficacité du test, allant de 1 (faible confiance) à 5 (forte confiance), a été enregistré pour chaque risque.

  • Le score de priorité du test est calculé. Il correspond au produit des scores de probabilité, de conséquences et d'efficacité du test.
  • 125 (maximum) — un risque très grave qui pourrait être détecté par des tests.
  • 1 (minimum) — un risque très faible qui ne serait pas détecté par un test.
  • En fonction du numéro de priorité du test, son importance peut être classée comme élevée (rouge), moyenne (jaune) ou faible (vert). Les éléments présentant le risque le plus élevé sont testés en premier.
  • Répartissez les activités de test entre les différentes phases de test. Désignez le groupe qui effectuera les tests pour chaque objectif dans les différentes phases de test (tests unitaires, tests d'intégration, tests système, tests d'acceptation).

La répartition entre les différentes phases de test est indiquée ci-dessous.

Numéro de priorité des tests et répartition des activités de test entre les phases de test unitaire, d'intégration, système et d'acceptation

Le périmètre des tests est défini dans le cahier des charges.ping phase.

  • Pour chaque étape, les objectifs du test, le composant testé, les responsabilités, l'environnement, les critères d'entrée, les critères de sortie, les outils, les techniques et les livrables sont définis.

Objectifs génériques des tests — Ces objectifs génériques sont applicables à de multiples projets et applications.

  • Ce composant répond aux exigences et est prêt à être utilisé dans des sous-systèmes plus importants.
  • Les risques associés aux types de tests spécifiques sont pris en compte et les objectifs des tests sont atteints.
  • Les composants intégrés sont correctement assemblés et la compatibilité des interfaces entre les composants est assurée.
  • Le système satisfait aux exigences fonctionnelles et non fonctionnelles spécifiées.
  • Les composants du produit répondent aux besoins de l'utilisateur final dans leur environnement d'utilisation prévu.
  • Une stratégie de gestion des risques est utilisée pour identifier, analyser et atténuer les risques.
  • Le système est conforme aux exigences réglementaires du secteur.
  • Le système répond aux exigencestracobligations scolaires.
  • L’institutionnalisation et la réalisation d’autres objectifs spécifiques tels que les objectifs de coûts, de délais et de qualité.
  • Les systèmes, les processus et les personnes répondent aux exigences de l'entreprise.

Objectifs de test génériques applicables à plusieurs projets et aux quatre phases de test

Des objectifs de test génériques peuvent être définis pour les différentes étapes du test.

  • Test des composants
  • Test d'intégration
  • Test du système
  • Test de réception

Considérons la phase de test du système.

  1. G4 et G5 démontrent que le système répond aux exigences fonctionnelles (F1, F2, F3) et aux exigences non fonctionnelles (N1, N2).
  2. Démontrer à l'aide de tests que les caractéristiques et fonctionnalités attendues du système fonctionnent correctement et que les risques associés à F1, F2 et F3 peuvent être traités par des tests fonctionnels.
  3. Démontrer à l'aide de tests que les caractéristiques opérationnelles du système fonctionnent correctement et que les risques associés à N1 et N2 peuvent être traités par des tests non fonctionnels.
  4. En fonction du numéro de priorité du test, l'importance du test peut être classée comme élevée (rouge), moyenne (jaune) et faible (vert).

Matrice de priorisation et d’évaluation des risques

La matrice d'évaluation des risques est une matrice probabilité-impact. Elle offre à l'équipe projet une vue d'ensemble rapide des risques et de la priorité à accorder à chacun d'eux.

Risk rating = Probability x Severity

La probabilité est la mesure de la chance qu'un événement incertain se produise, en fonction de l'exposition (temps, proximité et répétition). Elle s'exprime en pourcentage.

Cela peut être classé comme Fréquent (A), Probable (B), Occasionnel (C), Rare (D), Improbable (E) et Éliminé (F).

  • Fréquent — Devrait se produire plusieurs fois dans la plupart des circonstances (91 – 100%).
  • Probable — Susceptible de se produire plusieurs fois dans la plupart des circonstances (61 – 90 %).
  • Occasionnel — Cela pourrait se produire à un moment donné (41 – 60 %).
  • Télécommande — Peu probable, bien que cela puisse arriver à un moment donné (11 – 40%).
  • Improbable — Peut se produire dans des circonstances rares et exceptionnelles (0 – 10%).
  • Eliminé — Impossible à produire (0%).

La gravité correspond à l'ampleur des dommages ou des pertes causés par l'événement imprévu. Elle est cotée de 1 à 4 et peut être classée comme suit : catastrophique (1), critique (2), marginale (3) et négligeable (4).

  • Catastrophique — Des conséquences graves peuvent rendre le projet totalement improductif et même entraîner son arrêt. Il est impératif d'en tenir compte dans la gestion des risques.
  • Critical — Des conséquences majeures pouvant entraîner des pertes considérables. Le projet est gravement menacé.
  • Marginal — Dommages à court terme encore réversibles grâce à des activités de restauration.
  • négligeable — Dommages ou pertes minimes, voire inexistants. Ces dommages peuvent être surveillés et gérés par des procédures de routine.

La priorité est classée en quatre catégories, qui sont mises en correspondance avec la gravité et la probabilité du risque, comme indiqué dans l'image ci-dessous.

  • Grave
  • Haute
  • Moyenne
  • Low

matrice d'évaluation des risquesping probabilité en fonction de la gravité, classée en catégories de priorité grave, élevée, moyenne et faible

Sérieuse: Les risques relevant de cette catégorie sont signalés en orange. L'activité doit être interrompue et des mesures immédiates doivent être prises pour isoler le risque. Des contrôles efficaces doivent être identifiés et mis en œuvre. De plus, l'activité ne doit pas reprendre tant que le risque n'est pas ramené à un niveau faible ou moyen.

Haut: Les risques relevant de cette catégorie sont signalés en rouge et nécessitent une action immédiate ou une stratégie de gestion des risques. Il est impératif d'agir sans délai pour isoler, éliminer ou remplacer le risque et mettre en œuvre des mesures de contrôle efficaces. Si ces problèmes ne peuvent être résolus immédiatement, des échéances strictes doivent être définies pour leur résolution.

Moyen: Les risques relevant de cette catégorie sont signalés en jaune. Des mesures raisonnables et pratiques doivent être prises pour les minimiser.

Faible: Les risques relevant de cette catégorie sont signalés en vert et peuvent généralement être acceptés, car ils ne posent pas de problème majeur. Un examen périodique reste toutefois indispensable pour garantir l'efficacité des contrôles.

Liste de contrôle générique pour les tests basés sur les risques

La matrice détermine le niveau de risque. La liste de contrôle ci-dessous détermine quels candidats doivent être intégrés à la matrice.

  • Fonctionnalités importantes dans le projet.
  • Fonctionnalités visibles pour l'utilisateur dans le projet.
  • La fonctionnalité ayant le plus grand impact sur la sécurité.
  • Les fonctionnalités qui ont le plus grand impact financier sur les utilisateurs.
  • Zones de code source très complexes et sujettes aux erreurs.
  • Fonctionnalités ou fonctions qui peuvent être testées au début du cycle de développement.
  • Caractéristiques ou fonctionnalités ajoutées à la conception du produit à la dernière minute.
  • Facteurs critiques de projets antérieurs similaires ou connexes ayant causé des problèmes.
  • Principaux facteurs ou problèmes de projets similaires ou connexes ayant eu un impact considérable sur les dépenses d'exploitation et de maintenance.
  • Des exigences mal définies entraînent des conceptions et des tests de mauvaise qualité, ce qui peut avoir un impact sur les objectifs et les livrables du projet.
  • Dans le pire des cas, un produit peut être tellement défectueux qu'il est irréparable et doit être mis au rebut, ce qui nuirait gravement à la réputation de l'entreprise. Il convient d'identifier les problèmes critiques pour les objectifs du produit.
  • Situations ou problèmes qui pourraient entraîner des plaintes persistantes auprès du service client.
  • Des tests de bout en bout qui pourraient facilement porter sur plusieurs fonctionnalités du système.
  • L'ensemble optimal de tests permettant de maximiser la couverture des risques.
  • Quels tests présentent le meilleur rapport couverture des risques élevés/temps requis ?

Rapports et mesures sur les résultats des tests basés sur les risques

  1. Préparation du rapport de test. Le compte rendu de l'état des tests consiste à communiquer efficacement les résultats des tests aux parties prenantes du projet, à leur donner une compréhension claire et à montrer la comparaison des résultats des tests par rapport aux objectifs fixés.
    • Nombre de cas de test planifiés par rapport aux cas de test exécutés.
    • Nombre de tests réussis ou échoués.
    • Nombre de défauts identifiés, ainsi que leur statut et leur gravité.
    • Nombre de défauts critiques encore ouverts.
    • Temps d'arrêt de l'environnement, le cas échéant.
    • Des éléments qui font sensation, s'il y en a.
    • rapport de synthèse des tests et Couverture de test signaler.
  2. Préparation des indicateurs. Une métrique est une combinaison de deux mesures ou plus utilisée pour comparer les processus, les projets et les produits logiciels.
    • Variation des efforts et des horaires.
    • productivité de la préparation des cas de test.
    • Couverture de la conception des tests.
    • Productivité de l'exécution des cas de test.
    • Efficacité de l'identification des risques %.
    • Efficacité de l'atténuation des risques %.
    • Efficacité du test %.
    • Couverture de l'exécution des tests.
    • Productivité de l'exécution des tests.
    • Fuite par défaut %.
    • Efficacité de la détection des défauts, et densité de défauts.
    • Indice de stabilité des exigences.
    • Le coût de la qualité.

Ces mesures sont ensuite mises en perspective avec les risques :

  • Analyser les risques dans les catégories non fonctionnelles (performance, fiabilité et facilité d'utilisation) en fonction de l'état des défauts et du nombre de résultats de tests réussis ou échoués, par rapport aux risques.
  • Analyser les risques par catégories fonctionnelles à l'aide de métriques de test, de l'état des défauts et du statut de réussite ou d'échec des tests, en relation avec les risques.
  • Identifier les principaux indicateurs avancés et retardés et créer des indicateurs d'alerte précoce.
  • Surveiller et rendre compte des indicateurs de risque avancés et retardés (indicateurs clés de risque) en analysant les modèles de données, les tendances et les interdépendances.

Évaluation du risque inhérent et du risque résiduel

L'identification et l'analyse des risques doivent également inclure les risques inhérents, les risques résiduels, les risques secondaires et les risques récurrents.

  • Risque inhérent: Les risques identifiés ou déjà présents dans le système avant la mise en œuvre des contrôles et des réponses. Les risques inhérents sont également appelés risques bruts.
  • Risque résiduel: Les risques résiduels sont ceux qui subsistent après la mise en œuvre des mesures de contrôle et des réponses. Ces risques résiduels sont également appelés risques nets.
  • Risque secondaire : Le nouveau risque engendré par la mise en œuvre du plan de réponse aux risques.
  • Risque récurrent : La probabilité que les risques initiaux se reproduisent.

La mesure des résultats des tests basée sur le risque aide l'organisation à connaître le niveau résiduel de risque qualité pendant l'exécution des tests et à prendre des décisions de mise en production éclairées.

Profilage des risques et commentaires des clients

L'analyse du profil de risque est un processus permettant de déterminer le niveau optimal de risque d'investissement pour le client, en tenant compte du risque requis, de la capacité de risque et de la tolérance au risque.

  1. Risque requis Il s'agit du niveau de risque que le client doit prendre pour obtenir un rendement satisfaisant.
  2. Capacité de risque Il s'agit du niveau de risque financier que le client peut se permettre de prendre.
  3. Tolérance au risque Il s'agit du niveau de risque que le client préfère prendre.

Commentaires des clients: Recueillir les commentaires et avis des clients afin d'améliorer l'entreprise, le produit, le service et l'expérience.

Avantages des tests basés sur les risques

Les avantages des tests basés sur les risques sont présentés ci-dessous.

  • Amélioration de la productivité et réduction des coûts.
  • Amélioration des opportunités de marché (délai de mise sur le marché) et respect des délais de livraison.
  • Amélioration des performances du service.
  • Qualité améliorée, car toutes les fonctions critiques de l'application sont testées.
  • Des informations claires sur la couverture des tests. Grâce à cette approche, l'équipe sait ce qui a été testé et ce qui ne l'a pas été.
  • L'allocation de l'effort de test basée sur l'évaluation des risques est le moyen le plus efficace et le plus efficace de minimiser le risque résiduel lors de la publication.
  • La mesure des résultats des tests basée sur l'analyse des risques permet à l'organisation d'identifier le niveau résiduel de risque qualité pendant l'exécution des tests et de prendre des décisions de mise en production éclairées.
  • Des tests optimisés avec des méthodes d'évaluation des risques clairement définies.
  • Amélioration de la satisfaction client grâce à l'implication des clients, à de bons rapports et au suivi des progrès. tracRoi.
  • Détection précoce des zones à problèmes potentiels, afin de pouvoir prendre des mesures préventives efficaces.
  • La surveillance et l'évaluation continues des risques tout au long du cycle de vie du projet permettent d'identifier et de résoudre les risques, et de traiter les problèmes susceptibles de compromettre la réalisation des objectifs généraux du projet.

FAQ

Un risque produit est un défaut susceptible d'affecter l'utilisateur, comme un processus de paiement défaillant. Un risque projet menace la livraison elle-même : une compétence manquante, un environnement retardé, une exigence instable. Les tests permettent de traiter directement les risques produits, tandis qu'ils ne traitent les risques projet qu'indirectement.

L'évaluation devient une activité courte et récurrente plutôt qu'un document ponctuel. À chaque sprint, l'équipe réévalue les user stories qu'elle s'apprête à développer, ce qui permet d'actualiser le registre des risques. tracks gère le backlog au lieu d'un plan de publication rédigé des mois auparavant.

Les scores sont des estimations ; un risque auquel personne n’avait pensé n’est donc pas pris en compte. Les zones mal notées peuvent également se dégrader discrètement au fil des mises à jour. Des sessions d’exploration périodiques en dehors du registre constituent généralement la protection contre ces angles morts.

L'évaluation réalisée uniquement par les testeurs tend à privilégier les risques techniques. Une session efficace réunit un analyste métier ou un responsable produit pour l'impact, un développeur pour la complexité et l'historique des modifications, et un testeur pour la probabilité, avec un système de soutien pour résoudre les désaccords.

Les modèles d'apprentissage automatique classent les modules en fonction des données historiques de défauts, des modifications de code, des indicateurs de complexité et de la fréquence des changements extraits du système de contrôle de version et des problèmes. tracroi. Le résultat est un classement initial qui doit encore être examiné par un humain, car l'impact commercial n'est pas visible dans le référentiel.

Copilote GitHub Il est possible de rédiger des lignes de registre, des formules d'exposition et des objectifs de test candidats à partir d'une description d'exigences, et de générer des cas de test pour les éléments ayant le score le plus élevé. Les jugements de probabilité et de gravité restent toutefois du ressort de l'utilisateur.

Les secteurs réglementés conservent le même modèle de notation, mais y ajoutent une traçabilité : chaque risque, sa justification, les tests mis en œuvre et la validation sont conservés à des fins d’audit. La dépriorisation d’un risque n’est autorisée que si la justification est documentée.

Réévaluez le score dès qu'un élément ayant influencé son calcul change : nouvelle exigence, refonte majeure, incident de production ou apparition d'un groupe de défauts dans une zone faiblement notée. En pratique, les équipes procèdent à une révision à chaque fin de sprint et avant toute décision de mise en production.

Résumez cet article avec :