Un plan de test basé sur les risques

Planification des tests

L’objectif du plan de test est de décrire comment l’ensemble des tests sera accompli incluant les ressources, cédules et outils nécessaires à sa réalisation. Une approche efficace pour développer le plan de test est d’identifier et d’évaluer le niveau de risque du nouveau système informatique. Plus les fonctionnalités sont critiques pour les affaires, plus l’effort de test doit être important.

Comme chaque fonctionnalité ne possède pas le même poids, la planification basée sur les risques assure un découpage des efforts de test approprié et une séquence de réalisation adaptée au besoin du système ou produit logiciel à développer.

Découpage des efforts de test

Les tests logiciels devraient utiliser environ 40% des efforts total d’un projet.

Ce 40% inclut tous les essais qui pourraient avoir lieu durant un projet, soit les tests unitaires (TU), intégrés (TI), système (TS), d’acceptation (TA), de performance, de volume, de pré-production, etc.

Plus le processus de développement est immature, ou le projet est risqué, plus vite le 40% sera atteint.
Un programme de test structuré permettra de réduire à 30% d’efforts après quelques mois.
L’implantation de pratiques d’assurance et de contrôle de la qualité (AQL) en amont de la phase de tests (shift-left Testing) permettra de réduire à moins de 20% après quelques mois.

Peu importe le pourcentage, il est important de respecter trois règles :

1. L’effort des tests intégrés doit être au moins deux fois plus important que les tests unitaires.
2. L’effort des tests intégrés doit être similaire à celui des tests systèmes.
3. L’effort des tests d’acceptation devrait se limiter au même volume d’efforts que les tests unitaires si tous et chacun ont respecté leurs niveaux d’essais et leurs efforts.

Documentation des tests

Lors de la réalisation des tests, l’équipe de test doit produire plusieurs livrables :

Stratégie de test

Elle détaille comment tous les tests (unitaires, intégrés, système, acceptation, etc.) seront réalisés. Une stratégie de test est normalement fondée sur une analyse de risque.

Plan de test

Il précise comment les tests seront réalisés pour une seule phase de test. Normalement il existe un plan de test par phase de test. Bien entendu, si les TI et TS sont réalisés par la même équipe de test, il y aura un seul plan qui combine les deux phases de test. Un plan de test est, lui aussi, normalement fondé sur une analyse de risque.

Jeux de test

Ce livrable documente les scénarios et cas de tests étape par étape. Il est produit durant la phase de conception.

Calendrier de test

Il donne la séquence d’exécution des cas de test, jour par jour. Il est produit durant la phase conception.

Guide utilisateur et de formation

Le guide décrit comment utiliser le produit. Il est produit par le documentaliste (Technical Writer) qui devrait faire partie de l’équipe de test. Il est amorcé durant la phase conception et évolue en même temps que le développement du produit.

Preuve de tests unitaires

C’est la liste des éléments minimums qui doivent être testés par les développeurs durant les tests unitaires. Elle est produite durant la phase de conception, en même temps que les jeux de test.

Registre de test

Il recense la progression quotidienne des tests. Il est produit durant l’exécution des tests.

Rapport de test

Ce rapport présente les résultats des tests et permet de prendre une décision objective sur le déploiement (ou non) d’une livraison. Il est produit à la fin d’une période de test.

Gestion des anomalies

Une bonne gestion des anomalies permet de présenter celles détectées lors des tests. La liste est alimentée au fur et à mesure du processus de développement et du processus de test. Elle contient les anomalies de test mais également celles concernant la qualité (non-conformités).

Analyse de risque

Une approche efficace pour développer la stratégie et le plan de test est d’identifier et d’évaluer le niveau de risque du nouveau système informatique. Le risque est le fil conducteur majeur dans la conception des jeux de tests. Il aide à déterminer le temps, le budget et les ressources alloués aux tests.

Tout d’abord, l’équipe de test doit comprendre et investiguer les caractéristiques du système, dans le but d’évaluer le niveau de magnitude potentiel des risques (risques d’affaires). Ensuite elle doit développer sa stratégie de test basée sur ces risques.

Pour ce faire, l’équipe de test doit lister l’ensemble des fonctions et attributs qualité (attributs qualité du système ou produit logiciel, voir le modèle ISO/IEC 25010, exemples : sécurité, fiabilité, portabilité, etc.) qui sont requis par le projet. Ces attributs qualité devraient être indiqués s’ils sont importants pour le client et les parties prenantes. Ils devront être testés et sont généralement classés comme étant des tests non-fonctionnels ou de type « white box ».

