Tests logiciels : pour une automatisation adaptative et évolutive

Le passage au cloud, l’internet des objets et l’intégration continue des applications ont rendu plus que jamais l’automatisation des tests incontournable… à condition de considérer l’automatisation comme un processus long terme.

Les applications et logiciels évoluent constamment, tandis que les projets SI impliquent de plus en plus les métiers type marketing et finance. Ces paramètres sont à prendre en compte, car l’automatisation ne peut être pensée sans être liée, dans la méthode de sa mise en œuvre, aux utilisateurs finaux.

Pourquoi automatiser ?

Gain en temps, gain en productivité, les bénéfices d’une automatisation de test bien réalisée sont plus que tangibles. Le test représente 30 à 50% du coût de développement. Il est alors intéressant de penser des processus permettant de répéter automatiquement les tâches qui peuvent l’être, et ce d’autant que l’exécution des tests est souvent chronophage. Le test de non-régression est un bon exemple de tâche qu’il est impératif d’automatiser pour tester plus et mieux.

Les bénéfices périphériques sont intéressants. En premier lieu, le développeur peut se consacrer à des tâches plus stratégiques.  Ensuite, à moyen terme, la traçabilité de bout en bout alliée à un système d’alerte intelligent est susceptible de réduire l’effort de maintenance de manière significative. Ajoutons que le risque d’erreur humaine est de facto réduit : les avantages de l’automatisation sont objectifs et évidents.

Les écueils de l’automatisation

Pourtant, les bonnes pratiques d’automatisation ne vont pas de soi. Le livre blanc d’Acial sur les dix erreurs à ne pas commettre pour réussir son projet de test pointe l’automatisation comme un passage critique. Il est en effet très fréquent que les automates évoluent mal et/ou se révèlent inadaptés aux versions ultérieures du logiciel. C’est assez problématique, surtout quand on sait que 60 à 80% des développements de logiciels ont lieu après la première mise en production.

Le constat de l’inadéquation de l’automatisation aux besoins des utilisateurs est assez universellement partagé. Avant de se lancer sur le marché en 2011, Qualitia, un acteur du test indien, a ainsi remarqué que quatre entreprises sur cinq n’étaient pas satisfaites de la manière dont l’automatisation des tests a été implémentée chez eux.

Il est en réalité très facile de développer un automate inadapté : il suffit d’une mauvaise sélection de scénarios de test à automatiser. De surcroît, les enjeux sont nombreux.

- Les entreprises ne disposent pas nécessairement des bonnes ressources en interne. Chaque outil a un langage spécifique, qui nécessite autant d’équipes techniques pour les appréhender. De plus, les experts fonctionnels et les testeurs manuels ne peuvent pas automatiser car ils ne savent pas programmer.

- Les coûts de maintenance sont vite élevés si les scénarios de test changent souvent. Les milliers de ligne de code des tests d’automatisation, l’absence de documentation et le turnover des ressources humaines sont de nature à contrarier le projet.

- Le coût des outils et des ressources spécifiques retardent la période espérée de retour sur investissement.

- Plus on attend la livraison de l’application de test, plus on risque d’être en retard sur l’évolution de l’application à tester. Et dans l’urgence, à défaut d’avoir pensé les scénarios d’évolution, on abandonne l’automate. L’anticipation de la maintenance et de l’évolution de l’automate est cruciale.

- Les données de test doivent être établies le plus rigoureusement possible. Pour un site de e-commerce, par exemple, le testeur saura s’adapter si une référence demandée n’est plus disponible : il interprétera le cas du test et proposera une référence similaire. L’automate, lui, ne s’adapte pas. Il est donc important d’être méthodique dans la définition et la génération des données de test. 

