Suivre et piloter son projet
CHAPITRE 5
163
La stratégie de tests détermine également l’organisation à mettre en place : au-delà des
développeurs qui procèdent aux tests unitaires, comment s’organisent les activités de
tests ? Y a-t-il des ressources dédiées ? Quelle doit être la disponibilité des utilisateurs ou
de leur représentant pour les régulières campagnes de tests de validation ? C’est la raison
pour laquelle la stratégie, si elle se définit au niveau de chaque projet, doit également être
déterminée au niveau de l’organisation en fonction des moyens à déployer pour sa mise
en œuvre.
La stratégie de tests définit, en outre, les critères d’évaluation d’une campagne de tests :
taux de couverture des fonctionnalités, taux de réussite des tests, nombre de défauts
mineurs, majeurs, et bloquants…
Chaque test reflète directement le détail d’une conversation autour d’une user story : il doit être
clair et ne comporter aucune ambiguïté. Organisés et présentés soigneusement, ils rendront
inutile l’écriture (et surtout la maintenance) de tout document intermédiaire d’expression
détaillée des besoins. C’est une économie considérable !
Enfin, contrairement aux idées reçues, les coûts de mise en place de l’infrastructure ne sont pas
si élevés. L’environnement de test évolue de façon incrémentale comme le code de production. Il
est essentiel de soigner cet environnement afin que les tests restent toujours simples à écrire
ou modifier.
Comment procéder aux tests dans chaque itération si l’on dispose d’un pool de testeurs
dans une équipe transversale aux projets ?
La réponse de l’expert Jean Tabaka, coach et agile mentor chez Rally Software Development.
Dans les organisations où un pool de testeurs est censé répar tir sa contribution entre plusieurs
équipes, les bénéfices de l’agilité sont grandement réduits. Le principe de partager des ressources introduit des temps d’attente pour la ressource test et potentiellement de longs retards dans la
réalisation complète des fonctionnalités. Dans cet environnement de ressource raréfiée, les équipes finissent par terminer le développement d’une fonctionnalité, puis démarrer le développement
d’une autre sans vraiment connaître l’état de la fonctionnalité. Il y a une mauvaise perception de
l’achèvement. Il y a une faille dans la découverte ou la prévention des défauts, puisque l’équipe
attend que le testeur soit disponible pour réaliser les tests fonctionnels.
Parce que les développeurs passent à un autre jeu de fonctionnalités, les testeurs sont
contraints de maintenir un outil d’enregistrement des défauts. Ainsi, l’achèvement des fonctionnalités repose sur quelque chose d’incomplet. Par voie de conséquence, l’équipe agile ne peut
pas livrer ces fonctionnalités à l’issue de l’itération. Et cela crée la même illusion d’achèvement
que dans un cycle en cascade où les activités de test commencent une fois tous les développements terminés.
Le partage des ressources dédiées aux tests repose sur une hypothèse d’économie d’échelle. « Si
nous partageons cette ressource, cela reviendra moins cher pour nous de mener les tests pour
tous les projets. » Toutefois, cette économie d’échelle ne tient pas quand l’équipe de développement doit s’attaquer à un travail continuel de correction au fur et à mesure que les défauts sont
découverts, enregistrés, se dégradent, se chevauchent les uns les autres. Une ressource
dédiée à temps complet élimine ce travail de correction.
GestProjInform Livre Page 163 Vendredi, 3. avril 2009 12:07 12
CHAPITRE 5
163
La stratégie de tests détermine également l’organisation à mettre en place : au-delà des
développeurs qui procèdent aux tests unitaires, comment s’organisent les activités de
tests ? Y a-t-il des ressources dédiées ? Quelle doit être la disponibilité des utilisateurs ou
de leur représentant pour les régulières campagnes de tests de validation ? C’est la raison
pour laquelle la stratégie, si elle se définit au niveau de chaque projet, doit également être
déterminée au niveau de l’organisation en fonction des moyens à déployer pour sa mise
en œuvre.
La stratégie de tests définit, en outre, les critères d’évaluation d’une campagne de tests :
taux de couverture des fonctionnalités, taux de réussite des tests, nombre de défauts
mineurs, majeurs, et bloquants…
Chaque test reflète directement le détail d’une conversation autour d’une user story : il doit être
clair et ne comporter aucune ambiguïté. Organisés et présentés soigneusement, ils rendront
inutile l’écriture (et surtout la maintenance) de tout document intermédiaire d’expression
détaillée des besoins. C’est une économie considérable !
Enfin, contrairement aux idées reçues, les coûts de mise en place de l’infrastructure ne sont pas
si élevés. L’environnement de test évolue de façon incrémentale comme le code de production. Il
est essentiel de soigner cet environnement afin que les tests restent toujours simples à écrire
ou modifier.
Comment procéder aux tests dans chaque itération si l’on dispose d’un pool de testeurs
dans une équipe transversale aux projets ?
La réponse de l’expert Jean Tabaka, coach et agile mentor chez Rally Software Development.
Dans les organisations où un pool de testeurs est censé répar tir sa contribution entre plusieurs
équipes, les bénéfices de l’agilité sont grandement réduits. Le principe de partager des ressources introduit des temps d’attente pour la ressource test et potentiellement de longs retards dans la
réalisation complète des fonctionnalités. Dans cet environnement de ressource raréfiée, les équipes finissent par terminer le développement d’une fonctionnalité, puis démarrer le développement
d’une autre sans vraiment connaître l’état de la fonctionnalité. Il y a une mauvaise perception de
l’achèvement. Il y a une faille dans la découverte ou la prévention des défauts, puisque l’équipe
attend que le testeur soit disponible pour réaliser les tests fonctionnels.
Parce que les développeurs passent à un autre jeu de fonctionnalités, les testeurs sont
contraints de maintenir un outil d’enregistrement des défauts. Ainsi, l’achèvement des fonctionnalités repose sur quelque chose d’incomplet. Par voie de conséquence, l’équipe agile ne peut
pas livrer ces fonctionnalités à l’issue de l’itération. Et cela crée la même illusion d’achèvement
que dans un cycle en cascade où les activités de test commencent une fois tous les développements terminés.
Le partage des ressources dédiées aux tests repose sur une hypothèse d’économie d’échelle. « Si
nous partageons cette ressource, cela reviendra moins cher pour nous de mener les tests pour
tous les projets. » Toutefois, cette économie d’échelle ne tient pas quand l’équipe de développement doit s’attaquer à un travail continuel de correction au fur et à mesure que les défauts sont
découverts, enregistrés, se dégradent, se chevauchent les uns les autres. Une ressource
dédiée à temps complet élimine ce travail de correction.
GestProjInform Livre Page 163 Vendredi, 3. avril 2009 12:07 12