Ne confondez pas« Test Agile » ou « Test dans un projet agile »
Faut-il parler de « Test Agile » ou de « Test dans un projet Agile » : une fausse question à mon avis, d’autant plus que les définitions existantes pour le terme « Test Agile » ne font pas l’unanimité… Le concept de « Test dans un projet Agile », en revanche, semble tout à fait pertinent.
Projet Agile ou pas, il n’y a qu’un test valable, celui qui permet d’augmenter la satisfaction des utilisateurs et la rentabilité des développements !Il y a eu le phénomène « Off-Shore », soulevant des questions spécifiques au test, comme celle qui visait à déterminer s’il fallait parler de « Test Off-Shore » ou de « Test de l’Off-Shore », les deux pouvant bien sûr avoir du sens.
De même aujourd’hui, faut-il parler de « Test Agile » ou de « Test dans un projet Agile » : une fausse question à mon avis, d’autant plus que les définitions existantes pour le terme « Test Agile » ne font pas l’unanimité… Le concept de « Test dans un projet Agile », en revanche, semble tout à fait pertinent.
Il est inconcevable de ne pas tester. Une chose est sûre, il n’est pas concevable de ne pas tester et ceci quel que soit le cycle de vie de développement logiciel en vigueur. Un DSI n’intègrera pas dans son SI des applications, s’il sait qu’elles n’ont pas été testées, et de la même manière, un éditeur de logiciel ne vendra pas un logiciel sans l’avoir testé : projet Agile ou pas, il est nécessaire de tester et c’est pour cela que l’on peut être amené à faire du « Test dans un projet Agile ».
Le test doit s’appuyer sur des
incontournables. Tester
c’est bien, bien tester c’est mieux. Certes, mais comment faire la différence
entre le bon et le mauvais test ?
De
mon point de vue, bien tester consiste à mettre en œuvre un ensemble de
principes incontournables, en les complétant par des compétences fonctionnelles
et techniques spécifiques et, en les adaptant au mode de développement. En
d’autres termes, le test doit s’appuyer sur des incontournables qui seront
déployés de différentes façons pour différents modes de développement y compris
l’Agile. On peut citer comme incontournables, la nécessité de documenter les
tests en s’appuyant sur la description des caractéristiques fonctionnelles ou
non-fonctionnelles à tester, la nécessité de documenter leurs résultats, la
possibilité de vérifier la traçabilité entre l’expression d’un besoin et les
exigences, tests ou développements associés, le recours à un outillage adapté
qui permettra de faire mieux et plus vite, ou encore, la mise en œuvre d’un
processus, consistant à identifier différents niveaux de test et à concevoir,
implémenter, puis exécuter les tests à chaque niveau. Tous ces incontournables,
sans exception, doivent se retrouver sur un projet Agile.
Les projets Agiles n’échappent pas à la
nécessité de tester. De
même qu’il y a ceux qui pensent faire de la prose sans en faire, il y a ceux
qui pensent faire de l’Agile sans en faire, simplement parce qu’ils y ont pris
ce qui les arrangeait et ont laissé tomber tout le reste, notamment la
documentation des tests, ou encore l’usage d’outils d’exécution des tests contribuant
pourtant à la mise en œuvre d’un principe important dans l’Agilité qui est
l’industrialisation.
Citons par exemple un projet rencontré récemment, prétendant
fonctionner en mode Agile, selon la méthode « SCRUM »… et
pourtant :
* les « user stories » n’étaient
que très succinctement décrites, sans aucune indication sur la façon de les
tester.
* aucun test unitaire n’était automatisé ni
même simplement documenté, ni dans un
sprint, ni après livraison d’un sprint.
Ces
manquements exposaient le projet à de grands risques de qualité et de
satisfaction des utilisateurs, ce qu’une démarche Agile permet normalement
d’éviter.
Le test présente des particularités dans un projet Agile
Autant
le terme de « Test Agile » ne semble pas apporter grand-chose, autant
l’expression « Test dans un projet Agile » a du sens.
La
démarche Agile ne repose pas uniquement sur des itérations et des échanges dans
l’équipe, mais aussi et surtout sur l’optimisation de la valeur
« business » de ce qui est produit, ce à quoi le test peut fortement
contribuer.
Les
incontournables du test logiciel doivent être mis en œuvre dans un projet Agile.
Ils pourront l’être de façon plus naturelle et parfois différente, comme pour les exemples qui
suivent :
- Une exigence et les tests associés pourront se retrouver décrits dans le même élément, la User Story ; il s’agit là de conception des tests fonctionnels.
- Les tests unitaires, portant sur le code développé, pourront être décrits avant que le code ne soit développé ; il s’agit là de conception des tests unitaires en mode « TDD » (Test Driven Development ou Test Piloté par les Développements).
- Les tests techniques et fonctionnels seront automatisés, autant que possible, afin de pouvoir être exécutés à la fin de chaque tâche d’un sprint et également pour alimenter un référentiel de tests de régression utilisé à la fin de chaque sprint et dans différents environnements, développement et intégration par exemple.
- Une même personne pourra être à la fois développeur et testeur, ce qui peut surprendre, mais qui en fait a tout son sens, puisque l’automatisation de tests fonctionnels ou techniques est une tâche de développement.
Une
autre particularité du Test dans un projet Agile est l’utilisation d’outils
parfois différents des outils utilisés pour les projets qui suivent un cycle de
vie classique, comme le cycle en V.
Un
outil de gestion de backlog pourra être considéré comme un outil de gestion des
exigences et de conception des tests fonctionnels, puisqu’on y trouvera les
User Stories incluant une procédure de test. On peut citer quelques outils de
test open source appréciés sur les projets Agiles, tels que « Fitnesse »
(test de règles métier, au niveau du code, sans passer par l’IHM),
« Selenium » (test d’IHM, avec génération de code modifiable) ou
encore « Hudson » (outil d’administration des différentes tâches et
outils de test).
Une question de contexte de mise en œuvre
En
conclusion, je dirais que tous les principes fondamentaux et les
incontournables du test logiciel, tels ceux recensés par les différents Syllabi
de l’ISTQB, se retrouvent sur un projet Agile. Le schéma des 4 quadrants, conçu
par Brian Marick il y a près de 10 ans pour illustrer le test sur les projets
Agiles le montre bien ; à l’exception des « Tests sur
Storyboards » tout ce qui y figure fait partie des bases du test logiciel.
Projet
Agile ou pas, il n’y a qu’un test valable, celui qui permet d’augmenter la
satisfaction des utilisateurs et la rentabilité des
développements !
|
|