Automatisation des tests logiciels : pourquoi et comment ?

La course à l'automatisation des tests logiciels risque de ne pas répondre aux attentes des clients et de générer une multitude de scripts « inutiles » que personne n'utilisera, à cause d'un simple changement fonctionnel ou d'une modification de l'architecture du système. Sans compter qu'il faudra attendre longtemps avant de voir se concrétiser le retour sur investissement promis et les économies escomptées.

Tout cela parce que nous n'avons pas clairement défini, dès le début de ce parcours, l'orientation et les objectifs de nos initiatives d'automatisation des tests logiciels.

Pour tracer clairement la voie à suivre, il faut commencer par se demander « pourquoi »
. Pour éviter ces conséquences indésirables, il est essentiel de répondre à plusieurs questions avant de se lancer dans l’automatisation. Dans cet article, nous vous aiderons à analyser vous-même certaines des questions les plus importantes :

Pourquoi automatiser les tests logiciels ?
Cette question peut sembler évidente, et de nombreuses entreprises ont sans doute déjà plusieurs réponses claires en tête : « Pour gagner du temps lors des tests de régression », « pour favoriser l’agilité » ou « pour surveiller les environnements pré-production », pour n’en citer que quelques-unes. Quoi qu’il en soit, la question « pourquoi automatiser les tests logiciels ? » reste la plus importante.

Et s'il est essentiel de définir le « pourquoi », il est tout aussi crucial de le communiquer à votre équipe afin que personne ne perde de vue les objectifs de l'automatisation.

Dans un cas précis, alors que les objectifs d'automatisation étaient clairs et avaient été communiqués au partenaire, celui-ci a choisi une autre approche et a créé un nombre considérable de scripts pour le même flux de travail.

Avec autant de scripts, la gestion et le suivi étaient devenus très difficiles. Puis le logiciel a évolué. Il est devenu impossible de maintenir tous les scripts ; il était donc plus pratique de tout développer à nouveau à partir de zéro. Cependant, cette fois-ci, toutes les validations du flux ont été intégrées dans un seul script.

Les différentes façons d'aborder l'automatisation
Une fois l'objectif de l'automatisation clairement défini, une autre question importante se pose : « comment s'y prendre ? ». Et plusieurs autres questions en découlent, telles que :

• Que savons-nous de l’automatisation ?
  La première chose que je recommanderais est de dresser un état des lieux de ce que nous savons sur le sujet. L’écart entre la situation actuelle et la situation souhaitée est l’un des premiers obstacles à éliminer ou à réduire. Tout ce que nous entreprenons doit reposer sur une connaissance solide du sujet. Disposer en interne de collaborateurs qualifiés ou d’un partenaire expérimenté peut s’avérer très utile à ce stade.
   
• Est-ce que je dispose d'une équipe ou d'un partenaire ayant les compétences nécessaires pour mener à bien ce projet ?
  Il est essentiel de s'entourer des bonnes personnes, ou d'un partenaire, pour réussir. Non seulement pour leurs connaissances techniques, mais aussi pour l'engagement dont ils font preuve dans la poursuite de l'objectif.
   
• Combien coûtera le projet ?
  En général, une PoC (preuve de concept) ou un MVP (produit minimum viable) suffit pour se faire une idée des coûts. Même si la plupart des PoC restent productives, la manière dont elles sont mises en œuvre ne doit en aucun cas devenir la méthode à adopter à l’avenir. Une PoC vise à déterminer si « c’est faisable » – et si c’est le cas, il est temps de se lancer dans la planification !
   
• Quand puis-je espérer voir des résultats ?
  En fin de compte, l’automatisation est un projet de développement, ce qui facilite sa planification. Elle peut également s’inscrire dans le cadre d’un sprint ; les délais dépendront donc de l’ampleur de la tâche à accomplir. Le scénario idéal consiste à choisir un système qui se prête bien à l’automatisation, à automatiser un flux de complexité moyenne, puis à utiliser ce temps de référence pour planifier le reste des flux du système.
   
• Faut-il tout automatiser ?
  Pas nécessairement : la qualité prime sur la quantité. D’un point de vue technique, j’oserais dire que « 100 % des tests peuvent être automatisés ». Cependant, pour y parvenir, il faudrait engager des coûts très élevés, ce qui nous obligerait à abandonner cette idée.
   
• Qu'est-ce qui vaut vraiment la peine d'être automatisé ?
  Donner la priorité à l'urgent plutôt qu'à l'important est une bonne technique, tout comme la règle des 80/20 (Pareto), bien qu'elle soit déjà contestée. Après tout, ce qui compte, c'est d'avoir une vision très claire de la valeur que le script que je développe apporte à la réalisation des objectifs de l'entreprise.
   