Les nouvelles fonctions, les fonctions modifiées, les fonctions pour lesquelles des tests de régression sont requis sont donc listées. Pour chaque fonction et attribut, une cote de sévérité est assignée. Durant l’analyse de risque deux composantes majeures doivent être considérées pour assigner une sévérité :

1. La probabilité qu’un événement négatif survienne pour cette fonction ou cet attribut
2. L’impact, la perte potentielle ou l’impact associé à l’événement

► Sévérité d’un risque = probabilité x impact.

Probabilité

La probabilité d’apparition tient compte du taux ou de la fréquence d’utilisation d’une fonction. Ainsi lors de l’analyse d’une fonction, on détermine sa probabilité selon l’échelle suivante :

• Inévitable : tous les usagers utilisent nécessairement cette fonction (exemple : accès au système).
• Fréquent : les usagers utilisent fréquemment cette fonction, mais pas toujours (exemple : impression ou téléchargement d’un rapport).
• Occasionnel : un usager moyen n’utilise pas cette fonction qui est employée par un utilisateur plus expérimenté en cas de besoin particulier (paramétrage des options).
• Rare : la plupart des usagers n’utilisent jamais cette fonction qui n’est employée que dans le cadre d’opérations complexes (modifications de barres d’outils).

Impact

Une fois les zones de risques identifiées (fonctions et attributs qualité), on analyse l’impact d’un dysfonctionnement pour l’utilisateur. Ainsi, l’impact du dysfonctionnement est :

• Catastrophique : si cette fonction est défaillante, l’impact est majeur (la machine s’arrête, le logiciel cesse de fonctionner, la sauvegarde est impossible, etc.).
• Grave : si cette fonction fait défaut, l’application fonctionne toujours, mais le risque de perdre des données ou d’utiliser des données corrompues est important. On doit relancer l’ordinateur pour résoudre le problème (communication interrompue vers ordinateur hôte; mise à jour des données interrompue, etc.).
• Modéré : le problème rencontré incommode l’utilisateur, mais celui-ci peut le contourner à l’aide d’actions complémentaires (répertoire plein; créer un nouveau répertoire de sauvegarde).
• Ennuyeux : si cette fonction ne fonctionne pas bien, on peut continuer à utiliser l’application, mais des problèmes ultérieurs peuvent apparaître (nombre de caractères permis pour la saisie d’un nom de fichier).

Sévérité

La sévérité permet de déterminer la priorité des fonctions qui doivent être testées, ainsi que leur importance relative. On cherche également à automatiser davantage les fonctions ayant une sévérité « Élevée ».

Chaque fonction et attribut du produit logiciel se retrouve donc avec un niveau élevé, moyen ou faible de risque. Les fonctions ou attributs dits « Élevés » devront être testés davantage, donc plus d’efforts et de cas de test. Les fonctions dites « Moyennes » devront être testées deux fois moins que celles « Élevées ». Les fonctions ou attributs dits « Bas » devront être testés également deux fois moins que les fonctions « Moyenne ». La séquence de réalisation des tests doit également respecter le niveau de sévérité.

Règle des 1/3

La seule règle importante à respecter est que l’ensemble des sévérités allouées aux fonctions et attributs d’un système ou produit logiciel soit réparti également :

• 1/3 des fonctions ou attributs à « sévérité élevée »,
• 1/3 à la « sévérité moyenne »
• 1/3 à « sévérité basse ».

Le risque n’est pas une valeur fixe ou absolue : il dépend du contexte et de la perception de chaque individu. Ce qui peut être perçu comme risqué pour une personne peut ne pas l’être pour une autre, en fonction de leurs expériences, connaissances, et tolérance au risque. Une bonne pratique est de réaliser l’exercice en équipe avec le client ou le « Product Owner (PO) » et surtout ne pas oublier les parties-prenantes.

Conclusion

La planification basée sur les risques est une approche incontournable dans le développement logiciel, permettant de prioriser les efforts là où ils sont les plus critiques. En identifiant et en évaluant les risques potentiels dès le début, l’équipe de test peut concentrer ses ressources sur les zones les plus vulnérables, minimisant ainsi les surprises en fin de cycle. Cette approche proactive renforce non seulement la qualité et la fiabilité du produit final, mais elle assure également une livraison plus prévisible et contrôlée.

Pour aller plus loin :