Comment estimer un projet de test

Tu es responsable d’une équipe de test et tu souhaites estimer la charge des activités de test de ton projet. Dans cet article tu vas découvrir une méthode simple et efficace pour y parvenir.

N’hésites pas à poser des questions dans le zone commentaires pour clarifier tout point traité dans cet article.

Ce qu’il faut savoir avant de commencer :

Le test n’est pas une activité isolée, il dépend fortement de toutes les autres activités du cycle projet, et par conséquent, toi aussi tu dépends des autres acteurs du projet .

L’estimation n’est pas une tâche que tu es sensé accomplir seul dans un bureau, il te faut des informations fonctionnelles, techniques et logistiques dont un responsable de test ne dispose pas toujours.

Collaborer étroitement avec les autres intervenants du projet est alors capital: les profils métiers, les développeurs, et l’exploitation.  Cette collaboration a un autre avantage qui a au moins autant d’importance; un intervenant associé au travail d’estimation, se sent naturellement respecté, sa compétence reconnue, et il a envie que cela dure et que le travail auquel il a participé soit une réussite et fera ce qu’il pourra pour que ça le soit.

Impliquer les gens est un moyen respectueux et efficace pour les engager.

L’estimation de la charge de test est idéalement réalisée au début du cycle projet, mais il arrive que dans la réalité, le responsable de test et son équipe soient impliqués tardivement dans le cycle projet, et sont donc contraints de fournir une estimation de la charge de test alors qu’une date butoir de mise en Production est déjà décrétée !

Mais comment estimer la charge de test ?

En résumé  :

Etape 1 : Créer la liste « à tester »

Le processus d’estimation commence par un travail de collecte d’information.

En tant que test Manager, tu dois contacter les représentants des autres équipes du projet (Métier, Dev, Opérations) afin de rassembler une liste d’exigences fonctionnelles et non fonctionnelles. Selon les projets, ces exigences peuvent être des fonctionnalités, des user stories, des cas d’utilisation … etc

Cette liste constitueras ton périmètre de test, il s’agit généralement d’une liste très proche de celle fournie à l’équipe de développement par la MOA, cela permet aux différentes équipes de parler un langage commun lors des réunions, cela facilitera grandement la communication et réduira les incompréhensions (phénomène de distorsion du besoin : pertes d’information d’une équipe à l’autre, dû à des interprétations incomplètes ou erronées du besoin initial).

La qualité de cette liste a un impact direct sur la qualité des développements et des tests.

Remarque pratique : Lors des échanges avec les parties prenantes, des points à vérifier par les tests peuvent être cités, il serait utile de bien les noter car cela pourrait apporter une aide non négligeable lors de la quantification des exigences de test correspondants (Etape 2).

Etape 2 : Prioriser les éléments de la liste

L’analyse de risque qualité (ou l’analyse de risque produit) est une façon efficace de prioriser les exigences.

Le risque est la possibilité qu’un événement négatif ou non désiré puisse survenir, on appelle un risque projet tout risque pouvant porter sur des aspects délai et coût du projet (dépassement planning, absence ressources, surcoût ressources..).et on appelle risque produit ou risque qualité tout risque pouvant porter sur la qualité du produit logiciel développé (fonctionnement, sécurité, fiabilité…).

Le test Manager n’est pas le mieux placé pour évaluer le risque qualité de chaque exigence, mais doit apporter la méthode adéquate. Il est donc nécessaire d’impliquer les intervenants clé qui ont fourni ces exigences, leur proposer une méthode de priorisation et les accompagner dans sa réalisation.

Remarque : les Étapes 1 et 2 peuvent être réalisées conjointement.

Etape 2.1 : Evaluer le risque

Pour chaque exigence, 2 valeurs sont à renseigner pour évaluer le risque de dysfonctionnement:

  • La probabilité d’occurrence d’une défaillance :La probabilité est élevée si la fonctionnalité correspondante est de grande taille ou complexe.
  • L’impact en cas de défaillance : Plus les conséquences d’un incident en production au niveau de cet exigence sont importants plus la valeur de l’impact est élevée

Etape 2.2 : calculer les scores de risque qualité des exigences

Evaluer le risque qualité revient à calculer le score de chaque exigence.

Score  = Probabilité * Impact 

Etape 2.3 : Catégoriser les exigences en classes de priorité

Classer ces exigences en catégories selon le score de risque qualité :

Etape 3 : Associer des approches de tests aux classes de priorité (stratégie de test)

Une stratégie de test sera établie en associant une approche de test (plus ou moins rigoureuse) à chacune des classes de priorité.

Plus le risque est grand plus il faut tester en profondeur

Une approche de test peut être une technique de test : tests exploratoires, valeurs limites, classes d’équivalence… ou simplement une couverture de test : nombre de combinaisons de valeurs des champs d’un formulaire, les profils opérationnels …

Associer à chaque classe de priorité une approche de test. Une approche de test peut combiner plusieurs techniques/couverture de test.

L’approche de test choisie détermine l’effort de test nécessaire pour diminuer le risque d’incident pour chacune des classe de priorité.

Etape 4 : Estimer l’effort de test

Etape 4.1 : Calculer les durées de test de référence

Simuler ou à défaut estimer les actions de préparation et d’exécution pour une exigence de référence simple en utilisant chacune des approches choisies.

