Pourquoi (et comment) ne pas négliger les tests logiciels

Un effet « ciseaux » entre complexité accrue et rythme de sortie accéléré

Tout d’abord, rappelons qu’il y a de nombreux types de tests différents et complémentaires : tests unitaires, tests d’intégration, de validation, de performance, de non-régression, de sécurité, etc.

Nous avons connu un changement profond de la philosophie du développement où la stratégie Release Early, Release Often (RERO) a connu un énorme succès. L’illustration de ce changement est l’adoption des méthodes agiles de sorte que les cycles de développement se sont extrêmement réduits : le rythme de sortie des nouvelles versions est bien plus rapide que par le passé, et avec lui, le besoin de mener des cycles complets de test.

Par ailleurs, les applications modernes reposent sur des architectures excessivement complexes et sont amenées à fonctionner sur une multitude de terminaux. L’ère des parcs d’IBM PC uniformes dans les entreprises est derrière nous. Aujourd’hui, une même application doit pouvoir s’exécuter sur simple smartphone, une phablet, une tablette numérique, un portable, un Mac quand ce n’est pas une montre connectée ou un casque de réalité virtuelle.

De même, le niveau de complexité des applications et des interdépendances s’est accru de manière spectaculaire. Des composants qui s’exécutent sur de multiples conteneurs, sans parler des appels d’API externes et des packages avec des dépendances aussi nombreuses qu’en constante évolution, peuvent être utilisés par des milliers d’applications.

Dans un tel contexte, créer les scénarios de tests, provisionner les environnements complexes pour tester les applications, les exécuter sur une myriade de variations de configurations différentes demande un énorme investissement pour les éditeurs, mais aussi pour les entreprises.

Aussi, il est communément admis que le coût des tests représente de 15 à 25 % du budget de développement d’un logiciel.

De l’importance de l’automatisation

Bien que communément admise, cette fourchette apparaît sous-estimée, car elle laisse de côté de nombreux paramètres liés à la qualité du logiciel.

Une étude menée chez l’industriel Bombardier Transportation par l’École de Technologie Supérieure de Montréal a montré que ce coût représentait plutôt 33 % du budget, avec 21 % dédiés à l’évaluation de la qualité du code, c’est-à-dire les tests, mais aussi 10 % supplémentaires pour la correction des anomalies et 2 % pour l’évaluation.

Il existe des solutions pour endiguer ces coûts. Des approches comme le TDD (Test-Driven Development) incitent les équipes de développement à écrire les tests unitaires avant même de commencer à écrire le code. C’est une approche centrée développeur intéressante, mais la seule solution réellement efficace est l’automatisation.

La recherche de l’automatisation de tout ou partie des tests est une voie à explorer, mais à l’image de la courbe du Hype du Gartner, ce chemin vers l’automatisation passe inexorablement par différentes phases : des attentes surdimensionnées à la mise en place d’une solution productive en passant par de nombreuses désillusions.

Côté outillage, le cloud et l’apparition de services SaaS dédiés sont aussi des éléments de réponse, mais il n’existe pas de solution unique pour réaliser l’ensemble des tests nécessaires à la mise en production. Le développement d’applis mobiles doit pouvoir en effet s’appuyer sur un service qui les expérimente sur de multiples terminaux grâce à des robots.

Un large panel de technologies à maîtriser

Mettre en place des chaînes CI/CD dans lesquelles le volet test est largement automatisé reste un effort conséquent. Il s’agit de mettre en œuvre et de maîtriser une longue liste de solutions comme : Selenium, Cypress, Tosca, BrowserStack, JUnit, Cucumber, Robot Framework, Microsoft Playwright et tant d’autres.

Et au-delà de l’outil qui permet de rédiger les scénarios, il est également nécessaire de gérer les environnements qui permettent d’exécuter les tests dans des configurations différentes, de gérer les jeux de données pour permettre des exécutions à répétition, etc.

Dans le cadre des besoins rencontrés pour HRC Software, nous avions différentes contraintes fortes pour faire ce choix : des applications Web & mobiles développées via la solution Low-Code Neptune Software et reposant sur le framework frontend SAPUI5, la volonté de tester au plus près des terminaux principalement sous Android.

Enfin, nous avions le souhait d’inclure ces tests dans des outils d’intégration continue.

Sachant que nous sommes un éditeur de taille modeste sans les moyens et les effectifs pléthoriques d’un géant du Web, nous avons constitué notre chaîne CI/CD sur des solutions Open Source, notamment l’automatisation délivrée par Jenkins, et retenu la solution Playwright de Microsoft. Éditée sous licence Open Source, celle-ci offre de nombreuses possibilités quant à l’exécution de tests sur un device Android et des fonctionnalités pertinentes comme :

• la comparaison visuelle (imaginer le jeu des 7 erreurs en mode « Avant/Après »),
• l’enregistrement vidéo des sessions,
• la capacité de faire des captures d’écrans,
• l’exploitation des traces.

La solution peut être déployée sous forme de conteneurs Docker et nos tests d’exécutions d’applications Neptune Software sur navigateur et en natif se sont révélés très concluants.

Un effort initial important, mais qui s’avère gagnant sur la durée

Si se lancer dans l’automatisation des tests logiciels demande un investissement évident des équipes, c’est un prérequis si l’on veut produire du code de qualité à coût et délais raisonnables.

En nous engageant dans cette démarche, nous pensons pouvoir libérer un ETP jusque-là dédié aux tests, un expert qui pourra nous renforcer sur le design ou le développement ; des postes à plus forte valeur ajoutée pour un éditeur.

Il me semble que les DSI ont tout à gagner à initier cette démarche le plus tôt possible et ne pas attendre d’avoir un portefeuille de dizaines de projets à faire évoluer. Les tests représentent un coût important en termes de jours de consultants.

D’autre part, la Harvard Business Review observe une accélération des cycles de déploiement. Là où, il y a peu, les logiciels traditionnels proposaient des mises à jour annuelles, les solutions SaaS sont venues bousculer les habitudes avec certains acteurs qui sont même capables de déployer en Production plusieurs fois par jour.

Les entreprises qui ont à maintenir des développements spécifiques sur leurs ERP ont bien du mal à tenir le rythme et à valider leurs propres développements avant que la version suivante n’arrive. D’où l’importance de ces deux mots : industrialisation et automatisation.