Avant de lancer l’exécution de campagnes de tests pour un site internet ou une application mobile, il est nécessaire de rédiger des cas et plans de tests précis. Ce préalable, véritable fil rouge, permet d’assurer la maîtrise de la campagne de tests à mener. Pour être efficace, encore faut-il savoir bien formaliser et rédiger les cas et plans de tests. Explications.

Les campagnes de tests à mener sur des sites internet et applications mobiles s’appuient sur deux éléments essentiels : les cas de tests et les plans de tests. Si les premiers (cas de tests) décrivent, par le détail et unitairement, chacun des tests à exécuter, les seconds décrivent l’implémentation de la stratégie de tests, après chaque sprint (en mode Agile) avec le plan de test de niveau et de manière globale sur l’intégralité du projet dans son ensemble.

 

Éléments entrant dans la rédaction d’un cas de tests

Pour mémoire, un cas de tests correspond à une typologie de tests à exécuter (unitaire, d’intégration, …) afin de mesurer la bonne réalisation, ou non, du résultat attendu, selon une donnée de tests (Jeux de données ou JDD). Cela permet de comparer la réalité avec le résultat attendu. De fait, la rédaction de chacun des cas de tests doit lister :

  • Le type de test à exécuter et son scénario d’exécution.
  • Les données de tests qui doivent être utilisées.
  • Le résultat attendu.

 

Éléments entrant dans la rédaction d’un plan de tests

Chacun de ces cas de tests viennent s’insérer dans un plan de tests. Selon l’ISTQB®, on distingue deux types de plans :

  • Le plan de tests de niveau qui a pour but de décrire les activités précises à mettre en œuvre pour chaque niveau de tests (tests unitaires, d’intégration, système, d’acceptance), soit les cas de tests.
  • Le plan de tests maître, ou plan de tests projet, dont l’objectif est l’implémentation de la stratégie de tests sur un projet (site internet ou application mobile) particulier.

 

Concrètement, toujours selon l’ISTQB®, un plan de tests (de niveau et maître) doit répondre à différentes interrogations :

  • Pourquoi tester ? Il convient ici d’identifier et de lister les objectifs à atteindre.
  • Que tester ? Ce point doit préciser le périmètre de l’activité de recette du projet et mentionner les éléments qui sont à tester et ceux qui ne le sont pas (en précisant, dans ce second cas pourquoi ils sont exclus du champ de tests).
  • Comment tester ? La réponse à cette interrogation se décompose, en fonction des objectifs des tests, comme suit :
    • Spécifier les niveaux, types et méthodes de tests (cas de tests)
    • Définir les ressources matérielles adéquats (configurations matérielles, logicielles, outils de production…)
  • Qui mène les tests ? Ce point doit identifier les rôles et responsabilités de chacun (Test Manager, Testeur, Métiers, Développeurs).
  • Quel est le calendrier des tests ? Soit le planning lié à chaque niveau (plan de tests de niveau) et au projet global (plan de tests maître).
  • Quels sont les livrables ? Le plan de tests maître doit lister les différents plans de tests de niveau ; ces derniers mentionnant quant à eux les cas, scripts, données et rapports de tests.

 

Quand rédiger ces différents éléments ?

Ces éléments doivent impérativement être établis au début du processus, soit après avoir été évoqués lors des premières réunions pré-codage (lire à ce sujet les articles de notre blog : « 5 raisons d’intégrer les phases de tests dès la conception » et « Développement de sites ou d’apps mobiles : comment intégrer les phases de tests dans une démarche agile ? »)

 

Chez Testing Digital nous accordons une grande importance à la rédaction de ces éléments, car une fois clairement rédigés, les cas et plans de tests nourriront, de manière architecturée et précise l’outil de remontées des anomalies (lire à ce sujet : « Comment remonter une anomalie ? »).

Author

Xavier BRICE est COO et associé de TESTING DIGITAL. Issu d’une formation design / direction artistique, il commence par la création d'une agence de communication digitale en 2007 avant de lancer sa 1ère startup avec la création de CONTEST n' CO, société visant à changer les règles de communication interne au sein des entreprises. Consultant pour Byron Group depuis 2010, il crée avec Franck Sarfati et Fabien Driard, en 2012, le laboratoire de tests de Testing Digital.

Write A Comment