L’automatisation n’est pas une étape qu’on peut se permettre de négliger. Il serait vain de croire qu’on peut se passer de méthodologie, ou qu’on peut tout automatiser. De fait, l’automatisation ne remplacera jamais le test manuel. Linda Hayes, fondatrice de Worksoft, affirme ainsi que les testeurs manuels sont les « experts de l’inattendu », des scénarios uniques, quand l’automatisation, au contraire, se concentre sur tout ce qui est prédictible. Investir dans l’automatisation n’a d’utilité économique que si les tests sont amenés à être répétés ; or, la plupart des tests manuels ne le sont pas.

Automatiser correctement, c’est donc travailler en bonne intelligence avec les divers membres de l’équipe de test. C’est aussi être au fait des besoins finaux de l’utilisateur. Le fait qu’un certain nombre de méthodes aient été abandonnées met en  lumière les nécessités d’aujourd’hui. Ainsi, le « Record and Replay », bien que réutilisé aujourd’hui pour les tests mobiles, a été mis de côté car il ne fonctionne qu’à petite échelle et engendre des coûts de maintenance élevés. La méthode dite « Data driven » était plus intéressante, mais partait du principe que le test se résume à de l’input de données. Or, il s’agit avant tout de simuler de vrais scénarios business. Les testeurs ont besoin d’une approche qui spécifie quelles données utiliser, à partir de quel fichier.

L’enjeu est de ne pas perdre de vue les objectifs liés à l’automatisation : l’augmentation du ROI, et l’adéquation aux besoins métier.

 Une approche dynamique et non statique

L’approche doit être orientée métier et favoriser le dialogue entre les différentes parties prenantes. La bonne méthode ? Intégrer l’approche « assurance qualité » au cœur des équipes, et rapprocher développeurs et testeurs. L’organisation chez Google témoigne de l’importance d’une bonne coordination.

- L’ingénieur logiciel est impliqué dans l’écriture du code fonctionnel qui sera livré aux utilisateurs, ainsi que sur les problématiques d’architecture et de documentation.

- L’ingénieur logiciel en test se concentre sur la testabilité et l’infrastructure de test en général, afin d’améliorer la qualité du code et la couverture de test. Il est également habilité à automatiser. Son rôle est intéressant car il porte sur les problématiques d’environnement, de framework, et de qualité, et c’est lui qui sensibilise les ingénieurs logiciels à ces questions.

- L’ingénieur de test, enfin, est un expert produit. Il exécute les scénarios utilisateurs communs, élabore des scripts pour automatiser des scénarios de bout en bout… Lui aussi est un maillon central de la chaîne de test. Il communique notamment avec l’ingénieur logiciel en test et le bêta testeur.

Cette bonne coordination permet de développer des modèles qui garantissent l’adéquation du test et de son automatisation aux besoins métiers. Contrairement aux modèles évoqués précédemment, les méthodes élaborées aujourd’hui se concentrent véritablement sur cet aspect métier. On peut évoquer en exemple le Model Based Testing, qui fédère l’analyste métier, le testeur et le développeur autour d’un même projet de test.

La méthode Atom répond également aux besoins évoqués. Le principe est simple : il s’agit de remplacer les scripts de l’automate par des mots clés insérés dans un fichier Excel. Ces mots-clés, dont la syntaxe est imposée,  constituent la description des cas de test à partir de laquelle Atom interprète la volonté du testeur. Le Framework traduit le cas de test en action sur l’interface de l’application. Cette méthode est reconnue dans la communauté des experts. Elle a le mérite de réduire la charge de développement et de maintenance des automates. Elle donne également aux testeurs la maîtrise de l’automatisation. De par la simplicité de l’interface, il est tout à fait possible de modifier le fichier des mots-clés et d’être toujours en phase avec l’application à tester. 

L’automatisation du test requiert ainsi la définition des comportements à tester, et l’implémentation des bons mots d’actions.  Le processus peut avoir une forte valeur ajoutée en termes de ROI, mais il doit être mené avec méthode. Pour garantir une adéquation adaptative et évolutive avec un logiciel lui-même évolutif, la maintenance de l’automate doit être anticipée. Et l’automatisation doit être liée à une bonne compréhension des enjeux métier.