En quelques années, les méthodes agiles sont devenues majoritaires dans les cycles de développement logiciel. Et leur progression n'est pas terminée ! Ces changements rapides créent de nombreuses difficultés, notamment en matière de tests, où de nombreuses entreprises ou équipes en charge du développement ne savent pas comment les mettre en œuvre.
Ces problèmes proviennent souvent d'un manque de compréhension de l'agilité. Lorsque cette compréhension et le bon état d'esprit sont intégrés, il est alors plus facile de mettre en œuvre efficacement les approches et bonnes pratiques liées aux tests et plus particulièrement à la qualité en Agile.
Les particularités de l'Agile
Les développements agiles présentent deux particularités qui les distinguent fortement du cycle en V traditionnel :
- Les méthodes agiles sont des méthodes de développement itératives
- Les méthodes agiles proposent de ne livrer que des versions utilisables et "finies".
Les méthodes agiles sont des méthodes de développement itératives
Ce point est particulièrement important et est la conséquence d'une partie du manifeste Agile :
des logiciels opérationnels plutôt qu'une documentation exhaustive.
Cela contraste immédiatement avec le cycle en V, où les spécifications sont entièrement rédigées en amont avant de commencer le développement.
Dans le cas des méthodes agiles, le produit est "livré" et développé par petites briques. Le produit est en constante évolution. On peut le comparer à une tour Kapla. Le produit existe dans une version N puis est modifié par l'ajout d'une brique, ce qui en fait une version N+1. Ces petites modifications fréquentes et successives obligent à s'assurer à chaque fois que la nouvelle version du produit correspond toujours à ce qui est attendu... augmenté de sa nouvelle fonctionnalité (la nouvelle brique).
Il est particulièrement important de garder cela à l'esprit ! Lorsque des méthodes agiles sont utilisées, le produit, qui est fréquemment livré, croît et évolue. En revanche, dans le cas du cycle en V, une tour complète est directement proposée. Elle n'est donc pas destinée à évoluer rapidement. Cette différence de paradigme a un fort impact sur les tests, qui doivent :
- Vérifier en profondeur et rapidement le comportement de chaque petite modification
- S'assurer par une campagne de régression que la nouvelle fonctionnalité n'a pas cassé le produit.
- Mettre à jour la régression avec les nouvelles caractéristiques du produit (ou les modifications)
Le premier point explique la démocratisation des tests exploratoires, qui permettent de multiplier les tests en un temps limité. De plus, il est intéressant de noter que les tests exploratoires permettent également d'identifier certaines régressions ou anomalies non encore détectées.
Le deuxième point montre l'importance de l'automatisation des tests ! En effet, les tests de campagne de régression sont exécutés régulièrement (idéalement au moins une fois par nouvelle fonctionnalité (User Story)) et pour assurer un nombre suffisant de tests sans mettre en péril la capacité de l'équipe à livrer. Pour le moral des testeurs, il est également essentiel d'automatiser autant que possible les tests de campagne de régression.
Le troisième point est là pour nous rappeler qu'une campagne de régression doit être vivante... et cela est particulièrement vrai pour un produit qui est également vivant.
Les méthodes agiles proposent de ne livrer que des versions utilisables et "finies".
Il s'agit d'un point particulièrement important. Le produit livré par l'équipe de développement est un produit composé de fonctionnalités "finies".
L'un des problèmes récurrents dans les transformations Agile est la place des tests. Certains voient les sprints comme des mini-cycles en V, d'autres font des sprints de développement suivis de sprints de tests.... Ce n'est pas Agile ! Ce n'est ni plus ni moins que des V-cycles de plus courte durée.
En Agile, la notion de " fini " est essentielle ! Même si elle diffère selon les équipes (chaque équipe a son propre Definition of Done (DoD)) et l'évolution du produit (La DoD peut évoluer entre chaque sprint), il est essentiel de se rappeler d'une chose : lorsqu'une fonctionnalité est "terminée", on n'y touche plus !
Vous devez donc vous assurer que tous les éléments nécessaires au produit sont fournis à chaque livraison pour être utilisés et continuer à évoluer.
Cela inclut inexorablement :
- Les tests pour valider la nouvelle fonctionnalité
- Les tests unitaires des développeurs
- Toute la documentation jugée nécessaire
- Les tests de régression liés à la nouvelle fonctionnalité
- Le logiciel dans sa nouvelle version...
Il est donc inconcevable de considérer que le produit est fini s'il n'a pas été testé. Les sprints de test en dehors du développement sont donc totalement anti-agiles... Cette situation est parfaitement compréhensible lorsque l'équipe de développement travaille en Agile, qu'elle a effectué une certaine quantité de travail et qu'elle ne peut plus absorber de charge de travail (ni une charge de travail qui ne peut être anticipée). Cette situation se produit nécessairement lorsqu'une campagne de tests est réalisée sur le produit.
De même, les sprints ne peuvent pas être des cycles en V. Ce mode de fonctionnement crée un risque énorme : celui de ne rien livrer. Il ne faut pas non plus oublier la difficulté d'identifier la raison des régressions si elles apparaissent lorsque le produit a subi de nombreuses modifications (plusieurs US au lieu d'un).
Exemples de pratiques de test dans une équipe agile
Pour s'adapter aux méthodes agiles, les tests se sont adaptés ! Il y a évidemment la mise en place de l'automatisation et l'émancipation des tests exploratoires mais pas seulement !
Parmi ces bonnes pratiques, il y a notamment :
Le BDD
Contrairement au cycle V où il était possible de revoir les spécifications en amont des développements, l'Agile ne propose pas de documents exhaustifs et précis en amont des sprints. Néanmoins, il existe des exigences identifiées, décrites et priorisées par l'entreprise ou son représentant (le PO ou Product Owner dans Scrum). Ces exigences sont généralement sous forme de User Stories et peuvent faire l'objet de revues dans le but de se synchroniser sur l'exigence et d'avoir une compréhension commune. C'est tout l'objet du BDD ! Les différents acteurs (le PO, un testeur et un développeur pour les 3 amigos) se réunissent et illustrent la User Story avec des exemples pour décrire le comportement attendu.
Le DevOps
Je parle ici de "DevOps", mais en général on pourrait parler de "test continu", de"shift right" ou simplement d'interactions entre différents acteurs. L'idée ici est de connaître toute la chaîne de notre produit depuis l'identification du besoin jusqu'à l'utilisation en production en passant par le développement et les tests. Afin d'assurer cette communication et la fluidité des tests, une chaîne d'intégration continue comprenant des tests de différents types est généralement mise en place.
Le peer testing
Le test par les pairs est une pratique intéressante où un testeur assiste le développeur pendant que ce dernier développe. Cela permet des échanges et l'identification d'anomalies potentielles à un stade très précoce.
Le peer/mob programming
La peer programing n'est pas nécessairement une pratique Agile (comme le peer testing) mais on la retrouve principalement dans ces environnements. Le principe est d'avoir un duo (ou plus pour le "mob") de développeurs avec une personne qui écrit le code et les autres qui servent de réviseurs. Cela permet aux nouveaux arrivants de gagner en compétences mais aussi de proposer un code avec moins de défauts.
Ingénierie logicielle
L'artisanat logiciel est une approche du développement où la qualité de la conception est primordiale. Les logiciels doivent être bien conçus et développés. Pour cela, de nombreuses pratiques de développement pour assurer une bonne qualité sont mises en avant. Je pense notamment au TDD(Test Driven Development)
Il existe évidemment de nombreuses autres pratiques liées à la qualité logicielle en Agile qui peuvent être particulièrement efficaces selon le contexte.
Les tests dans une équipe agile, en résumé
Les tests agiles et la qualité des produits ne sont pas seulement l'apanage des testeurs ! Un produit de qualité est le résultat de l'investissement de tous les acteurs qui y travaillent. Les bonnes pratiques sont nombreuses et il faut savoir sélectionner les plus pertinentes dans son contexte. Il est important de noter que " l'automatisation " ne fait pas partie des " bonnes pratiques " proposées, car au-delà d'une pratique, l'automatisation est avant tout une étape qui s'impose très rapidement dans la construction de tout logiciel avec des méthodes agiles. Il existe évidemment des bonnes pratiques liées à l'automatisation mais cela pourrait faire l'objet d'un ou plusieurs articles dédiés !
.png)
