Tribunes

« Test agile » ou « test dans un projet agile »

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 !

Publicité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 oeuvre 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 oeuvre 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 a la nécessité de tester

Les projets agiles n'échappent pas a 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 oeuvre 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.

Publicité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 oeuvre 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 Développement Piloté par les Tests)
- 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 oeuvre

Une question de contexte de mise en oeuvre

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 !

Article rédigé par

Eric Riou du Cosquer, Trésorier du CFTL (Comité Français des Tests Logiciels)
Eric Riou du Cosquer est Trésorier du CFTL (Comité Français des Tests Logiciels) et Test Manager Senior chez France Télécom

Diplômé de l'Ecole d'Ingénieurs de Brest (Informatique Industrielle), Eric Riou du Cosquer a commencé sa carrière en 2000, en qualité de Chef de Projet au sein des sociétés CSC PeatMarwick, puis Softeam de 2000 à 2003, avant de rejoindre la division R&D de France Télécom, dans le cadre des projets CATI et APSYS. Depuis 2007, Eric exerce en qualité de Consultant et Formateur pour le Centre de Compétences Test de France Télécom (ROSI/DDSI).
Depuis 2002, il a dispensé plusieurs conférences et formations dans le domaine des tests de logiciels. En tant qu'expert, Eric Riou du Cosquer est également membre du groupe de travail international pour la définition du Syllabus Avancé de l'ISTQB, Responsable de la création de la version française et Président du Club utilisateurs de Mercury France.
Il a également participé à la définition et à la mise en oeuvre du processus de qualification de FT division R&D, ainsi qu'à l'audit de l'utilisation des outils de gestion de tests et anomalies sur différents projets, côté fournisseurs.