Suivre et piloter son projet
CHAPITRE 5
161
Pour éviter d’en arriver à ce genre de raisonnement tout à fait justifié, il est fortement souhaitable de pouvoir automatiser les tests fonctionnels réalisés à la fin de chaque itération de la
même manière que sont automatisés les tests unitaires. Dans ce cas de figure :
– les régressions sont détectées dès leur injection et le coût de leur correction est minime ;
– le test fonctionnel est spécifié une seule fois mais exécuté x fois.
Pour en revenir à la question, il est alors possible de tout tester à chaque fin d’itération.
2) La réponse de l’expert David Gageot, directeur technique chez Tech4Quant.
Idéalement, on ne devrait livrer que ce qui est testé. C’est la notion de « done » dans Scrum.
Toutefois, il est toujours très intéressant de laisser une application aux mains de vrais utilisateurs. Pour ce faire, on laissera à chaque itération l’application en libre accès sur un serveur de
test et on sera à l’écoute de remontées d’anomalies.
On peut également proposer une phase finale de recette fonctionnelle, plus classique. Cette
recette pourra être courte car elle se focalisera sur le fonctionnel. Les bogues techniques
auront été détectés beaucoup plus tôt.
3) La réponse de l’expert Dominic Williams, coach XP.
Il est forcément possible de tester, dans une itération, tout ce qui a été produit dans cette itération. Au besoin, on produit moins et on teste plus.
La difficulté vient de la nécessité de tester à nouveau tout ce qui a été développé et testé
précédemment. La solution réside dans l’automatisation.
L’existence d’une phase finale dédiée aux tests introduit un laps de temps et un coût considérable entre ce que font les développeurs et ce que peuvent obtenir les utilisateurs. Il devient
alors impossible de faire des livraisons fréquentes, clé de voûte de l’agilité. En outre, elle introduit la perception selon laquelle il est acceptable, voire normal, que ce que produisent les
développeurs contienne des défauts.
Il y a deux ingrédients indispensables à l’élimination de cette phase :
– Tous les tests doivent être automatisés.
– Lorsque, malgré les tests existants, un défaut est découvert, il ne faut jamais se contenter de
le corriger : il faut aussi se demander comment on aurait pu éviter ce défaut et comment désormais éviter tous les défauts du même genre. Cela peut impliquer un changement de process,
de conception, ou l’ajout d’une autre technique de test...
Ainsi, les développeurs reçoivent un feedback rapide sur leur travail : d’abord en exécutant
eux-mêmes, chaque fois qu’ils le souhaitent, les tests automatisés ; ensuite de la part des utilisateurs.
Le principe consiste à livrer souvent une petite quantité de travail de très bonne qualité, et d’en
tirer immédiatement les leçons afin que les livraisons suivantes soient d’encore meilleure
qualité.
Prétendre qu’on peut tout tester dans chaque itération revient donc à prétendre que tous les
tests peuvent être automatisés – ou au moins qu’il reste si peu de tests non automatisés qu’on
peut facilement les réaliser dans chaque itération.
☞
GestProjInform Livre Page 161 Vendredi, 3. avril 2009 12:07 12
CHAPITRE 5
161
Pour éviter d’en arriver à ce genre de raisonnement tout à fait justifié, il est fortement souhaitable de pouvoir automatiser les tests fonctionnels réalisés à la fin de chaque itération de la
même manière que sont automatisés les tests unitaires. Dans ce cas de figure :
– les régressions sont détectées dès leur injection et le coût de leur correction est minime ;
– le test fonctionnel est spécifié une seule fois mais exécuté x fois.
Pour en revenir à la question, il est alors possible de tout tester à chaque fin d’itération.
2) La réponse de l’expert David Gageot, directeur technique chez Tech4Quant.
Idéalement, on ne devrait livrer que ce qui est testé. C’est la notion de « done » dans Scrum.
Toutefois, il est toujours très intéressant de laisser une application aux mains de vrais utilisateurs. Pour ce faire, on laissera à chaque itération l’application en libre accès sur un serveur de
test et on sera à l’écoute de remontées d’anomalies.
On peut également proposer une phase finale de recette fonctionnelle, plus classique. Cette
recette pourra être courte car elle se focalisera sur le fonctionnel. Les bogues techniques
auront été détectés beaucoup plus tôt.
3) La réponse de l’expert Dominic Williams, coach XP.
Il est forcément possible de tester, dans une itération, tout ce qui a été produit dans cette itération. Au besoin, on produit moins et on teste plus.
La difficulté vient de la nécessité de tester à nouveau tout ce qui a été développé et testé
précédemment. La solution réside dans l’automatisation.
L’existence d’une phase finale dédiée aux tests introduit un laps de temps et un coût considérable entre ce que font les développeurs et ce que peuvent obtenir les utilisateurs. Il devient
alors impossible de faire des livraisons fréquentes, clé de voûte de l’agilité. En outre, elle introduit la perception selon laquelle il est acceptable, voire normal, que ce que produisent les
développeurs contienne des défauts.
Il y a deux ingrédients indispensables à l’élimination de cette phase :
– Tous les tests doivent être automatisés.
– Lorsque, malgré les tests existants, un défaut est découvert, il ne faut jamais se contenter de
le corriger : il faut aussi se demander comment on aurait pu éviter ce défaut et comment désormais éviter tous les défauts du même genre. Cela peut impliquer un changement de process,
de conception, ou l’ajout d’une autre technique de test...
Ainsi, les développeurs reçoivent un feedback rapide sur leur travail : d’abord en exécutant
eux-mêmes, chaque fois qu’ils le souhaitent, les tests automatisés ; ensuite de la part des utilisateurs.
Le principe consiste à livrer souvent une petite quantité de travail de très bonne qualité, et d’en
tirer immédiatement les leçons afin que les livraisons suivantes soient d’encore meilleure
qualité.
Prétendre qu’on peut tout tester dans chaque itération revient donc à prétendre que tous les
tests peuvent être automatisés – ou au moins qu’il reste si peu de tests non automatisés qu’on
peut facilement les réaliser dans chaque itération.
☞
GestProjInform Livre Page 161 Vendredi, 3. avril 2009 12:07 12