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.
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.
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