• Comment vais-je évaluer les résultats de mon automatisation ?
  Définir des indicateurs clés de performance (KPI). Comme pour toute planification stratégique, les KPI doivent être définis en fonction de l'objectif principal et des objectifs secondaires. Il convient également de prendre en compte certains indicateurs de qualité pertinents dans ce domaine. Voici quelques exemples de KPI :
  • Taux de défauts : défauts détectés par le script (de préférence en utilisant la densité de défauts).
  • Types de défauts : codage, environnement, données, etc.
  • Taux d'échec : à partir de 100 % d'une exécution de script, ce pourcentage correspondant à une erreur.
  • Minutes d'exécution manuelle VS minutes d'exécution automatisée : cela permet d'identifier le gain de temps généré par votre script.
  • % de couverture d'automatisation : proportion de flux automatisables par rapport à l'ensemble des flux de test du système (il n'est pas recommandé de fixer un objectif trop élevé. En réalité, il ne faudrait même pas fixer d'objectif).
  • % d'avancement dans le développement de l'automatisation : flux automatisés VS flux automatisables. En fonction de votre plan, vous devez comparer les chiffres prévus à ceux réalisés.

Leçon clé : planifier l'automatisation des tests logiciels
Jusqu'ici, nous avons donc compris que l'automatisation n'est pas aussi simple qu'on nous l'avait laissé entendre : monter un serveur au hasard (généralement n'importe quel poste de travail), générer un script avec n'importe quel outil, puis se contenter de l'exécuter en boucle, comme si le nombre d'exécutions ou de scripts était proportionnel à notre progression vers l'objectif. Ça ne marche tout simplement pas comme ça.

Ce qu’il faut retenir de cette analyse, c’est qu’avant de s’engager sur la voie de l’automatisation, il faut prendre le temps, aussi longtemps que nécessaire, de : définir clairement les objectifs > planifier > établir des priorités > définir les indicateurs clés de performance (KPI) et les objectifs > et mettre en place des points de contrôle et des méthodes de suivi axés sur la valeur de l’automatisation, et non sur la quantité de scripts à générer.

Et si vous êtes déjà engagé dans cette voie et que les perspectives ne sont pas encourageantes, posez-vous ces questions pour vous orienter vers les possibilités d'amélioration de votre équipe.

Un dernier mot sur l'automatisation des tests logiciels
Pour conclure, et pour revenir à la question du « pourquoi », voici quelques approches possibles en matière d'automatisation qui peuvent apporter une grande valeur ajoutée à l'entreprise :

• Automatiser pour favoriser l’agilité
  Dans cette optique, il n’est pas judicieux d’automatiser 100 % des cas de test. Il vaut mieux se concentrer uniquement sur les flux fonctionnels les plus critiques afin d’éviter tout impact sur l’activité lié à une nouvelle version (tests régressifs). De plus, il est également recommandé d’inclure les tests dont l’exécution manuelle prend davantage de temps (afin de se concentrer sur les tests manuels des nouveaux cas / flux créés à la suite d’une modification du code). Enfin, incluez les tests les plus complexes qui requièrent des connaissances fonctionnelles avancées (cela permet également de se passer de l’analyste fonctionnel expert, qui doit se concentrer sur d’autres flux). L’exécution de ces tests est idéalement déclenchée dans le cadre d’un schéma d’intégration continue avant la mise en production d’une nouvelle modification du code et après l’exécution de la validation des données correspondantes (idéalement automatisée elle aussi).
   
• Automatiser la surveillance de la stabilité des systèmes
  Lorsqu’on apporte une modification majeure à un système, les analyses d’impact négligent souvent certaines intégrations avec d’autres systèmes, et il arrive fréquemment qu’un impact non identifié affecte le fonctionnement d’un ou plusieurs systèmes. Cela entraîne l’interruption des tests jusqu’à la correction ou la restauration de la modification. Dans le cadre de cette approche d’automatisation, il est conseillé de ne prendre en compte que les « Happy Paths » et de tester ces workflows plusieurs fois par jour de manière programmée (par exemple, avec Jenkins), ce qui nous permet de détecter rapidement, via un tableau de bord en ligne, si un système, un service ou un serveur rencontre des problèmes. Si l’on va plus loin en matière de notification « en ligne », on peut déclencher l’envoi d’un e-mail, d’un SMS ou d’un message d’alerte dans des outils tels que HipChat, afin que les membres de l’équipe soient rapidement informés sans avoir à consulter le tableau de bord.

Contactez-nous à l'adresse
. Pour plus d'informations sur l'automatisation des tests logiciels, contactez nos experts ou rendez-vous sur notre site Getronics.