Maîtriser les projets avec l'Extreme Programming
Le pilotage par les tests-client
| Accueil | Les chapitres | Wiki Wiki Web | Liens | Contact |

Le pilotage par les tests-client s'inscrit dans les cycles courts de l'Extreme Programming (version et itération). Si les "histoires" du client, les user stories (scénarios) sont les identifiants des spécifications, ce sont ensuite les échanges entre développeurs et client qui permettront de préciser le besoin.
Plus précisément, les spécifications de tests de validation (anciennement nommés tests d'acceptance dans XP) ou tests-client sont autant de précisions sur les spécifications. Ils possèdent une propriété que n'a pas une expression de besoins classique, à savoir la possibilité offerte au client de "se forger une opinion", définition même du "test".

Le client définit ainsi le périmètre d'une version et, à l'intérieur, le périmètre de chaque itération. Si la mise au point de l'itération est basée sur les histoires et leur pondération en "point" (poids de la réalisation), ce sont bien les tests-client qui valideront - ou non - l'implémentation effectuée par le collège des développeurs.
Le but des développeurs est alors de faire en sorte que les tests-client passent.

Si, à l'issue d'une itération, certains tests sont évalués à "KO", alors le client a la possibilité de ré-injecter la même histoire dans l'itération suivante, sa pondération étant réévaluée par les développeurs en fonction du résultat des tests.

Les tests-client sont alors le "deal" passé entre client et développeurs. Ils forment un ensemble fini de cas de test. En supposant un certain équilibre obtenu entre tous les tests (en terme de durée de développement associée) il est alors possible de considérer la métrique :
n OK / total tests.

Par ailleurs, la métrique : n tests-client/poids de l'histoire permet d'apprécier le nombre de tests associés. Les équipiers auront établi relativement rapidement un nombre "moyen" pertinent de tests par type de demande. Une variation sensible par rapport à ce nombre moyen est alors une "alerte" qui permet d'analyser plus avant la gestion de l'histoire en question. Schématiquement, cette métrique offre une idée du nombre de tests par unité d'estimation (jeton ou point).
Autrement dit, supposons un jeton défini comme une "semaine idéale de développement". Si une histoire est évaluée à 2 jetons, et est munie de 10 tests-client, alors le ratio est de 10/2 soit 5 tests par "semaine idéale". Une demande toujours évaluée à 2 jetons mais armée uniquement de 2 tests aura un ratio de 2/2 soit 1 test par semaine idéale.



^ top ^        © 2004       Contact