Automatisation des tests de logiciels - pourquoi et comment

06/09/2021

Il est essentiel de répondre à plusieurs questions avant de se lancer dans l'automatisation des tests de logiciels. Dans cet article, nous vous aidons également à analyser vous-même certaines des questions les plus importantes.

Un groupe de collègues discutant de l'automatisation des tests de logiciels

La course à l'automatisation des tests de logiciels risque de ne pas répondre aux attentes des clients, de produire un nombre incalculable de scripts "inutiles" que personne n'utilisera, à cause d'un simple changement fonctionnel ou d'une modification de l'architecture du système. Et d'induire une longue attente pour le retour sur investissement promis et les économies escomptées.

Tout cela parce que nous n'avons pas clairement établi la direction et les objectifs de nos initiatives d'automatisation des tests logiciels dès le début du projet.

Une voie claire commence par le pourquoi

Pour éviter ces résultats 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 l'automatisation des tests de logiciels ?

Cette question peut sembler évidente, et de nombreuses organisations peuvent déjà avoir plusieurs réponses claires à l'esprit. "Pour éviter de perdre des heures dans les tests de régression, pour promouvoir l'agilité ou pour surveiller les environnements pré-production, pour n'en citer que quelques-unes. Quoi qu'il en soit, "pourquoi automatiser des tests logiciels?" reste la question 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 d'automatisation.

Dans un cas, alors que les objectifs d'automatisation étaient clairs et qu'ils avaient été partagés avec le partenaire, celui-ci a pris un chemin différent et a créé un grand nombre de scripts sur le même workflow.

Avec autant de scripts, il est devenu très difficile de les gérer et de les contrôler. Puis le logiciel a changé. 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é effectuées dans un seul script.

Les multiples facettes de l'automatisation

Une fois que l'objectif de l'automatisation est clair, une autre question importante se pose : "comment le faire ? Plusieurs autres questions en découlent, telles que :

Que savons-nous de l'automatisation ?
La première chose que je recommande est d'identifier l'état actuel des choses par rapport à ce que nous savons du sujet. L'écart entre le AS-IS (actuel) et le TO-BE (à venir) est l'une des premières choses à éliminer ou à réduire. Tout ce que nous faisons doit être fondé sur une solide connaissance du sujet. La présence de personnes compétentes en interne ou d'un partenaire expérimenté peut s'avérer très utile à ce stade.

Ai-je une équipe ou un partenaire possédant les compétences nécessaires ?
La clé du succès réside dans la présence des bonnes personnes ou d'un partenaire. Non seulement pour les connaissances techniques, mais aussi pour l'engagement qu'ils prennent à l'égard de l'objectif.

Combien coûtera le projet ?
En général, un PoC (proof of concept) ou un MVP (minimum viable product) suffit à donner une idée des coûts. Si la plupart des PoC restent productifs, la manière dont ils sont réalisés ne doit en aucun cas devenir le processus à suivre à l'avenir. Un PoC vise à savoir si "c'est faisable" - et si c'est le cas, il est temps de commencer à planifier !

Quand dois-je m'attendre à voir des résultats ?
En fin de compte, l'automatisation est un projet de développement, ce qui permet une planification simple. Elle peut également être traitée dans le cadre d'un sprint, les délais étant alors déterminés par la taille de ce que nous voulons faire. Le scénario idéal est le suivant : prendre un système qui est un bon candidat à 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.

Dois-je tout automatiser ?
Pas nécessairement : la qualité prime sur la quantité. Techniquement, j'oserais dire que "100% des tests peuvent être automatisés". Toutefois, pour y parvenir, nous devrions supporter des coûts très élevés, ce qui nous obligerait à abandonner l'idée.

Qu'est-ce qui est vraiment pratique à automatiser ?
Donner la priorité à l'urgent sur l'important est une bonne technique, ou suivre le déjà imparfait 80/20 (Pareto). Après tout, ce qui compte, c'est d'être très clair sur la valeur que le script que je développe apporte à la réalisation des objectifs de l'entreprise.

