Toutes les équipes de développement agiles ne sont pas forcément dotées de test de non-régression (TNR) automatisées. Comment faire dans ce cas pour livrer fréquemment en production, à chaque fin de sprint par exemple, si l’équipe ne dispose pas d’automate de test ? Une équipe est-elle vraiment agile si n’est pas capable de livrer souvent ? Heureusement, de bonnes idées, empruntées au modèle en cascade, vont nous aider.
Même si de plus en plus d’équipes se mettent aux pratiques du Software Craftsmanship et du DevOps, certaines n’en sont qu’au début de leur histoire et expérimentent en premier des pratiques agiles autour des interactions et de la collaboration. Ces dernières ne sont donc pas forcément au fait des pratiques et de l’outillage qui leur donnerait un haut niveau de confiance dans la qualité des livrables dès la fin du sprint. Parmi ces équipes, nombreuses sont celles qui essayent de livrer en production juste après un sprint. Comment font-elle pour vérifier manuellement la non-régression dans ce cas? pendant le sprint ? alors que de nouvelles fonctionnalités sont toujours en cours de réalisation ? Mauvaise idée !
Les tests unitaires ne sont pas des tests de non-régression
Certaines équipes investissent sur l’automatisation des tests unitaires en croyant qu’ils garantiront la non-régression de l’application mais ce n’est pas le cas. Cet article décrit bien les différents types de test et leurs objectifs. Les tests de non-régression permettent de s’assurer que le comportement de l’application n’a pas été altéré par les modifications apportées ou bien si c’est le cas, que cela est parfaitement sous contrôle.
Des TNR manuels à la fin du sprint
Lorsqu’une équipe n’est pas équipée de tests de non-régression automatisés, chaque fin de sprint doit s’accompagner d’une période dédiée aux TNR manuels. La durée de cette période est à corréler au nombre de testeurs, au niveau de risque que l’équipe est prête à prendre et à la quantité de fonctionnalités à tester. Cela peut aller de quelques jours à plusieurs mois. Si la volonté de l’équipe est de livrer après chaque sprint, il est nécessaire que la durée des TNR ne dépasse pas la durée d’un sprint.
Le modèle en cascade pour nous aider
Nous pouvons reprendre l’exemple du modèle en cascade présenté ci-dessus pour organiser la définition du besoin, les développements ainsi que les tests. J’entend déjà les agilistes crier à l’hérésie mais laissez moi un peu de temps pour m’expliquer.
En Scrum, seules les user stories correctement définies (INVEST) sont candidates pour le prochain sprint. En effet, accepter des user stories incomplètes dans le sprint revient à prendre le risque de ne pouvoir le terminer. Les personnes en charge de la définition du besoin ont pour mission d’avoir préparé suffisamment de user stories prêtes pour le prochain sprint. Ces personnes peuvent s’aider d’un tableau kanban représentant la maturité des user stories et stocker les candidates au prochain sprint dans une colonne “Ready to dev” par exemple.
Le backlog de sprint pourra s’alimenter à partir des user stories candidates qui auront été sélectionnées par le product owner. Le sprint se termine, non pas quand la dernière user story est terminée mais quand la date de fin de sprint est atteinte. L’équipe se sera organisée pour terminer le développement des user stories engagées, les valider fonctionnellement et désactiver le code de celles qui n’auront pu être validées. Dès lors, les tests de non-régression peuvent commencer mais aussi le nouveau sprint.
Le schéma ci-dessus montre comment les sprints peuvent s’enchaîner sans attendre que les TNR soient terminés. Les TNR sont réalisés sur le contenu du sprint précédent et non pas sur le nouveau sprint en cours de développement. Pour que la fréquence de livraison soit la même que celle des sprints, il est important que la durée des TNR ne dépasse pas la durée des sprints.
Quand vous disposez de TNR automatisés, la non-régression peut être testée tous les jours, voir plusieurs fois par jour. Par exemple, dans une précédente mission, les TNR étaient joués toutes les nuits et duraient 6 heures. Ils ont remplacé les campagnes de tests manuels réalisés par deux testeurs pendant deux à trois semaines.
Développer et faire des TNR en même temps
Il n’est pas nécessaire d’attendre la fin des TNR du sprint N pour commencer le développement du sprint N+1. Les TNR du sprint N sont menés en parallèle des développement du sprint N+1. Les développeurs auront pris soin d’isoler le code source produit au sprint N des nouveaux développements prévus pour le sprint N+1. Ainsi, lorsqu’un bug est détecté pendant les TNR du sprint N, il doit à la fois être corrigé dans le code de la version du sprint N mais aussi dans le sprint N+1. Cela permet de ne livrer que le contenu du sprint N et ses corrections sans les nouvelles fonctionnalités du sprint N+1 qui ne sont pas encore testées.
Conclusion
Il est possible de livrer fréquemment en production même si l’équipe ne dispose pas encore de tests de non-régression automatisés. Les TNRs manuels démarrent dès la fin du sprint, en parallèle du démarrage du nouveau sprint. Les développeurs doivent veiller à bien isoler les corrections issues des TNRs, des nouveaux développements à l’aide de mécanismes permettant la gestion des branches de développement et des versions.
En investissant sur les TNRs automatisés, l’équipe réduira la durée de la compagne de TNR à quelques heures et s’autorisera à les jouer pendant le sprint, sur les développements en cours, pour une détection au plus tôt des problèmes. Cela permettra une couverture bien plus large des scénarios de production. Si l’équipe cherche à améliorer la qualité de ses livrables et son time to market, elle a tout intérêt à étudier l’automatisation de ses TNRs. Dès lors qu’elle aura pris goût à l’automatisation et à l’amélioration continue, il est fort probable que l’équipe s’intéresse de près aux pratiques Software Craftsmanship et DevOps qui finiront par lui ouvrir les portes de la livraison continue.
photo credit: Scott Sanford Photography _MG_7816 via photopin (license)
