GENERAL – Page 2 – Test Academy

Catégorie : GENERAL

18 Fév

Qu’est ce qu’un testeur logiciel ?

Le rôle principal d’un testeur est d’apporter une information sur la qualité du Produit testé. Son travail est de fournir une réponse à la question : est ce que le produit est conforme au besoin ? Pour créer un logiciel d’envergure importante, il est nécessaire de constituer une équipe de profils multiples. Si le développeur est l’artisan qui va construire le logiciel (Le produit), le référent fonctionnel (Client, Utilisateur, Product Owner …) quant à lui est la personne dont les exigences sont à satisfaire: il décrit ce que le logiciel doit permettre de faire (Le besoin). Le testeur assure le lien entre les deux tout au long du projet. Le testeur interagit avec le référent fonctionnel afin d’assimiler son besoin initial, il vérifie que ce besoin est claire, cohérent et complet. Puis il accompagne le travail du développeur pour s’assurer que le produit développé correspond bien à ce qui est voulu par le référent. Donc récapitulant :

Le référent fonctionnel décrit le Besoin
Le développeur construit le Produit
Le testeur dit si le produit est conforme au besoin ou pas.

i le mot « dit » est choisit sciemment, parce que la responsabilité du testeur n’est pas de rendre le produit conforme, ni de modifier le besoin initial pour s’adapter au comportement constaté de l’application. La tâche principale du testeur est donc d’apporter une information sur la conformité ou non du produit développé par rapport au besoin exprimé. Cela ne diminue en rien la centralité de son action parce que c’est l’information qu’il apporte qui déclenche concrètement les travaux de correction du développeur et ainsi l’amélioration de la qualité du produit. Le testeur assimile donc le comportement attendu de l’application (Le besoin), le clarifie en faisant la chasse aux manquements et aux zones d’ombres du besoin, assure la bonne transmission de l’attendu entre le référent et le développeur, et vérifie finalement la conformité du produit au comportement attendu. Pour résumer voici les trois facettes du travail d’un testeur :

Le rôle principal : vérifier la conformité de l’application au besoin
Le Bon testeur : Assurer la bonne transmission du comportement attendu de l’application tout au long du projet
L’excellence : Participer activement à la bonne spécification du besoin dès les premières phases du projet

Ces différentes facettes du travail d’un testeur nécessite comme tout autre métier de la rigueur, tel un inspecteur qui scrute les recoins de l’application pour détecter tout écart avec les spécifications. Et de noter minutieusement toutes les étapes par lesquelles il est passé pour détecter l’anomalie pour permettre au développeur de la reproduire avant de la corriger. Un bon testeur communique « beaucoup », il en faut pour assurer la transmission du comportement voulu par l’utilisateur aux membres de l’équipe de développement. et de faire des retours sur l’état d’avancement et la qualité du produit. Un excellent testeur communique « bien » et a un rapport empathique avec ses interlocuteurs : il sait se mettre à leurs places. Un projet est un ensemble de personnes travaillant pour atteindre un objectif commun. Une personne n’est pas qu’un tas de connexions de neurones, il est un être émotionnel. Le relationnel du testeur est donc indispensable : quand il détecte une anomalie il doit savoir en discuter avec le développeur sans heurter sa sensibilité et le pousser à se mettre à la défensive. Un excellent testeur communique « bien » aussi en étant à l’écoute des besoins de l’utilisateur et des retours et contraintes de l’équipe de développement. Le contenu de cet article est corrigé ou enrichi grâce à vous, n’hésitez pas à me laisser vos remarques et vos contributions dans la zone de commentaires.

08 Oct

GENERALBy Anir RADID

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.

08 Oct

GENERALBy Anir RADID

Comment prédire la fin d’un projet de test

Les indicateurs d’analyse

L es indicateurs que nous avons vu dans l’article « Comment construite le tableau de bord d’un projet de test » sont 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.

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 d’utiliser de vraies données pour ses prévisions et communique en toute transparence sur les incertitudes du projet.

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.

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).

08 Oct

GENERALBy Anir RADID

Comment prédire la fin des tests

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 ?

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.

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.

