Les plans de test

Définition ISTQB : un document décrivant l‘étendue, l‘approche, les ressources et le planning des activités de test prévues. Il identifie entre autres les éléments et caractéristiques à tester, qui fera chaque tâche, le degré d‘indépendance des testeurs, l‘environnement de test, les techniques de conception des tests et les techniques de mesure des tests à utiliser, et tout risque nécessitant des plans de contingence. C‘est un document reprenant les processus de planification des tests [d‘après IEEE 829]

Un plan de test définit donc ce que l’on va tester, comment on va le tester mais aussi ce qui ne va pas être testé. Une analyse des risques est également présente afin de décrire les limites de ces choix et leurs impacts sur la qualité.

Différents plans de tests

Il y a de nombreux types de plans de test. D’après ISTQB on peut les regrouper en 2 groupes, les plans de tests impactant l’ensemble du projet et étant haut niveau, les plan de tests plus précis spécialisés sur un niveau de test en particulier.

Plan de test maître/ de projet:

Un plan de test définissant plusieurs niveaux de tests

Plan de test de niveau/ de phase:

Plan de test spécifique à un niveau de test

Personnellement, j’encourage les plans de test par fonctionnalité (et donc par User Story en Scrum). Dans le cas du SCRUM, mes plans de tests ciblent généralement les tests fonctionnels (tests systèmes) mais il est également possible de le faire sur les différents niveaux de test, par exemple les tests unitaires en écrivant directement dans le plan de test que la couverture des instructions des tests unitaires est bien de 100%.

Quelle est la valeur ajoutée d’un plan de test ?

Un plan de test permet de savoir où l’on va et comment on y va. Il permet donc d’y aller plus efficacement. Il assure également la bonne compréhension du besoin par l’ensemble des personnes travaillant sur le projet en étant un document accessible par tous où il est écrit explicitement ce qui va et ce qui ne va pas être testé.

La partie « ce qui ne va pas être testé » est très importante. Si des bugs sont trouvés sur ce qui n’est pas testé, alors cela ne peut pas être reproché (et théoriquement ne devrait pas être corrigé non plus). Par exemple, si on veut développer une application Android, il faut savoir sur quels téléphones et quelles versions d’Android on souhaite que l’application fonctionne. On peut choisir d’avoir une application ne fonctionnant qu’à partir d’Android 5.0, dès lors tous les téléphones avec des versions antérieures ne sont pas dans le périmètre de test (cela réduit fortement le coût des tests). De même on peut également dire que l’on teste uniquement sur un certain nombre de téléphones en excluant, par exemple, les téléphones qui ne sont pas vendus en boutique (c’est pour cela que les opérateurs assurent le fonctionnement de leurs applications uniquement sur les téléphones en boutique).

Comment implémenter les plans de test ?

Comme tout bon testeur, il faut savoir être pragmatique. Selon les projets les besoins sont différents, les budgets également. Il faut également convaincre, souvent par l’exemple, de l’utilité de ce ou ces plans de test. Comme pour le développement d’applications, le POC (Proof Of Concept) peut être très utile.

Je travaille depuis peu de temps sur un projet de récupération d’informations sur une base de données contenant des documents. Lorsque je suis arrivé il n’y avait pas de plans de test. Mes premières questions ont été :

–         Qu’est-ce que l’on teste ?

–         Quels sont les formats des documents ?

–         Comment teste-t-on l’application ?

–         Que veut-on exactement ?

Ces questions n’ont pas eu de réponses claires, en effet les besoins n’étaient pas explicitement définis. Dès lors j’ai proposé un plan de test général de l’application puis un exemple de de plan de test sur une des fonctionnalités de l’application. Pour cela j’ai utilisé des plans de tests simples en m’inspirant du « One Page Test Plan ».

Ces plans de test ont tout de suite été adoptés car ils permettaient de répondre à mes premières questions, à connaitre les risques mais aussi savoir comment on souhaitait tester l’application.

Je n’ai évidemment pas proposé de plans de test exhaustifs, ce n’est pas le besoin sur ce projet. Sur ce projet le besoin était d’avoir un cap et un document permettant de mettre d’accord tous les acteurs du projet sur ce qui est attendu de l’application.

Pour des projets en mode SCRUM, un test plan pour chaque User Story est également un très bon outil et ce pour les mêmes raisons que précédemment.

Conclusion

Un plan de test est un outil, de mon point de vue, quasiment incontournable. C’est un document qui permet à l’ensemble des acteurs de se mettre d’accord sur le périmètre de l’application et sur les risques engendrés par ces choix. Il donne un but clair et commun à l’ensemble des acteurs.

Enfin ce document peut être écrit rapidement, (il doit être adapté au projet sur lequel on l’utilise) il peut donc avoir un très bon retour sur investissement.

Sources :

Glossaire ISTQB : http://swisstestingboard.org/wp-content/uploads/2014/04/Glossaire_des_tests_de_logiciel_-_2_1_F_ISTQB.pdf

Dojo One Page Test Plan : https://dojo.ministryoftesting.com/lessons/the-one-page-test-plan?utm_content=bufferdde79&utm_medium=social&utm_source=linkedin.com&utm_campaign=buffer