Comment construire un tableau de bord pour un projet de test
- nombre de tests OK,
- nombre de tests KO,
- nombre de tests Non Testables,
- nombre de tests Non Exécutés
- .nombre d’anomalies bloquantes, majeures, mineures…etc
- Est ce que mon application a une qualité suffisante pour la mettre en production ?
- Combien d’itérations de tests restent-ils encore et quand est ce que les activités de tests seront clôturés ?
- Aujourd’hui quelles sont les parties de l’applications qui fonctionnent correctement ? Et qu’est ce qui ne fonctionne pas ?
- A quoi est due la non qualité de l’application et qu’est ce qui est faisable pour l’améliorer ?
Les indicateurs de qualité
Un produit logiciel n’est pas constitué de tests, les tests sont des éléments externes qu’on applique sur le produit logiciel pour juger de sa qualité. On peut cependant représenter une application par les exigences fonctionnelles et techniques qui la constituent : des fonctionnalités, un backlog de user stories, un ensemble de cas d’utilisations, des caractéristiques techniques… etc
Les exigences sont une expression formelle et hiérarchisée des besoins d’un projet logiciel.
Ces exigences ont autant d’importance pour les activités de test que pour les activités de développement,
En plus de faciliter la transmission du besoin exprimé par les référents métier et permettre sa compréhension par le développeur et le testeur, représenter un produit logiciel par une structure d’exigences, rend sa qualité mesurable.
« Tout ce qui se mesure se gère » Peter Drucker.
Grâce aux exigences, le produit logiciel peut être structuré en arborescence et sa qualité peut alors être représentée sous forme d’une TreeMap. Les exigences sont une expression formelle et hiérarchisée des besoins d’un projet logiciel.
Ces exigences ont autant d’importance pour les activités de test que pour les activités de développement,
En plus de faciliter la transmission du besoin exprimé par les référents métier et permettre sa compréhension par le développeur et le testeur, représenter un produit logiciel par une structure d’exigences, rend sa qualité mesurable.
« Tout ce qui se mesure se gère » Peter Drucker.
Grâce aux exigences, le produit logiciel peut être structuré en arborescence et sa qualité peut alors être représentée sous forme d’une TreeMap.
A titre d’exemple, on peut considérer qu’une application de calcul, a pour exigences les fonctions suivantes : Addition, Soustraction, Multiplication et Division.
Si ces fonctions ont des tailles différentes selon leur importance métier, leur complexité technique ou fonctionnelle alors la représentation de cette application peut en tenir compte.
Suite à une compagne de test ces résultats sont annoncés : 68% OK, 12%KO, et 20% NE.
Grâce à ces résultats on sait que globalement l’application n’est pas opérationnelle puisque il y a 12% de cas en échecs. Mais ces résultats ne permettent pas de savoir lesquelles de ces fonctions sont opérationnelles, ni même lesquelles ont été couvertes par les tests exécutés.
Les chiffres bruts d’exécution sont tellement ambigus qu’ils peuvent représenter différents niveaux de qualité du produit et ainsi correspondre à plusieurs situations.
Situation 1 : Ces résultats peuvent signifier que 2 parties de l’application sont validés et sont opérationnelles.
Notez ici que dire que les modules Addition et Soustraction sont validés, et les modules Multiplication et la Division non validés a beaucoup plus de sens que : 68% des cas de test sont OK, 12%KO, et 20% NE.
Situation 2 : Ces résultats peuvent aussi signifier qu’aucune fonction n’a été validé, donc aucune n’est opérationnelle :
Quelques soit la situation, cette représentation permet en un coup d’œil de suivre la qualité du produit logiciel.
Une autre façon de suivre la qualité du produit logiciel est l’histogramme de validation des exigences combiné à un histogramme des anomalies ouvertes.
Ce graphique associe l’avancement de la validation de l’exigence (le grand histogramme) aux anomalies ouvertes sur cette exigence (les petits histogrammes), comme ça on voit plus clairement le chemin à parcourir pour atteindre nos objectifs de qualité.
Un objectif qualité peut être :
- Un seuil maximum de tests en succès qui peut différer d’une exigence à une autre selon son importance (la barre rouge dans la graphique).
- Un seuil maximum d’anomalies selon leurs criticité.
Les indicateurs de moyens
Les indicateurs de qualité sont la raison première du tableau de bord mais en cas de non qualité il faut donner aux gestionnaires des leviers pour améliorer la situation pour ne pas s’enliser dans les itérations et les régressions.
Pour vous aider à construire le tableau de bord le plus adapté à votre projet, je vous proposes quelques indicateurs à titre d’exemples pour inspirer votre démarche.
La force de test
Ces indicateurs présentent la capacité de l’équipe de test à préparer et à exécuter des tests en montrant le nombre de testeurs travaillant sur chaque activité et leur productivité.
La disponibilité de la plateforme :
Les indisponibilités de la plateforme de test et son instabilité peut être très handicapant pour les activités de test, il faut alors suivre son état de près.
La force de développement :
Détecter des anomalies est un gage d’efficacité des activités de tests mais n’améliore en rien la qualité du produit si elles ne sont pas suivies par un effort de correction et de livraison ayant autant d’efficacité.
Les compteurs des tests :
Le graphique « Préparation des tests » met en évidence la marge de tests préparés et qui sont prêts à être exécutés, si cette marge est petite le besoin d’accentuer l’effort de préparation peut être urgent.
Le graphique « Exécution des Tests » mesure le taux de re-test qui est un indicateur de la qualité des développements.
Le graphique Bilan des tests est une représentation quantitative des tests basés sur les résultats des exécutions. En effet pour avoir cette progression des tests plusieurs itérations d’exécution ont pu être nécessaires.
Les indicateurs d’analyse
Les indicateurs que nous avons vu plus haut sont tous des photos prises à un instant donné de la vie du produit logiciel, mais parfois nous avons besoin de plus pour analyser la situation de notre projet.
En réalité, un client demande autre chose que seulement comment se porte son projet à un instant donné, il peut exiger une visibilité sur le futur.
Il peut ainsi poser au responsable de test les questions suivantes :
- « Quand est ce que tout ça va se terminer ? »
- « Quel périmètre aura-t-on validé au 1er Juillet ? »
- « Est ce qu’on aurait tout fini à une date donnée ? »
Quand est ce que tout ça va se terminer ?
Le responsable de test peut bien sûr lui faire une prévision basée sur des estimations et des calculs farfelues mais un Greattesteur se basera lui sur l’historique réel du projet.
« Celui qui ne sait pas d’où il vient ne peut savoir où il va car il ne sait pas où il est. En ce sens le passé est la rampe de lancement vers l’avenir » l’Archiduc Otto d’Habsbourg-Lorraine
Les résultats de l’exécution des tests sont ainsi sauvegardés et suivis dans le temps :
On peut associer d’autres données à ces courbes pour relever des corrélations :
- Les fluctuations de la disponibilité de l’infrastructure
- Les changements du nombre de personnes travaillant sur la préparation et l’exécution des tests et leurs vélocité.
- La capacité de l’équipe de développement à corriger les anomalies.
Pour répondre alors à la question du client sur la fin des test, le Greattesteur peut donner une réponse en quelques secondes et voici comment il fera!
En se basant sur la courbe de tests en succès (OK), il va dessiner de façon manuelle une ligne de projection optimiste et une ligne de projection pessimiste.
L’écart entre la ligne optimiste et pessimiste symbolise la prédictibilité du projet de test, heureusement cet écart tend généralement à se stabiliser avec le temps.
La question du client fixe un objectif de périmètre à 100 %, mais le temps est variable.
La fin prévue des tests est alors l’intervalle entre les intersections des lignes de projection et la ligne du périmètre 100 %: Ici la fin des test est prévue entre mi-janvier et début Mars.
L’avantage de cet approche est sa simplicité, sa rapidité ainsi que la transparence qu’elle apporte vis à vis du client en communiquant honnêtement sur les incertitudes du projet.
Si le client souhaite une date au lieu d’une période, il est tout à fait possible d’utiliser la courbe de tendance qui existe nativement dans Excel : Outils de Graphique – Création – Ajouter un élément de graphique – Courbe de tendance – Prévision linéaire.
Quel périmètre aura-t-on validé au 1er Juillet ?
Dans ce cas le périmètre est variable et le temps est fixe. Cela donne quelques chose comme ça.
En fixant la date, La projection des intersections sur l’axe nous donne un périmètre cible : Le Greattesteur dira ici qu’au 1er Janvier on aura couvert 77 à 92% du périmètre.
Est ce qu’on aurait tout fini à une date donnée ?
La même logique s’applique ici aussi.
On constate que cette question fixe le périmètre à 100 % et fixe aussi la date (par exemple au 1er Décembre).
Sur la graphique ça donnera quelques chose qui ressemble à ça :
Ici la réponse à la question du client serait clairement : « Non, on n’aura malheureusement pas tout fini au 1er Décembre ».
Voici ce qui est sera validé à la date voulue.
Et voilà le délai nécessaire pour tout valider.
On aura donc le choix entre :
- réduire le périmètre : livrer en Décembre et le reste après
- ou allonger les délais : ne rien livrer en Décembre et tout livrer après
Le client choisira ce qui lui convient le mieux.
En général il vaut mieux commencer par réduire le périmètre, on peut toujours ainsi faire une deuxième livraison pour couvrir 100 % du périmètre.
Cette approche a l’avantage, encore une fois, d’utiliser de vraies données pour ses prévisions et communique en toute transparence sur les incertitudes du projet.
J’espère que ces indicateurs vous inspireront pour construire un tableau de bord adapté aux besoins de vos projets et qu’ils vous permettront de communiquer des informations pertinentes pour prendre les bonnes décisions.
Références :
- Le développement logiciel Agile du point de vue du métier. Vidéo de Henrik Kniberg traduite par Cédric Chevalérias et doublée par Florent Lothon (http://www.agiliste.fr).
La charge de test du projet est la somme des charges des exigences du périmètre de test.
