Gestion de projet – Vers les méthodes agiles
162
Poussé à l’extrême, le test peut même devenir central. On parle de pilotage par les
tests, pratique qui consiste à rédiger les scénarios de test avant le code, puis de
n’écrire que le code minimal pour faire passer le test avec succès. Le cycle comporte
cinq étapes : écrire un premier test, vérifier qu’il échoue (car le code qu’il teste
n’existe pas), écrire le minimum de code suffisant pour faire passer le test, vérifier
que le test passe, puis refactoriser le code. Le code est donc testable unitairement, on
évite ainsi une conception hasardeuse puisque le développeur s’interroge sur la façon
dont le module va être utilisé.
Comment faire l’impasse sur une phase finale dédiée aux tests ? Car il est impossible de tout
tester dans chaque itération (suite)
Je suis convaincu que tous les tests peuvent être automatisés. En pratique, tous les projets
agiles que j’ai connus avaient quelques tests non automatisés parce que leur automatisation
aurait coûté trop cher. L’automatisation est plus facile si elle a été mise en place progressivement dès le début du projet. La meilleure façon d’amortir le coût d’automatisation des tests est
d’utiliser le principe des « spécifications exécutables ». Les tests sont exprimés sous une
forme qui est à la fois lisible comme une spécification, et exécutable par un outil. Ainsi, le travail
de spécification et de définition des tests est mis en commun, et l’exécution des tests est
gratuite. Il y a de nombreuses techniques ou outils disponibles (notamment FIT), l’idéal étant
que la définition de ces spécifications exécutables soit techniquement à la portée du client, de
la maîtrise d’ouvrage ou des utilisateurs.
En quoi le pilotage par les tests est-il un facteur d’accélération des développements et de
réduction des coûts ? L’infrastructure et l’organisation à mettre en place sont coûteuses !
La réponse de l’expert Pascal Pratmarty, consultant indépendant et ingénieur expérimenté en
développement logiciel.
Tout le monde reconnaît aujourd’hui les vertus des tests automatiques. C’est un véritable bulletin de santé du projet, réactualisable en permanence, qui forme un filet de sécurité efficace
contre les régressions fonctionnelles : l’équipe peut ainsi engager plus sereinement les développements de nouvelles fonctionnalités et les remaniements internes.
Qu’apporte donc de plus un pilotage par les tests ?
Dans un environnement où 100 % des tests doivent passer, un test qui échoue constitue un excellent fil directeur pour le développement : son introduction rompt l’équilibre d’un système, et le rétablissement de cet équilibre mobilise alors toute l’énergie de l’équipe. Il évite les phénomènes de
dispersion si couramment vécus dans les projets logiciels. Par exemple, s’il arrive au cours de la
résolution d’un test que nous songions à un cas de figure non prévu, notre mode d’action par
défaut est celui-ci : nous notons ce point sur un papier, terminons le travail en cours, puis traduisons le nouveau problème sous la forme du prochain test à résoudre. Le résultat est extrêmement
satisfaisant et réconfortant, car la batterie de tests représente à tout moment le témoin fidèle de
l’état du système. Si un besoin change, nous modifions d’abord le test correspondant, car son
échec justifie et sécurise notre intervention dans le code de production.
GestProjInform Livre Page 162 Vendredi, 3. avril 2009 12:07 12
162
Poussé à l’extrême, le test peut même devenir central. On parle de pilotage par les
tests, pratique qui consiste à rédiger les scénarios de test avant le code, puis de
n’écrire que le code minimal pour faire passer le test avec succès. Le cycle comporte
cinq étapes : écrire un premier test, vérifier qu’il échoue (car le code qu’il teste
n’existe pas), écrire le minimum de code suffisant pour faire passer le test, vérifier
que le test passe, puis refactoriser le code. Le code est donc testable unitairement, on
évite ainsi une conception hasardeuse puisque le développeur s’interroge sur la façon
dont le module va être utilisé.
Comment faire l’impasse sur une phase finale dédiée aux tests ? Car il est impossible de tout
tester dans chaque itération (suite)
Je suis convaincu que tous les tests peuvent être automatisés. En pratique, tous les projets
agiles que j’ai connus avaient quelques tests non automatisés parce que leur automatisation
aurait coûté trop cher. L’automatisation est plus facile si elle a été mise en place progressivement dès le début du projet. La meilleure façon d’amortir le coût d’automatisation des tests est
d’utiliser le principe des « spécifications exécutables ». Les tests sont exprimés sous une
forme qui est à la fois lisible comme une spécification, et exécutable par un outil. Ainsi, le travail
de spécification et de définition des tests est mis en commun, et l’exécution des tests est
gratuite. Il y a de nombreuses techniques ou outils disponibles (notamment FIT), l’idéal étant
que la définition de ces spécifications exécutables soit techniquement à la portée du client, de
la maîtrise d’ouvrage ou des utilisateurs.
En quoi le pilotage par les tests est-il un facteur d’accélération des développements et de
réduction des coûts ? L’infrastructure et l’organisation à mettre en place sont coûteuses !
La réponse de l’expert Pascal Pratmarty, consultant indépendant et ingénieur expérimenté en
développement logiciel.
Tout le monde reconnaît aujourd’hui les vertus des tests automatiques. C’est un véritable bulletin de santé du projet, réactualisable en permanence, qui forme un filet de sécurité efficace
contre les régressions fonctionnelles : l’équipe peut ainsi engager plus sereinement les développements de nouvelles fonctionnalités et les remaniements internes.
Qu’apporte donc de plus un pilotage par les tests ?
Dans un environnement où 100 % des tests doivent passer, un test qui échoue constitue un excellent fil directeur pour le développement : son introduction rompt l’équilibre d’un système, et le rétablissement de cet équilibre mobilise alors toute l’énergie de l’équipe. Il évite les phénomènes de
dispersion si couramment vécus dans les projets logiciels. Par exemple, s’il arrive au cours de la
résolution d’un test que nous songions à un cas de figure non prévu, notre mode d’action par
défaut est celui-ci : nous notons ce point sur un papier, terminons le travail en cours, puis traduisons le nouveau problème sous la forme du prochain test à résoudre. Le résultat est extrêmement
satisfaisant et réconfortant, car la batterie de tests représente à tout moment le témoin fidèle de
l’état du système. Si un besoin change, nous modifions d’abord le test correspondant, car son
échec justifie et sécurise notre intervention dans le code de production.
GestProjInform Livre Page 162 Vendredi, 3. avril 2009 12:07 12