Est ce qu’on aurait tout fini à une date donnée ?

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 d’utiliser de vraies données pour ses prévisions et communique en toute transparence sur les incertitudes du projet.

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.

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).

31 Mar

GENERALBy Anir RADID

Comment construire un tableau de bord pour un projet de test

J’ ai vu beaucoup de projets présenter les résultats de leurs campagnes de test par de simples compteurs de type :

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

J’ai aussi vu l’inconfort des responsables de tests de ces projets quand le client leur pose des questions légitimes mais auxquelles leurs indicateurs simplistes ne sont pas capables de fournir une réponse.

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 compteurs de base ne permettent effectivement pas de répondre à ces questions car elles poussent à voir la phase de test comme un stock de cas de tests à dérouler jusqu’à épuisement, un paradigme binaire (stock rempli, stock vide) et avare de possibilités. A la fin de cet article vous saurez comment constituer vos indicateurs de test et construire un tableau de bord adapté à votre projet de test. Vous aurez aussi des moyens simples et pratiques de prédire l’évolution future de votre projet de test (en fin d’article). Vous pouvez télécharger gratuitement le modèle detableau de bord GTT en bas de cet article. Il existe plusieurs définitions au test, mais elle s’accordent toutes à l’assimiler à une comparaison entre un objet testé et une référence de test, le résultat de cette comparaison est une information sur la qualité de l’objet test. On n’attend pas d’une équipe de test d’améliorer la qualité du produit testé – c’est le travail des développeurs – mais on attend de l’équipe de test de rendre compte clairement de la qualité actuelle de l’application. Le responsable de test doit alors construire un tableau de bord qui renseigne clairement sur la qualité actuelle de l’application testée, qu’il puisse mesurer cette qualité. Mais comment mesurer une notion aussi abstraite que la qualité logicielle ?

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.

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.

06 Mar

GENERALBy Anir RADID

Comment faire un planning pour un projet de test

Un planning est une projection dans le temps des activités d’un projet.forme d’une TreeMap.

Un planning est essentiel pour :

Susciter l’engagement
Donner de la visibilité
et Pousser à l’action

Pour créer un planning il faut :

Décomposer le projet en tâches
Estimer les durées des tâches
Prévoir la disponibilité de l’équipe
Renseigner les dates clés du projet
Dessiner le planning en respectant les contraintes : de durée, de disponibilité et de livraison

L’ISTQB dans son syllabus avancé « Gestionnaire de test » décompose le processus de test en 8 activités principales, mais un planning n’en exige heureusement que 3 :

Pilotage: Planification, Suivi, Contrôle, évaluation des critères de sortie, reporting et Clôture
Préparation : Analyse, conception et implémentation
Exécution : Exécution et reporting

Les activités de pilotage étant permanentes ne seront pas représentées dans le planning.

Un projet simple aura par conséquent un planning composé de 2 tâches et ressemblera alors au graphique ci-dessous :

1- Estimer les durées des tâches

Chaque tâche de préparation et d’exécution doit avoir une durée. La durée d’une tâche de préparation/exécution est la somme de toutes les durées de préparation/exécution des fonctionnalités contenus dans le lot correspondant. Pour en savoir plus sur les techniques d’estimation consulter l’article Comment estimer un projet de test.

2 – Prévoir la disponibilité de l’équipe

Collecter les absences planifiées des membres de l’équipes et prévoir aussi les absences non planifiées (maladies, montée en compétence lente, déplacements,…etc)

Un outil de planification doit proposer un tableau facilitant cette collecte et son utilisation.

3 – Renseigner les contraintes de dates

Lister toutes les dates clés pouvant impacter le planning.

La date mise en production
Les dates de livraison
Les dates de disponibilité de l’infrastructure
Les dates de validation des spécifications
…

4 – Dessiner le planning en respectant les contraintes

Chaque case du tableau de planning correspond à une durée et une disponibilité.

La règle du jeu est de compléter les cases en ayant comme objectif:

Faire baisser le RAF à zéro
Garder la capacité restante au dessus de zéro

Veiller à la cohérence avec les dates de livraison des spécifications validées et des lots de l’application développés.