Développer des logiciels en mode Agile nécessite de délivrer de la valeur aux clients de manière régulière, par sprint d'un mois, deux semaines ou même une semaine. Il est donc essentiel de mettre en place une politique de validation des logiciels bien testée, sinon vos efforts seront réduits à néant par la présence de nombreux bugs.
En effet, si vous souhaitez livrer de nouvelles fonctionnalités sur un logiciel, tester ces nouvelles fonctionnalités n'est pas suffisant car une modification du logiciel peut également impacter les fonctions livrées précédemment. Dans ce cas, il est également nécessaire de repasser un ensemble de tests dits de "non-régression" sur les fonctions existantes, dont le nombre peut rapidement augmenter au fur et à mesure que vous livrez de nouvelles versions.
Il existe plusieurs possibilités pour valider un produit logiciel rapidement et avec un effort limité. Chacune d'entre elles comporte un certain niveau de risque que vous devez assumer : vous pouvez obtenir une qualité infinie avec des ressources infinies !
Analyse d'impact des changements de code logiciel
L'analyse d'impact des modifications de code consiste à évaluer l'ensemble des tests à rejouer en fonction du code modifié.
Lorsqu'elle est bien maîtrisée, cette technique permet de réduire considérablement le plan de validation.
Une bonne coordination est nécessaire entre les équipes de développement et les testeurs pour s'assurer que rien n'est oublié. Cette technique permet même d'envisager à l'avance et de limiter les modifications qui seront apportées, afin de livrer plus rapidement, lors d'un refactoring de code par exemple.
Comment valider partiellement les fonctionnalités d'un logiciel
Vous pouvez organiser vos sprints et vos livraisons en versions mineures et majeures afin que seul un sous-ensemble prioritaire de vos tests de non-régression soit effectué lors de la livraison des versions mineures.
Une règle de Pareto bien maîtrisée vous permettra d'identifier 20% de vos tests qui valideront 80% des fonctionnalités, et vous pourrez vous concentrer sur les tests des nouvelles fonctionnalités.
Un bon accord avec votre client vous permettra d'utiliser des versions mineures uniquement pour présenter et valider un principe de travail ou une proposition de conception UX, mais certainement pas pour les déployer en production.
Pour préparer la prochaine version majeure sans perdre trop de temps à la valider, vous pouvez commencer à faire votre non-régression globale de manière incrémentielle au fur et à mesure que vous produisez les versions mineures précédentes, en utilisant l'analyse d'impact de chacune des versions mineures pour déterminer l'ordre de relecture 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 permet de limiter les plans de tests à rejouer une fois la version majeure développée. Pour mettre en œuvre cette technique, il est préférable d'organiser vos sprints mineurs du plus impactant (gros refacto de bas niveau par exemple) au moins impactant (finalisation des interfaces graphiques) afin de limiter la casse sur les derniers sprints mineurs.
Et cette méthode ne vous permet pas de mettre en place un processus de validation continu et fluide car elle nécessite toujours une phase de stabilisation de votre version majeure.
Comment automatiser la validation des fonctionnalités d'un logiciel
L'intérêt de mettre en place une validation automatisée lorsqu'on fait de l'Agile est évident : si le coût de production d'un test automatisé est généralement plus cher que de simplement le rejouer manuellement, la validation automatisée commence à être rentable à partir d'un certain nombre de versions validées et livrées.
Il vous permet de livrer votre logiciel à tout moment : il suffit de rejouer votre plan de test automatisé (et éventuellement certains tests manuels que vous n'avez pas pu automatiser), ce qui est plus rapide qu'un plan de test entièrement manuel.
Cependant, la mise en œuvre de la validation automatisée souffre de deux problèmes majeurs : les testeurs n'ont généralement pas les compétences en développement informatique : les testeurs n'ont généralement pas certaines compétences en codage nécessaires pour utiliser les outils du marché, et la robustesse des tests générés fait souvent défaut et nécessite un important maintenance.
C'est dans le but de répondre à ces deux points que nous avons créé Agilitest : Le test fonctionnel continu est désormais une réalité avec Agilitest, découvrez notre solution d'automatisation des tests.
.png)
