Last update: 02/06/2016 13:53

Le rapport de tests du point de vue du … chef de projet

Pour le chef de projet, les activités de test (quelles qu'elles soient), sont le passage obligé avant la livraison du produit à fournir. Et pour le chef de projet, la date de livraison (avec respect du périmètre et qualité attendus) est l'une des plus importantes, sinon la plus importante de son plan [1] .

Nos consultants sont souvent en contact direct avec des équipes de test et toutes, dans les nombreuses missions auxquelles nous avons eu la chance de participer, ont leur manière de remettre leurs rapports de tests, tous mieux ficelés les uns que les autres, avec moult graphiques et force couleurs. Mais est-ce vraiment de cela dont le Chef de proojet a besoin? La réponse fuse: non!

Alors voici en quelques mots les objectifs du Chef de projet lorsqu'il lit un rapport de tests. Cela tient en quelques mots et nous allons les appuyer pour que les Test Managers sachent une fois pour toutes comment libeller leur communication via les Project Managers:

Le Chef de projet souhaite disposer d'un rapport qui lui dise si oui ou non le produit (souvent du software dans le cas qui nous occupe) a la qualité requise et si la qualité n'est pas suffisante quand il peut envisager de recevoir le produit à la qualité voulue. Point final. Punt aan de lijn. Period!

On le rephrase en anglais…

The Project Manager needs to be able to extrapolate/interpret the report to figure out whether it meets the quality criteria that were defined for delivery and when he will be able to deliver. That’s All, Folks!

Vite dit, mais pas vite fait! Donnons un peu de chair à cet objectif!

Informer…

C'est bien beau de montrer des courbes de toutes les couleurs et dans tous les sens indiquant le degré de couverture, le pourcentage de succès, le nombre de tests qui n'ont pas encore pu être déroulés, etc. … mais rien de tout cela n'intéresse le Chef de projet. Cela ne veut certes pas dire que ces infos sont inutiles. Cela veut simplement dire qu'elles ne sont pas utiles au Chef de projet. Nuance!

Comment construire, sur base des infos que les Test Managers montrent habituellement, ce qui intéressera le Chef de projet? Imaginons, que 100 tests ont été définis au total pour s'assurer de la qualité d'un logiciel. Imaginons encore que seuls 75 tests ont été réalisés (les autres n'ayant pas encore pu être déroulés pour l'une ou l'autre raison). Imaginons encore que sur les 75 tests réalisés, 50 soient passés avec succès (c'est 1/3 des tests, soit 66,67%). Imaginons que sur les 25 tests qui ont échoué

Imaginons encore que nous sachions qu'une anomalie prenne en moyenne 0,5 jour[2] pour être résolue (vérifiée comme "résolue").

Alors … voici le graphique attendu par le chef de projet:

La partie verte correspond à la couverture effective couronnée de succès. Ici, 50 tests sont OK sur 100.

La partie orange représente les tests qui n'ont pas été effectués. Ici, 25 tests sur 100.

La partie rouge représente les tests qui ont échoué (25 tests sur 100 dans notre cas)

Voilà le seul graphique dont le PM a besoin. Croyez-nous! Pas besoin de voir différentes courbes! Une simple tarte. Cette vue est essentielle car elle montre tout de suite un tout cohérent et toutes les découpes de la tarte sont tout de suite à l'échelle de la tarte.

Vous pouvez aussi décider de montrer plus de tranches sur la tarte: vous pouvez décider de monter le détail de la tranche rouge: autant de blocking, de partial blocking, de non-blocking, de cosmétique, … Nous vous laissons juges! Mais de grâce… KISS!

Avec ce graphique, vous montrez au Chef de projet si le produit testé rencontre la qualité escomptée. Voilà un des objectifs du PM satisfait! Que faire maintenant si le produit n'a pas encore la qualité requise (ou que vous ne puissiez pas encore conclure à la qualité du produit)? Ben … faut pouvoir dire quand on espère qu'il le sera et pour cela il faut extrapoler!

Extrapoler… la route vers le burn down chart

Vous serez obligés de faire un peu de maths sur base de la durée moyenne de résolution d'une anomalie (une moyenne qu'il vous appartient d'établir dès le début du projet et qui variera au fur et à mesure du projet en fonction des observations de terrain). Ici, rappelez-vous que nous avons établi cette moyenne à 0,5 jour.

Severity Count Time to solve Aggregated Time to Solve
Blocking 3 1.5md 1.5md
Partial Blocking 5 2.5md 4.0md
Non Blocking 5 2.5md 6.5md
Cosmetic 12 6md 12.5md

Expliquons d'emblée la première ligne de ce tableau. Nous avons 3 anomalies, chacune prend en moyenne 0.5 jour pour être réputée/vérifiée "résolue". Il faudra donc 1.5 jours pour venir à bout des 3 anos.

Voyons la deuxième ligne du tableau! Il s'agit de résoudre 5 anomalies "Partial Blocking". Sur base de la moyenne, vous déterminez ainsi qu'il faudra 2,5 jours pour en avoir fini. Ces 2,5 jours s'ajoutent aux 1,5 jours de la ligne 1 pour former un total (Aggregated Time to Solve) de 4,0 jours. Le reste des lignes se lit de la même manière.

Bien entendu, le temps moyen de résolution est une valeur qui bouge tout au long de la vie d'un projet. En tant que Test Manager il vous appartient d'en avoir la meilleure vue possible. Le Project Manager sait lui que c'est une moyenne et que cette valeur revêt ainsi un certain degré d'incertitude. Par ailleurs, il est parfaitement acceptable (conseillé même) de travailler avec des moyennes par type de sévérité (même si la sévérité n'est pas directement liée à la difficulté). À vous de voir !

Néanmoins, la table en question permet une extrapolation parfaite pour le Chef de projet: il sait qu'il peut livrer la solution dans 1,5 jours si la qualité est mise au seuil "No Blocking", dans 4,0 jours si la qualité requise est positionnée à "No Partial Blocking", dans 6,5 jours si c'est "No Non Blocking" et dans 12,5 jours si toutes les anos doivent être résolues. Simply perfect!

Et comme c'est un bon Chef de projet, il ajoute les fameux 17% de degré d'incertitude (standard de l'industrie du software), il ajoute le temps de release/packaging, il se met une échéance à COB/EOB (Close Of Business/ End Of Business) avant de communiquer quoi que ce soit à qui de droit.

L'extrapolation dont notre petit billet fait ici mention se rapproche très nettement d'un burn down chart qui n'est qu'une représentation graphique du travail qui reste à faire en comparaison avec le temps. L'extrapolation rendue possible par ce genre de graphe est le moment où il ne restera plus rien à faire (souvent utilisé dans les méthodes agiles). Voici un exemple d'un tel burn down chart en droite provenance de Google :

A project burn down chart generated from a google docs template

Enfin, voici un petit lien vers une feuille Excel qui présente un burndown chart classique. Cette feuille peut être réutilisée dans tous vos projets: échantillon de burndown

Notes de bas de page

[1] … Nous ne situons pas cette problématique dans le cadre d'une initiative Agile

[2] … C'est une moyenne que vous devrez établir sur base de votre expérience de Test Manager

Our website uses cookies to save your preferences. We kindly ask you to consent to our use of cookies when you first visit our website. If you do not consent, the sole recourse is to stop visiting our website. X