La simplicité de l’exigence de référence facilite grandement l’exercice d’estimation. Choisir une exigence de petite taille : Probabilité = 1

Conseil pratique : Il serait utile de noter en commentaire les postulats sur lesquels ont été basé ces estimations de base. Cela aidera à réajuster sereinement les calculs plus tard.

Etape 4.2 : Calculer les charges de test

Estimer l’effort de test pour chaque exigence selon sa taille par rapport à l’exigence de référence(Probabilité) et sa catégorie (Approche):

La charge de test du projet est la somme des charges des exigences du périmètre de test.

Etape 5 : Ajuster l’estimation (nouvelle itération)

Il est toujours possible de réajuster les résultats de l’estimation en cas de besoin, pour cela tu disposes de plusieurs leviers :

  • Appliquer des Coefficients de modération aux charges des exigences: si l’équipe a hérite d’un patrimoine de test existant de précédentes campagnes, ou que le niveau d’expertise des testeurs est élevé, cela réduit significativement le temps de préparation et exécution …
  • Réévaluation du risque ( Importance métier, Complexité fonctionnelle, complexité technique)
  • Modification de la stratégie de test : Modifier l’effort de test ( approches, couverture, profondeur de test..)

Les questions et commentaires des lecteurs améliorent la qualité des articles et font plaisir à l’auteur, n’hésitez pas à m’écrire ci-dessous.

6 commentaires sur “Comment estimer un projet de test

Ajouter un commentaire

  1. Merci pour cet article très complet, il donne des pistes intéressantes et concrètes pour cette tâche critique. Le côté relationnel évoqué au début de l’article est également très pertinent.

    (Petite remarque, je ne peux pas m’empêcher 😀 Il y a une petite faute d’orthographe dans le préambule : « Dans cette article »)

  2. Merci bcp Anir pour l’article. la Démarche est parfaite et bien précise! et très claire. Mais le soucis, c’est que les managers sont pas patients et peuvent attendre la fin de ce travail pour avoir un bon chiffrage, ils veulent un résultat rapide. C’est pourquoi dans la plus pard des projets que j’ai expérimenté les tests étaient estimés soit à la base du chiffrage du dév (1/3 de l’activité de dév), soit en se basant sur l’expertise acquis par le responsable projet/fonctionnel/ ou Test. Merci encore pour ton travail.
    Je partage ton article ;).

    1. Merci Abdou pour ton commentaire et désolé pour cette réponse tardive.
      Ta remarque est juste. cette démarche d’estimation donne l’impression qu’il faut beaucoup de temps et de calculs pour avoir un chiffrage alors qu’utiliser des abaques qui ne gagnent pas en précision avec le temps semble tellement plus facile et rapide.
      J’ai préparé un outil Excel complet automatisant toute cette démarche pour permettre de faire des estimations rapides et précises.
      Tu peux y accéder par le lien suivant :
      https://greattest.fr/acces-gratuit-greattest-planner/

  3. Bonjour,
    Article pragmatique, très intéressant.J’ai cependant quelques questions :
    1-quelle est la définition d’une petite taille d’exigence, sur quel critère cela repose t-il ?
    2-comment évaluer une durée de préparation et d’exécution de test à partir d’une exigence qui peut couvrir plusieurs tests et des tests qui peuvent combiner plusieurs exigences ?
    3-comment evaluer la probabilité d’occurrence sur des exigences faisant l’objet de tnr? Merci d’avance pour le retour

    1. Bonjour Annabelle,

      Merci pour ces questions, en voici quelques éléments de réponses.

      1-quelle est la définition d’une petite taille d’exigence, sur quel critère cela repose t-il ?
      Les exigences de petites taille sont celles dont tu as estimé la « probabilité d’occurence » à 1. Ce sont celles qui sont simples (complexité basse) et dont le test ne nécéssite que peu d’actions comme par exemple « Se connecter à portail web » qui se traduit concrétement en 3 actions simples Login, mot de passe, et Bouton « Valider ».

      2-comment évaluer une durée de préparation et d’exécution de test à partir d’une exigence qui peut couvrir plusieurs tests et des tests qui peuvent combiner plusieurs exigences ?
      La question est très pertinente. Les outils sur le marché n’impose en effet aucune méthode de définition des exigences, de conception des tests ou de traçabilité entre les exigences et les tests, mais cette liberté d’action ne dispense pas le concepteur de couvrir les exigences par les tests d’une façon à rendre les résultats des executions clairement interprétables et empêcher les confusions. Je ne connais pas d’autre moyen d’assurer cette clareté qu’en bâtissant une traçabilité en forme d’arboressance entre les exigences et les tests où une exigences peut être couverte par plusieurs tests, mais un test ne peut être lié qu’à une seule exigence.

      3-comment evaluer la probabilité d’occurrence sur des exigences faisant l’objet de tnr?
      Les tests de Non Régréssion sont des tests qui ont déjà été exécutés lors des livraisons antérieurs, pour les estimer on peut directement s’inspirer des temps de réalisation antérieurs. Toute la difficulté de l’estimation est d’apprécier un travail qui n’a pas été réalisé auparavant.

      Plus d’explications en vidéo sont disponibles dans l’espace membre: https://greattest.fr/membre-page-daccueil/

      Anir

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Fièrement propulsé par WordPress | Thème : Baskerville 2 par Anders Noren.

Retour en haut ↑