Analyse du risque

 

*   Les facteurs de risque

*   Priorité du risque

 

---

 

Une fois les objectifs de test recensés, il faut définir les objectifs les plus importants et ceux qui présentent le plus grand risque.

 

Comme les tests ne pourront pas éliminer toutes les anomalies de l'application, on sera toujours amené à faire des choix mais on ne voudra pas éliminer des tests les plus importants. A cet effet, on définira pour chaque objectif de test une priorité qui dérivera directement du facteur de risque.

 

On peut définir le facteur de risque comme étant la combinaison de :

*   la probabilité d'apparition d'un dysfonctionnement,

*   l'impact de ce dysfonctionnement sur les utilisateurs ou sur l'environnement.

 

En fait, cela consiste à prendre chaque objectif de test, donc chaque fonction principale de l'application, et à définir si la fonction est souvent utilisée et quel sera impact d'un éventuel dysfonctionnement.

 

Le résultat de cette analyse du risque conduit à attribuer une priorité à chaque objectif de test qui fera l'objet d'un paragraphe séparé du plan de test.

 

Le risque s'applique à des catégories particulières qui peuvent être :

*   fonctionnalité la fonction testée ne correspond pas aux besoins.

*   performance- les temps de réponse sont inacceptables,

*   instabilité les fonctions ne sont pas reproductibles,

*   coût financier - le coût du dysfonctionnement est important,

*   planning- la correction de l'anomalie induira un retard important de la livraison,

*   fiabilité -le nombre constaté d'anomalies et leur sévérité pose problème.

 

 

Le dernier maillon de la chaîne lié au risque est le sujet, c'est-à-dire les personnes qui seront directement influencée par ce facteur risque. On distingue :

*   l'utilisateur du logiciel,

*   le concepteur,

*   l'exploitant.

 

Les facteurs de risque

Probabilités d'apparition

C'est la première étape de l'analyse du risque. On parcourt l'ensemble des objectifs et on définit le degré d'utilisation de chaque fonction. On peut, par exemple, définir les degrés suivants :

*   Inévitable - Une partie de l'application que tous les utilisateurs rencontreront nécessairement. Exemple : écran d'accueil.

*   Fréquent - Une partie de l'application utilisée par les utilisateurs, mais pas dans toutes les sessions. Exemple : impression d'un document.

*   Occasionnel - Une partie de l'application qu'un utilisateur moyen n'utilisera pas, mais qui peut être utilisée par un utilisateur expérimenté en cas de besoin. Exemple : paramétrage des options.

*   Rare - Une partie de l'application qui n'apparaît que dans certains cas, dans le cadre d'opérations complexes. La majorité des utilisateurs ne l'utilisent pas, mais elle joue un rôle dans certaines situations. Exemple : modifications de barres d'outils.

 

Cette analyse des probabilités d'apparition s'effectuera au niveau de chaque objectif de test. Elle guidera les testeurs vers les fonctionnalités les plus utilisées.

 

Impact

Une fois les zones importantes identifiées, il faut analyser l'impact d'un dysfonctionnement sur l'utilisateur ou sur l'environnement externe à l'application.

 

De même, on pourra définir, selon impact des anomalies, les niveaux suivants :

*   Catastrophique. Exemple : la machine s'arrête, le logiciel dans son ensemble ne fonctionne plus, on ne peut pas sauvegarder, etc.

*   Grave - Si cette fonction ne marche pas, l'application peut continuer, mais le risque de perdre des données ou d'utiliser des données corrompues est important. Il est nécessaire de relancer l'ordinateur pour résoudre le problème. Exemple : la communication vers l'ordinateur hôte s'interrompt, et les données ne sont plus mises à jour.

*   Modéré - Le problème rencontré perturbe l'utilisateur, mais ce dernier peut le contourner en effectuant des actions complémentaires. Exemple : la disquette de sauvegarde est pleine, l'utilisateur doit passer par le disque dur pour finir la sauvegarde.

*   Ennuyeux - Si cette fonction ne marche pas, on peut continuer à utiliser l'application, mais elle peut poser des problèmes ultérieurement. Exemple : on veut entrer un nom de fichier de dix caractères, mais l'application ne permet pas d'en entrer que cinq.

 

Le fait de combiner les probabilités d'usage avec les impacts sur les utilisateurs va permettre de classer les objectifs de tests par priorités.

 

Priorité du risque

La priorité servira à valoriser l'importance que l'on accorde à chaque objectif de test.

Une priorité élevée définira les problèmes qui doivent impérativement être résolus,

une priorité moyenne les problèmes qui pourront être résolus ultérieurement, mais qu'il ne faut pas négliger, et en fin une priorité basse les problèmes dont la solution peut attendre et qui seront traités en dernier.

 

L'action suivante est d'assigner ces priorités aux objectifs de test. Cette démarche s'effectue en deux étapes : définir une table de risque, puis assigner des priorités en fonction de cette table, comme le décrit le tableau ci-dessous :

 

 

Inévitable

Fréquent

Occasionnel

Rare

Catastrophique

Elevée

Elevée

Elevée

Moyenne

Grave

Elevée

Elevée

Moyenne

Basse

Modéré

Moyenne

Moyenne

Basse

Basse

Ennuyeux

Moyenne

Basse

Basse

Basse

 

 

La dernière étape de l'analyse du risque est la constitution de la matrice de risque pour l'ensemble des objectifs de tests. Cette matrice contient les champs suivants :

*   Objectif de test

*   Probabilité d'usage

*   Impact

*   Catégorie

*   Sujet

*   RISQUE

 

précédant                                           suivant

 

[retour à l'introduction]