La dernière édition de la Journée française des tests logiciels, dont Best Practices et Benchmark Digital & Business étaient partenaires, a été l’occasion de dresser le panorama de l’état de l’art dans ce domaine, autour de l’automatisation et de la collaboration.
Dans la mesure où la fréquence des livraisons de versions d’applications s’est considérablement accélérée, les tests doivent être effectués plus souvent et plus vite, sans compromettre la qualité. « Dans une approche de type cycle en V, avec entre deux et quatre versions majeures d’applications par an, une à deux versions de tests par mois sont généralement suffisantes. Dans un mode agile, avec une à trois versions d’applications par trimestre, il faut au moins une à deux versions de test par semaine », conseille Vittorio Capellano, Test Practice Leader chez Acial.
Dans un contexte de cycle agile et DevOps, avec plusieurs versions majeures par mois d’applications, les tests doivent être réalisés sur un rythme quasi-quotidien. « L’automatisation des tests est devenue une réponse logique à l’accélération de la fréquence des versions, les pratiques et outils ont accompagné cette évolution », assure Vittorio Capellano, pour qui le choix du modèle d’automatisation doit résulter d’une analyse conjointe de facteurs humains (ressources et compétences), techniques (technologies et outils) et opérationnels (approches et bonnes pratiques).
Choisir le ou les bons outils reste une étape cruciale pour la réussite du projet d’automatisation. « Le contexte actuel voit une multiplication d’outils et de frameworks avec une recherche d’innovation permanente dans les fonctionnalités proposées. Le choix doit résulter d’une analyse combinée de plusieurs paramètres : économiques (investissement initial et maintenabilité long terme, open source vs éditeur), techniques (couverture du périmètre applicatif, environnement technique, fonctionnalités avancées) et humains (ressources impliquées et niveaux de compétences, adéquation avec le niveau de technicité de l’outil) », explique Vittorio Capellano.
Ce dernier suggère six bonnes pratiques en matière d’automatisation :
- Ne pas se précipiter. Il convient de réfléchir à la maturité des tests manuels, d’identifier les tâches répétitives et de bien organiser le projet d’automatisation. D’une part, pour le pilotage (choix structurants sur l’outil et l’organisation, planification de l’activité, capitalisation des bonnes pratiques, maintien de l’effort sur le long terme et justification du ROI). D’autre part, pour la réalisation (mise en place des outils et des pratiques, création, calibrage et maintenance des scripts automatisés, organisation de l’exécution, suivi et résolution des non conformités).
- Choisir le bon niveau pour automatiser. Il s’agit d’appréhender les avantages et inconvénients des différentes approches combinant outils et ressources.
- Ne pas oublier l’IHM (Interface Homme-Machine). Certains bugs ne sont que visuels (décalages, superpositions…) et ne seront pas détectables par un script, même s’il s’exécute sur l’IHM. « Ils seront visibles à l’œil nu, mais pas forcément sur tous les environnements (terminaux, navigateurs…), il ne s’agit évidemment pas non plus de comparer des images au pixel près », précise Vittorio Capellano.
- Optimiser la structure des scripts. Les premiers scripts automatisés seront souvent complexes et rigides, rendant difficile une exécution fréquente. Pour Vittorio Capellano, « un script automatisé doit posséder certaines caractéristiques de qualité, comme pour un projet de développement et le refactoring des tests automatisés constitue une bonne pratique. Ainsi, un test automatisé non optimisé sera toujours préférable à aucun test automatisé… ».
- Anticiper l’intégration de l’outil dans la chaîne de fabrication. Un script automatisé ne peut pas être conçu pour fonctionner de façon isolée, il doit pouvoir être exécuté à l’identique sur de multiples environnements. « Dès la conception, et parfois dès le choix de l’outil, il faut se poser la question des environnements à couvrir, en choisissant un outil qui communique bien avec l’écosystème des outils de l’organisation », suggère Vittorio Capellano.
- Adopter une approche collaborative. Cela évite de travailler en silo. « Cela renforce le lien entre testeurs et développeurs et favorise la collaboration autour de l’effort d’automatisation », assure Vittorio Capellano.
Cette exigence de collaboration a été développée, lors de la Journée française des tests logiciels, par Jean-Pierre Lambert, consultant créateur de Scrum Life, une chaîne YouTube francophone sur l’agilité. Pour lui, la collaboration, « signe d’une véritable agilité » a plusieurs caractéristiques : « travailler ensemble, se parler, partager ses compétences, ainsi que son propre mode de fonctionnement, et connaître les autres. » La collaboration agile se focalise sur la valeur et l’amélioration continue. Pour favoriser la collaboration, Jean-Pierre Lambert conseille d’appliquer cinq principes :
- Réfléchir ensemble : les membres de l’équipe doivent définir ensemble les plannings de sprint et réaliser des estimations collectives, depuis la conception jusqu’au déploiement.
- Prévoir et animer une réunion quotidienne, pour identifier ce qui reste à faire et ce qui a été réalisé.
- Privilégier le délai de production : « Souvent, on se concentre sur la productivité, mais c’est facile de contourner ce critère : il suffit d’augmenter le nombre de tickets et cela n’incite pas à aider les autres, car la productivité diminuerait encore plus », remarque Jean-Pierre Lambert, pour qui il faut se focaliser sur le temps de cycle.
- Privilégier le pair-programming, « à l’image des pilote et co-pilote dans un rallye automobile, c’est mieux d’utiliser deux cerveaux et quatre yeux », assure Jean-Pierre Lambert. Autre approche pertinente : le « swarming », lorsque toute l’équipe travaille pour réduire le temps de cycle. « C’est très puissant car on ne démarre pas une nouvelle tâche avant d’avoir terminé la précédente », précise le consultant.
- Commencer et terminer ensemble, avec des KPI communs (et non individuels), orientés résultats.
Marc Hage Chahine, expert en tests chez Altran, effectue un intéressant parallèle entre l’alimentation et les tests logiciels. Pour lui, une bonne campagne de tests se caractérise par plusieurs éléments :
- Un objectif précis.
- Le respect des contraintes de temps.
- Une adaptation au public visé.
- Des tests bien priorisés donnant le bon niveau d’information avec un bilan clair.
- Un focus sur la qualité du logiciel.
Tout comme il y a plusieurs types de repas, il y a plusieurs types de tests. Un bon repas a des ingrédients variés, contient généralement des féculents, se compose de davantage qu’un plat unique, et il est impossible de manger de tout au cours d’un même repas. De manière similaire, une bonne campagne de test doit inclure des tests non-fonctionnels, avec des tests techniques, les tests exhaustifs sont impossibles et une campagne est constituée de différentes activités de test.
De même, Marc Hage Chahine propose une analogie entre la santé et les campagnes de tests : tout comme il faut manger équilibré et en quantités raisonnables (ni trop, ni trop peu), être conscient qu’une mauvaise alimentation peut être fatale et qu’un repas n’a généralement pas d’effet à long terme, une bonne campagne de test doit optimiser les coûts de la qualité et inclure différents types de tests. « Une mauvaise gestion des tests peut être fatale à une application et une mauvaise campagne n’impacte pas forcément le produit sur le long terme », ajoute Marc Hage Chahine.
Selon lui, pour être en bonne santé, il faut « manger équilibré, en fonction de ses besoins, varier ses repas et manger de bons produits, il en est de même pour les tests : il faut en utiliser plusieurs types, faire les tests nécessaires, les faire évoluer en fonction des campagnes et réaliser des tests de qualité. » Autre manière d’illustrer l’analogie : tout comme dans les repas, il faut plusieurs ingrédients (féculents, liquides, protéines, matières grasses, fruits, légumes…), une campagne de tests peut combiner des tests fonctionnels, de performance, de comptabilité, d’utilisabilité, de fiabilité, de sécurité, de maintenabilité et de portabilité.
| Un parallèle entre les repas et les campagnes de test | |||
| Repas | Campagne de tests | ||
| Repas quotidien | Fréquence | Très haute (3 fois/jour) | |
| But | Se sustenter, survivre | Pas d’anomalie critique | |
| Caractéristiques | Peu sophistiqué ou varié | ||
| Repas entre amis |
Fréquence | Moyenne (une fois/semaine) | |
| But | Partager un bon repas | Pas d’anomalie majeure | |
| Caractéristiques | Plusieurs plats, plus complet et riche que le repas quotidien | Plus complète que la campagne de tests vitaux, plusieurs phases possibles | |
| Repas de fête |
Fréquence | Faible | |
| But | Fêter un événement | Pas d’anomalie, valider le comportement d’une nouvelle fonctionnalité | |
| Caractéristiques | Nombreux plats variés, copieux, coûteux | Coûteuse, copieuse, variée | |
| Source : Marc Hage Chahine, Altran, intervention lors de la Journée française des tests logiciels 2020. | |||
| Un parallèle entre la santé et une campagne de test | ||
| Maladies | Problèmes liés aux tests | |
| Obésité | Problème hormonal | Problème d’architecture |
| Trop de nourriture | Trop de tests | |
| Carence alimentaire | Manger déséquilibré | Critère de qualité défaillant |
| Anorexie | Manger trop peu | Sous-qualité |
| Source : Marc Hage Chahine, Altran, intervention lors de la Journée française des tests logiciels 2020. | ||
| De la recette de l’houmous au test : beaucoup de points communs | |
| Pour réussir la recette de l’houmous | Pour réussir une campagne de tests |
| Tremper les pois chiches pendant 24 heures | Préparer les environnements pour les tests fonctionnels |
| Cuire les pois chiches 45 min à la cocotte-minute | Exécuter les tests fonctionnels automatiques |
| Piler les 2 gousses d’ail et presser les 2 citrons | Préparer l’environnement des tests de portabilité et celui des tests d’utilisabilité |
| Astuce du chef : garder l’eau de cuisson des pois chiches | Astuce du testeur : garder les logs des tests fonctionnels automatisés pour vérifier certaines performances |
| Placer les pois chiches dans le robot | Exécuter les tests fonctionnels et analyser les résultats des tests automatisés |
| Ajouter l’ail, le jus de citron, le sel, le poivre, le tahiné et trois louches d’eau de cuisson, puis mixer | Exécuter les tests d’utilisabilité, de portabilité, de fiabilité et de performances |
| Lorsque le tout fait une purée, goûter le résultat puis adapter (sel, poivre, eau, citron…) | Exécuter des tests exploratoires sur les critères de qualité qui en ont besoin |
| Mettre le houmous dans un saladier, faites la présentation, puis ajouter l’huile d’olive | Faire des tests de maintenabilité et préparer le bilan |
| A noter : il faut goûter pour s’assurer de la bonne qualité du plat | A noter : il est vivement recommandé d’ajouter des tests exploratoires dans les différentes campagne |
| Source : Marc Hage Chahine, Altran, intervention lors de la Journée française des tests logiciels 2020. | |
Orange Labs : une migration sous forme d’abécédaire
Orange Labs, la division de recherche et de développement de la multinationale française de télécommunications Orange, a remplacé un outil patrimonial, utilisé depuis plus de vingt ans, par une autre solution (ALM Octane de l’éditeur Micro Focus). Orange Labs gère non seulement des projets de développement de logiciels, tels que des applications Web, mobiles et de back end, mais aussi la distribution de matériels et de composants de télécommunications, tels que des routeurs, des décodeurs et une variété d’appareils IoT (Internet des objets). Orange Labs a recherché une solution de gestion de la qualité des produits pour intégrer des tests automatisés dans tous les projets informatiques, pour gérer plus de 600 projets de tests, chacun contenant plusieurs éléments de tests dans un espace de travail, et 3 000 utilisateurs. Au cours d’une période de deux ans, tous les projets de tests existants ont été migrés vers la nouvelle solution, tandis que tous les nouveaux projets de tests ont été initiés dès le début dans la nouvelle solution. Yann Helleboid, Testing Community Manager pour Orange Labs, a synthétisé cette opération sous forme d’un abécédaire :
A comme… Ancien. C’est ce qui caractérise la solution précédente, utilisée depuis plus de vingt ans. « Une éternité… », précise Yann Helleboid.
B comme… Bazar. L’outil précédent avait différents noms, associés à plusieurs instances. « La situation était donc difficile, lourde à gérer. »
C comme… Complexe. « Nous devions gérer en parallèle un outil obsolète et des exigences de transformation de l’entreprise, marquée par la montée de l’agilité et de DevOps. »
D comme… Décision. Le choix de la solution est une étape cruciale et doit s’effectuer sur un mode collaboratif, au lieu d’une approche top down.
E comme… Essai. Dix pilotes ont été réalisés, avec différents cas de figure. Cela peut sembler beaucoup mais, « dans une grande organisation, tous les projets ne vont pas au même rythme selon les technologies, il faut une diversité des business cases. »
F comme… Final. La durée de migration a été fixée à deux ans. « Si le délai est trop court, les équipes ont le couteau sous la gorge et mettent en danger la production, si le délai est trop long, ça ne démarre jamais… ».
G comme… Go. C’est le moment où il n’est plus possible de créer de nouveaux projets avec l’ancienne solution.
H comme… Hybride. Les deux solutions peuvent fonctionner en parallèle pendant le temps de la migration. Mais c’est difficile : « C’est un énorme challenge, car les effectifs n’augmentent pas et la charge de travail double pour l’exploitation et le support. »
I comme… Incitation. Comment inciter les utilisateurs à s’approprier la nouvelle solution ? « Il ne faut pas forcer à changer à un moment donné, mais inciter progressivement à le faire, avec beaucoup de communication, d’outils de migration et de support, surtout pour les premiers projets concernés. »
J comme… Joueurs. Ce sont les utilisateurs qui se lancent en premier et perçoivent les avantages à migrer vers une solution plus moderne. « Les propriétaires de projets de tests sont encouragés à explorer toutes les différentes fonctionnalités d’ALM Octane et à partager leur expérience sur d’autres projets. Cette boucle de commentaires collaborative offre aux utilisateurs une grande expérience, et le bouche-à-oreille publicitaire a élargi l’utilisation. »
K comme… Kilos (d’habitudes). Les utilisateurs essaient de reproduire, avec le nouvel outil, leur manière de faire avec l’ancien. D’où un effort d’explications et de gestion du changement à prévoir…
L comme… Liberté. « Nous avons arrêté d’essayer de convaincre des utilisateurs qui ne veulent pas l’être. » L’approche d’Orange Labs a été de laisser la liberté d’utiliser n’importe quelle autre solution. « Offrir le choix à nos utilisateurs est un véritable changement de mentalité et cela fait partie de notre transformation numérique. Nous ne voulons pas imposer un outil ou une méthodologie spécifique à nos utilisateurs. »
M comme… Mi-chemin. Il s’agit de vérifier que les résultats sont en ligne avec les anticipations, par exemple d’avoir validé la migration de la moitié des utilisateurs et des applications à mi-chemin de la durée prévue.
N comme… Néophytes. La mise en place d’une nouvelle solution est toujours l’occasion de convaincre de nouveaux utilisateurs, « notamment ceux qui sont passés au travers des formations. »
O comme… Ô rage, ô désespoir. C’est la réaction légitime face à l’augmentation de la charge de travail en parallèle de la diminution des ressources. Mais, heureusement, l’automatisation compense cette difficulté.
P comme… Pertes de données. Elles peuvent survenir à tout moment, d’où l’intérêt des sauvegardes et de leur récupération. « Nous avons perdu une semaine de data, mais, heureusement, c’était le 15 août ! », se souvient Yann Helleboid.
Q comme… Quadrature du cercle. Il faut pouvoir relier tous les outils (de tests, de qualité…) de manière automatique. « Ce que nous n’avions jamais réussi à faire auparavant a été possible grâce aux API. »
R comme… Revue. Régulièrement, la satisfaction des utilisateurs doit être mesurée, en particulier sur les aspects fonctionnels de la solution (de manière à challenger l’éditeur) et le degré d’automatisation.
S comme… Souplesse. Lorsque les ressources sont contraintes, il faut faciliter la vie des utilisateurs, par exemple pour créer un compte ou un projet en quelques clics.
T comme… Training. La formation doit être différenciée selon les utilisateurs, en débutant par exemple par des sessions d’une heure, qui peuvent s’organiser à distance, ce qui suffit à la majorité des utilisateurs. Des durées plus longues (de quelques heures à quelques jours) s’envisagent pour des besoins plus complexes.
U comme… Utilisateurs. Leur support doit être efficace et réactif, surtout lorsque l’outil n’est pas obligatoire. « Il faut multiplier les canaux d’interaction, pour les équipes, c’est l’enfer, mais les utilisateurs adorent », résume Yann Helleboid.
V comme… Vélocité. Elle est essentielle pour s’adapter au rythme des mises à jour de la solution.
W comme… Watt. L’automatisation permet d’utiliser moins de serveurs, donc de consommer moins…
X comme… X-Files. A l’issue de la durée prévue pour la migration, l’idée est de couper les serveurs supportant l’ancienne solution. « Bien sûr, il reste des projets pour lesquels les utilisateurs n’ont pas agi pour migrer. Tant pis pour eux… », explique Yann Helleboid. Des utilisateurs étourdis (dont les projets ont quand même été sauvegardés…) qui sont donc contraints de migrer ! Chez Orange Labs, 400 projets n’avaient pas été migrés, à l’issue de la durée prévue : « Personne n’a réclamé, cela ne semblait donc pas si dramatique et c’est l’occasion de faire le ménage. »
Y comme… Youpi ! C’est le moment où l’ancienne solution disparaît pour laisser la place à la nouvelle.
Z comme… Zen. Il faut le rester, même s’il est toujours possible d’automatiser et d’intégrer davantage.