Comment vais-je mesurer les résultats de mon automatisation ?
Définir des indicateurs de performance clés. Comme pour toute planification stratégique, les indicateurs clés de performance doivent être définis en fonction du but principal et des objectifs secondaires. Pensez à certains indicateurs de qualité, qui sont également pertinents dans ce domaine. Voici quelques exemples d'indicateurs clés de performance :
- Taux de défauts : défauts trouvés par le script (idéalement en utilisant la densité de défauts).
- Types de défauts : codage, environnement, données, etc.
- Taux d'échec : à partir de 100 % de l'exécution d'un script, quel est le pourcentage de résultats erronés.
- Minutes d'exécution manuelle VS minutes d'exécution automatisée : cela permet d'identifier les gains de temps générés par votre script.
- % de couverture de l'automatisation : flux automatisables sur l'univers total des flux de test du système (il n'est pas recommandé de définir un objectif élevé. En fait, nous ne devrions même pas avoir d'objectif).
- % Progrès dans le développement de l'automatisation : flux automatisés VS flux automatisables. En fonction de votre plan, vous devez comparer le planifié au réalisé.

Leçon clé : planification de l'automatisation des tests de logiciels

Jusqu'à présent, nous avons compris que l'automatisation n'est pas aussi triviale qu'on nous l'a dit : assembler un serveur aléatoire (généralement n'importe quel poste de travail), générer un script avec n'importe quel outil, et se consacrer à l'exécution encore et encore comme si plus il y a d'exécutions ou de scripts, plus on se rapproche de notre objectif. Cela ne fonctionne 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 s'arrêter, aussi longtemps que nécessaire, pour clairement : définir les objectifs > planifier > établir des priorités > définir des KPI et des cibles > et établir 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 à afficher.

Et si vous êtes déjà sur cette voie et que les perspectives ne sont pas positives, posez-vous les questions suivantes pour vous guider vers les possibilités d'amélioration de votre équipe.

Un dernier mot sur l'automatisation des tests de logiciels

Pour conclure, et pour revenir au "pourquoi", voici quelques approches qui peuvent être données à l'automatisation tout en ajoutant une grande valeur à l'organisation :

Automatiser pour favoriser l'agilité
Dans cette perspective, il n'est pas opportun d'automatiser 100 % des cas de test. Il est préférable de ne considérer que les workflows fonctionnels les plus critiques afin d'éviter tout impact commercial dû à une nouvelle version (tests régressifs). En outre, il est bon d'inclure les tests dont l'exécution manuelle prend plus de temps (pour se concentrer sur les tests manuels des nouveaux cas / flux que nous créons en raison de la modification du code). Enfin, il convient d'inclure 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). Les exécutions de ces tests sont idéalement déclenchées dans un schéma d'intégration continue avant la poussée d'une nouvelle modification du code et après l'exécution de l'inspection du code de données correspondant (idéalement aussi automatisée).

Automatiser pour contrôler la stabilité des systèmes
Lors d'une modification majeure d'un système, les analyses d'impact omettent souvent certaines intégrations avec d'autres systèmes et il est fréquent qu'un impact non identifié affecte le fonctionnement d'un ou de plusieurs systèmes. Cela entraîne l'arrêt des tests jusqu'à la correction ou le retour en arrière de la modification. Dans cette optique d'automatisation, il est conseillé de ne considérer que les "Happy Paths" et de tester ces workflows plusieurs fois par jour de manière planifiée (par exemple, avec Jenkins) ce qui permet de savoir rapidement via un Dashboard en ligne si un système, un service ou un serveur rencontre des problèmes. Si nous allons plus loin dans la notification "en ligne", nous pouvons déclencher un e-mail, un SMS ou un message d'avertissement dans des outils tels que HipChat afin que les membres de l'équipe soient rapidement informés sans avoir à consulter le tableau de bord.