Cet article a été écrit et est paru dans le livre du CFTL « Les tests en agile« . La qualité de la mise en plage est par conséquent nettement meilleur sur le livre. Néanmoins, le contenu reste le même
1- Introduction.
L’Agilité est une approche de développement logicielle totalement différente des approches
classiques comme le cycle en V.
L’approche agile adoptant un état d’esprit (ou une vision) différent du développement des logiciels,
tous les maillons de la chaîne de développement sont impactés et doivent s’adapter à
cette nouvelle manière de procéder, de penser. Le test est également impacté en tant que
maillon prépondérant de la chaîne du développement logiciel.
Afin de bien comprendre les principales divergences entre un cycle de développement dit
classique et un cycle de développement agile, j’aime utiliser une analogie : celle de la
construction d’un pont.
Pour construire un pont en adoptant une méthode comparable au cycle en V :
- On fait les plans, on fait
intervenir les architectes et on vérifie la conformité aux
normes (durée : 6 mois). - On commence la construction par les piliers (durée : 4 mois).
- On finit la
construction, on vérifie l’ensemble des normes de construction (durée : 7
mois) - On annonce l’ouverture et on prépare l’arrivée des automobilistes (durée : 1 mois)
- Ouverture du pont
Bilan : Le projet dure 18 mois. Les automobilistes peuvent donc raccourcir leur trajet au bout de 18 mois.
Si on devait construire un pont en adoptant une méthode comparable à une
méthode agile :
Attention, cela n’est pas forcément instinctif. Il faut revenir à la base. Quel
est le souhait des
automobilistes ? Le souhait n’est pas d’avoir un pont ! Non, le souhait est de
ne plus avoir à faire 40 minutes de trajet supplémentaire tous les matins.
Le projet de pont en méthode agile se présenterait donc ainsi :
- Faire venir (ou acheter) un ou
plusieurs bateaux pour faire des allers-retours et
permettre aux automobilistes de gagner l’autre rive – certes moins vite qu’avec un pont,
mais beaucoup plus qu’en faisant le détour – (durée : 2 mois). - On fait les
plans et on fait intervenir les architectes, on vérifie la conformité aux
normes
(durée : 6 mois) et on adapte aux retours des utilisateurs si besoin (ex : trottoirs si
beaucoup de piétons, plus de voies si trafic important…). - Pendant que
les bateaux font leurs allers-retours et que de l’argent commence à
rentrer, le pont est construit, en commençant par les piliers (durée : 6 mois car il ne faut
pas déranger les bateaux).
Les plans peuvent être modifiés en fonction de l’utilisation des bateaux (bacs) - On finit la
construction, on vérifie l’ensemble des normes de construction à chaque
étape (durée : 9 mois, toujours pour ne pas déranger les bateaux). - On annonce l’ouverture prochaine aux utilisateurs des bateaux (1 mois)
- Ouverture du pont.
Bilan : Le projet dure 24 mois, soit 6 mois de plus que le cycle en V. Ce même projet coûte
également plus cher car il a fallu acheter ou louer les bateaux. En revanche, le service pour faire traverser le fleuve a été opérationnel au bout de 2 mois au lieu de 18 (mais on a accès au pont au bout de 24 mois).
Conclusion :
Il n’y a pas de bonnes ou de mauvaises méthodes. A périmètre égal et défini au début du projet,
une méthode agile peut coûter plus cher qu’une méthode classique, notamment à cause des
tests qui prendront une part plus importante (car exécutés beaucoup plus fréquemment).
L’intérêt principal des méthodes agiles est d’arriver plus rapidement sur le marché pour pouvoir
adapter son périmètre en fonction des retours et des besoins exprimés pas les utilisateurs. Un
développement agile coûtera beaucoup moins cher qu’un développement classique nécessitant
des reprises, car ce dernier ne correspond pas (ou plus) au besoin.
Nous voyons bien, à travers cet exemple, que la manière de fonctionner avec un esprit « agile » est nettement différente de la manière « classique ». Les tests dans une méthode agile vont
prendre une place plus importante que dans une méthode classique. Le test d’un logiciel coûte
plus cher en agile que dans un cycle en V !
Les raisons principales sont :
- L’accès régulier à de nouvelles versions du logiciel par des utilisateurs finaux.
- Cet accès régulier à de nouvelles versions « force » l’équipe agile à tester intégralement son produit avant chaque mise à disposition. Là où un cycle en V ne proposait qu’une seule phase de test, les méthodes agiles peuvent en proposer des dizaines !
- Une construction itérative.
- Lorsque l’on construit de manière itérative un produit, on se retrouve à avoir comme matériau de base pour notre construction ce que l’on a déjà développé. Notre produit devient alors les fondations de notre produit futur.
- Pour avoir une construction solide, il faut partir sur de bonnes bases. Le produit étant la base, sa qualité (fonctionnelle ou non) ne peut être négociée et il faut donc des tests afin de s’assurer que le niveau de qualité suffisant est atteint.
L’organisation
des tests en Agile doit donc s’adapter à ces 2 points. Pour cela, il n’y a pas
de
solution unique. Néanmoins, grâce à l’apparition des équipes
pluridisciplinaires et à une
communication qui s’en trouve améliorée, il n’y a rien d’insurmontable !
2- Organiser les tests afin de pouvoir
livrer de manière régulière de nouvelles
versions du produit.
Comme décrit dans la partie précédente, l’Agilité permet de livrer régulièrement de nouvelles
fonctionnalités d’un produit utilisable. Afin que cette promesse ne soit pas vaine, il faut :
- Assurer que les nouvelles fonctionnalités aient une vraie valeur ajoutée.
- Assurer que les nouvelles fonctionnalités soient vraiment utilisables.
- Assurer que les anciennes fonctionnalités soient encore utilisables.
Voici un
schéma permettant d’appréhender la différence d’échelle entre les mises en
service
avec le cycle en V et avec des méthodes agiles :
Afin de répondre au premier point, l’Agilité propose une gestion des demandes à travers un « backlog » et sa priorisation. Les fonctionnalités à développer sont sélectionnées à partir de ce backlog. Le rôle des tests sur ce point est de questionner la pertinence de la fonctionnalité présentée lors des réunions permettant de décrire ces besoins.
Les tests sont primordiaux pour répondre au second point. A chaque nouvelle livraison, un produit propose une ou plusieurs fonctionnalités ainsi qu’un ou plusieurs correctifs d’anomalies. Afin de répondre à ce besoin, il faut donc prévoir des tests pour valider ces correctifs et ces fonctionnalités.
Pour cela, il faut concevoir, écrire et exécuter ces tests pendant l’itération. Il devient donc
nécessaire de pouvoir commencer à travailler sur les tests avant la livraison des spécifications (s’il y en a) et avant la livraison du code. Cela engendre naturellement de nouvelles pratiques, comme l’ATDD ou le BDD même si cela n’est pas forcément obligatoire. Ce qui est en revanche obligatoire, c’est que tous les membres de l’équipe soient capables d’aider sur des tâches du test. Comme dans tout développement, les charges de test sont sujettes à des pics, pendant lesquels le(s) testeur(s) aura(ont) besoin d’aide, et des creux pendant lesquels le testeur devra aider sur des tâches autres que les tâches de test.
Enfin, et c’est la partie la plus importante, les tests doivent également permettre d’assurer que ce qui a été construit lors des itérations précédentes est toujours en état de fonctionner. Les utilisateurs peuvent être compréhensifs lorsqu’ils n’arrivent pas à utiliser une nouvelle fonctionnalité implémentée, ils le sont en revanche beaucoup moins lorsqu’une fonctionnalité qu’ils ont l’habitude d’utiliser, devient inutilisable suite à une mise en service. Afin de limiter au maximum ces problèmes, l’équipe se doit de tester, au moins avant chaque mise en service, les anciennes fonctionnalités de son produit. Pour cela il faut exécuter les tests de régression (souvent appelés tests de non régression). Ces tests de régression sont fréquemment exécutés, il est donc intéressant de prévoir de les automatiser.
En fait, en Agilité, on se retrouve avec une organisation des tests qui peut ressembler à celle-ci :
Dans l’image ci-contre, les tests vitaux correspondent à un sous-ensemble des tests de régression, les tests de validation sont les tests permettant de valider le comportement de la nouvelle fonctionnalité et les tests de régression correspondent à la campagne regroupant les tests utilisés, afin d’assurer que les nouvelles fonctionnalités n’ont pas introduit de régression majeure sur le produit.
Enfin, toujours dans le cadre de l’Agilité, il peut être très intéressant de mettre en place des sessions de tests exploratoires. Ces tests permettent de gagner du temps sur la conception et l’écriture mais aussi de lutter contre le paradoxe des pesticides en exécutant régulièrement des tests différents.
3- Organiser ses tests afin de gérer,
sur le long terme, une construction itérative
du produit.
Même si l’on parle de « sprint » avec le Scrum, un produit agile n’est pas quelque chose que
l’on construit sur du court terme (à quoi bon faire de l’itératif si l’on peut construire un produit en moins de 2 mois ?). Un produit agile est un produit qui peut se construire sur plusieurs années (certaines applications mail mobiles ont largement dépassé les 5 ans !) et peuvent ainsi devenir complexes et comporter un très grand nombre de fonctionnalités. Cela oblige donc à avoir des campagnes de régressions performantes tout en maintenant une durée d’exécution, de maintenance et d’analyse restreinte.
C’est pour cette raison que la campagne des tests de régression est complexe à gérer et devient la source de nombreux problèmes pouvant amener à une fin de vie prématurée du produit. Afin d’avoir une bonne campagne de régression, il faut :
Eviter de faire de la sur-qualité.
Il arrive régulièrement qu’une équipe agile, pas assez mature d’un point de vue test, souhaite faire de la sur-qualité en intégrant tous ses tests dans la campagne de régression. Cette démarche ne peut fonctionner qu’à court terme ! A moyen terme, le nombre de tests à maintenir, exécuter et analyser devient insoutenable car en constante croissance, l’équipe en arrive donc à un point où elle a le choix entre ne plus maintenir et exécuter les tests, ou passer tout son temps sur des tâches de test ! Les deux solutions sont mauvaises.
Bien sélectionner ses tests de régression.
La sélection des tests de régression doit se faire dès la conception des tests d’une fonctionnalité. Les tests de régression étant les seuls à devoir être ré-exécutés ils doivent faire l’objet d’une attention particulière en permettant notamment une automatisation aisée. Pour rappel, afin d’avoir une automatisation aisée il faut, au minimum, avoir des scripts bien écrits (1 action => 1 résultat (ou plusieurs)), des résultats stables (ne dépend pas du jour ou de l’heure) et fiables (vérifie ce qu’il y a vraiment à vérifier).
Cette sélection doit être faite en fonction de la criticité du parcours ainsi que de sa probabilité de défaillance.
Enfin, comme toute sélection, on ne doit prendre qu’une partie des tests qui ont servi à valider la fonctionnalité.
Maintenir sa campagne de tests de régression.
Une campagne de test non maintenue est pire que pas de campagne du tout ! La raison est
simple : avec une campagne non maintenue, l’équipe garde l’illusion que son produit est protégé par des tests permettant de repérer les bugs majeurs ou critiques. Ce n’est malheureusement pas le cas ! Les membres de l’équipe sachant que leur campagne n’est pas maintenue n’analysent pas les tests constamment en échec. Pire, quand il y a trop de tests non maintenus, l’équipe n’analyse plus du tout la campagne, même si cette dernière est exécutée automatiquement.
Afin d’éviter ces problèmes, il est nécessaire de maintenir sa campagne de régression. Cette maintenance doit être faite de différentes manières, en voici quelques-unes :
– Mettre à jour ses cas de tests dès qu’ils sont impactés par un nouveau développement ajouté au produit.
– Lutter contre le paradoxe des pesticides : pour cela, les tests exploratoires sont une très bonne réponse mais pas forcément suffisante. Afin d’améliorer l’efficacité de la campagne de régression, il est conseillé de modifier des tests qui ne sont jamais en échec en proposant par exemple des jeux de données différents.
– Supprimer des tests s’avérant inutiles.
– Enrichir les campagnes aves des tests couvrant de nouvelles fonctionnalités
– Supprimer les tests les moins importants afin de garder un volume de tests que l’on peut exécuter, analyser et maintenir.
Automatiser ses tests.
L’automatisation des tests devient une nécessité avec les méthodes
incrémentales. Aucun testeur ne peut ré-exécuter manuellement plusieurs fois
par semaine pendant des années les mêmes tests. Afin de préserver les testeurs
(mais aussi le temps de l’équipe agile), il est nécessaire d’automatiser une
partie de ses tests.
Pour cela, de nombreux outils et méthodes ont émergé. Il existe notamment
l’ATDD et le BDD qui visent à faire des tests une documentation vivante du
produit (et donc de n’avoir que les tests à maintenir plutôt que les tests et
la documentation), mais aussi à faciliter l’automatisation par l’intermédiaire
de mots clés et de l’homogénéisation de l’écriture des cas de test.
4- L’Agilité à l’échelle.
Construire un produit grâce aux méthodes agiles, c’est bien. Néanmoins, il
n’est généralement
question que de l’équipe agile. Or une équipe agile, c’est en théorie entre 5
et 9 personnes.
Il est malheureusement impossible sur certains projets ou produits de ne faire
travailler que
5 à 9 personnes.
Pour ce type de produit, plusieurs équipes doivent travailler ensemble. Afin de
synchroniser ces équipes, il faut mettre en place des processus leur permettant
de toutes travailler dans le même sens. Pour cela, diverses méthodes ont été
créées, elles sont appelées «Agilité à l’échelle ».
Actuellement, les 2 modèles dominants sont les modèles « Spotify » et « SAFe ». Dans ce livre, vous avez également un retour d’expérience sur le « Scrum of Scrum ».
Exemple d’organisation sur l’Agilité à l’échelle :
Chacun de ces modèles a ses spécificités mais ils gardent tous des points communs qui sont :
On ne négocie pas la qualité du produit.
Ce point ne nécessite pas forcément une forte adaptation. Néanmoins, chaque nouvelle
fonctionnalité étant ajoutée sur le produit global, il est important d’avoir accès à des campagnes de tests d’autres équipes afin de vérifier si nos développements n’ont pas impacté négativement les autres équipes.
Afin de repérer ces impacts le plus rapidement possible, il peut être intéressant d’avoir une base de tests vitaux (voire plus) commune, voire une équipe dédiée à la supervision de ces tests de régression du produit.
Il est bon de regrouper les personnes ayant les mêmes compétences au sein de groupes de compétences.
Plus les produits nécessitent de personnes pour être développés, plus il y a des compétences communes dispersées dans les différentes équipes. Permettre à ces personnes de se regrouper et d’échanger sur leurs expériences, problèmes et succès permet de faire gagner du temps à toutes les équipes.
Ces mêmes groupes peuvent travailler à la mise en place d’outils ou pratiques communs qui seront bénéfiques à l’ensemble des équipes agiles travaillant sur le projet.
Cela est vrai pour le test mais pas uniquement. Exemple pour le Scrum of Scrum :
Les équipes agiles doivent communiquer entre elles car elles travaillent toutes sur le
même produit.
Les équipes travaillant sur le même produit sont nécessairement dépendantes les unes des
autres. L’équipe A peut se retrouver à attendre un développement de l’équipe B tandis que l’équipe C peut créer une régression dans une fonctionnalité développée par l’équipe B… Afin de limiter ces risques, les équipes doivent se synchroniser, savoir comment ces risques impactent les autres équipes mais aussi ce que les autres équipes attendent d’elles.
Sans communication et organisation, les équipes finissent par perdre beaucoup de temps avec des corrections d’anomalies, de l’attente de fonctionnalités voire des développements incompatibles nécessitant de redévelopper entièrement certaines parties du produit.
5- Conclusion.
L’organisation des tests en Agile n’a rien à voir avec l’organisation des tests
dans les méthodes classiques. Le changement de méthode de développement induit
un changement d’état d’esprit, la livraison de nouvelles versions du produit de
manière très fréquente, de même que la création de produits de manière
incrémentale engendre de nouveaux besoins. Ces besoins trouvent des réponses
(processus, automatisation, tests exploratoires, ATDD/BDD…) qui sont d’un point
de vue macroscopique très génériques mais qui vont devoir être adaptées à
chaque équipe d’afin d’atteindre un niveau optimal.
Enfin, l’Agilité à l’échelle ajoute une couche supplémentaire de complexité et
oblige les membres de chaque équipe agile à ne pas penser uniquement à elle
mais à tout un environnement constitué de plusieurs équipes agiles.
Enfin, l’Agilité à l’échelle ajoute une couche supplémentaire de complexité et oblige les membres de chaque équipe agile à ne pas penser uniquement à elle mais à tout un environnement constitué de plusieurs équipes agiles.
N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances
Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles
N’hésitez pas à faire vos propres retours d’expérience en commentaire.
