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 !





 

Autour du même sujet