Agilité : 3 solutions pour valider rapidement les fonctionnalités d’un logiciel ?

par Christophe Cressend | 30 décembre 2020

Développer des logiciels en mode Agile nécessite de délivrer régulièrement de la valeur à ses clients, en sprint réguliers d’un mois, de deux semaines, voire d’une semaine. Il est donc primordial de mettre en oeuvre une politique de validation logicielle très rodée, sous peine de voir ses efforts réduits à néants par la présence de nombreux bugs.

En effet, si vous souhaitez délivrer de nouvelles fonctionnalités sur un logiciel, tester ces nouveautés n’est pas suffisant car une modification logicielle peut aussi impacter des fonctions précédemment délivrées. Il faut aussi dans ce cas rejouer un ensemble de tests dits « de non régression » sur les fonctions existantes, et dont le nombre peut rapidement augmenter au fur et à mesure que vous délivrez des versions.

Il existe plusieurs possibilités permettant de valider un logiciel rapidement et en limitant ses d’effort, chacune d’entre elle comporte un certain de niveau de risque qu’il faudra assumer : un peu faire une qualité infinie avec des ressources infinies, encore faut-il savoir ou mettre la barre !

L’analyse d’impact des modifications du code logiciel

L’analyse d’impact des modifications du code consiste à évaluer l’ensemble des tests à rejouer en fonction du code modifié. Bien maitrisé, cette technique permet de réduire drastiquement le plan de validation. Une bonne coordination est nécessaire entre les équipes de développement et les testeurs pour s’assurer que rien ne sera laissé de côté. Cette technique permet même d’envisager à l’avance et limiter les modifications qui seront réalisées, de façon à livrer plus rapidement, dans le cadre d’un refacto par exemple.Il existe un certain nombre d’outils qui vont tracer les cheminements de l’ensemble de vos tests dans votre code logiciel, et par analyse inverse, vous indiquerons quels tests rejouer en fonction des modifications réalisées.

La validation partielle

Vous pouvez organiser vos sprint et vos livraisons en mineures et majeures pour ne réaliser qu’un sous ensemble prioritaire de vos tests de non régressions lors de la livraison des versions mineures. Un règle de Pareto bien maitrisée vous permettra d’identifier 20% de vos tests qui validerons 80% des fonctionnalités, et vous pourrez vous focaliser sur les tests des nouveautés. Une bonne entente avec votre client vous permettra d’utiliser les versions mineures uniquement pour présenter et valider un principe de fonctionnement ou une proposition d’UX Design, mais certainement pas pour déployer en production.

Pour préparer la version majeure suivante sans perdre trop de temps à la valider, vous pourrez commencer à faire votre non régression globale de manière incrémentale lors de la production des versions mineures précédentes, en utilisant l’analyse d’impact de chacune des versions mineures à suivre pour déterminer l’ordre de rejeu de votre régression globale. Cette méthode est risquée dans la mesure où vous ne réalisez pas votre non régression sur la version finale, mais elle peut limiter les plans de tests à rejouer une fois la version majeure développée. Pour mettre en oeuvre cette technique, il est préférable d’organiser ses sprints mineurs du plus impactant (grosse refacto bas niveau par exemple) au moins impactant (finalisation des IHMs) de façon à limiter la casse sur les derniers sprints mineurs.

La validation automatisée

L’intérêt de mettre en oeuvre la validation automatisée lorsqu’on fait de l’Agilité est évident : si le coût de production d’un test automatisé est en général plus coûteux que de simplement rejouer celui-ci manuellement, la validation automatisée commence à être rentable à partir d’un certain nombre de versions validées et délivrées, et elle vous permet de livrer votre logiciel à tout moment : il suffit de rejouer votre plan de tests automatisés (et éventuellement quelques tests manuels que vous n’aurez pas pu automatiser), ce qui est plus rapide qu’un plan de tests complètement manuels. La mise en oeuvre de la validation automatisée souffre cependant de deux problèmes majeurs : les testeurs n’ont généralement pas les compétences en développement informatique pour utiliser les outils d’automatisation du marché, et la robustesse des tests générés fait souvent défaut et engendre une maintenance importante. Comment adresser ces deux points fera l’objet de la prochaine publication.