Depuis sa création dans les années 90, l’automatisation des tests a connu des périodes d’adolescence, de préadolescence et de vingtième année. De la méthodologie d’enregistrement et de lecture à l’intelligence artificielle et à l’automatisation basée sur l’apprentissage automatique, son évolution a été fascinante en raison du débat constant sur son efficacité.

En dépit de son existence ou de son utilité, certains concepts liés à ce sujet laissent encore perplexes certains d’entre nous. Par exemple,

• Succès de l’automatisation des tests
• L’automatisation des tests : Un objectif difficile à atteindre
• Les projets prennent du retard malgré l’automatisation
• Rôle de l’automatisation dans les futurs tests

Il s’agit d’énigmes tirées de l’expérience de chacun, mais elles semblent familières et assez cohérentes. Il pourrait y en avoir d’autres, certains ont des solutions et d’autres doivent être résolus.

…ce qui m’amène au sujet

Selon Sujatha…

Clarifiez et définissez une stratégie claire sur ce que vous voulez réaliser avec l’automatisation des tests.

Essayer d’automatiser les tests tout en laissant le reste du processus du cycle de livraison du logiciel (SDLC) en l’état est la recette la plus rapide pour un désastre de l’automatisation. La mise à niveau du reste des phases du SDLC se complète bien lorsque vous entreprenez d’automatiser les tests.

Par exemple, de nombreuses entreprises n’encouragent pas l’automatisation des tests unitaires ou d’intégration, ou ne suivent pas une approche testable pour construire un produit. Ils souhaitent tester l’interface utilisateur par le biais de l’automatisation. Pour eux, l’automatisation se limite au niveau fonctionnel ou à l’interface utilisateur.

Ces pratiques ont tendance à suivre un chemin prévisible de chaos.

Pendant un certain temps, le moteur semble être sur la bonne voie. Mais lorsque les choses se gâtent, il y a des retouches à faire. Ils finissent par prendre du retard.

Le remède habituel à ce défi se résume à une seule chose : rompre avec le processus monolithique typique qui consiste à tout automatiser et à le catégoriser en portions d’unité, d’intégration, d’API et d’interface utilisateur.

Comme le dit Software Testing News,

Le plus gros morceau est que 70 % des tests écrits devraient être des tests unitaires, qui sont principalement écrits par les développeurs pour tester leur propre code et détecter les bogues avant qu’ils n’atteignent les équipes d’assurance qualité. Ces tests sont cruciaux car ils fournissent une couverture de test fondamentale qui réduit le nombre de bogues majeurs découverts plus tard dans le cycle de test.

En montant dans la pyramide, les 20 % suivants devraient être alloués aux tests d’intégration, qui sont généralement rédigés lorsque les systèmes sont intégrés à d’autres dépendances et à des systèmes tiers, où des services fictifs et des environnements virtualisés automatisés pourraient être utilisés pour compléter la couverture là où les tests unitaires risquent d’être manqués.

Lorsque nous atteignons le sommet de la pyramide, les derniers 10 % doivent se concentrer principalement sur les tests fonctionnels de l’interface utilisateur. Ces tests sont fragiles car tout enchantement de l’interface utilisateur peut facilement briser les packs de tests. Par conséquent, ils devraient idéalement être automatisés sur les pipelines de construction, ce qui permet la maintenabilité et des efforts de tests exploratoires supplémentaires au fur et à mesure de l’avancement des constructions itératives. Grâce au modèle de la pyramide de test, les équipes peuvent économiser du temps et de l’argent dans leur cycle de test, en augmentant la couverture de test à l’extrémité inférieure de la pyramide, ainsi qu’en éliminant tous les bogues exposés au fur et à mesure que l’on monte dans les couches de test de l’interface utilisateur centrée sur l’activité de l’entreprise.

Rapport sur l’état de l’automatisation des tests en 2022 – 30 % des organisations accordent la priorité au passage des tests manuels aux tests automatisés en 2022.

Cela montre que le passage à l’automatisation des tests reste un rêve pour certaines entreprises.

Sujatha énumère quelques facteurs clés à prendre en compte lors du passage aux tests automatisés :

• Soutien de l’écosystème par la construction d’un produit testable

S’assurer qu’un produit testable est construit. Par testable, j’entends : avoir des éléments d’interface utilisateur uniques et lisibles, avoir un identifiant unique pour tous les composants (sans avoir besoin d’écrire des scripts X path), rendant ainsi les identifiants directs et le processus d’automatisation au niveau de l’interface utilisateur plus facile, même si le style et la conception changent par la suite.

• Comprendre que l’automatisation des tests fonctionnels complète les tests de régression manuels et ne les remplace pas.

Avec l’automatisation, vous ne faites qu’améliorer l’efficacité des tests de régression manuels en les automatisant. Ne considérez pas les tests de régression automatisés de manière isolée

• Les ensembles d’outils et les processus que vous choisissez doivent être adaptés au processus de mise sur le marché et de test de votre produit.

Utilisez les dockers à la place des machines virtuelles. Il réduit l’effort de maintenance et vous permet de contrôler vos besoins exacts.
En ce qui concerne le processus, si votre configuration actuelle ressemble à quelque chose comme ceci : Construction ad hoc réussie – Test de fumée – Passage à la production.
Dans ce cas, l’intégration de tests automatisés dans ce processus sera une tâche difficile et dénuée de sens.
La mise en place d’un processus structuré tel qu’un sprint, où chaque activité est prédéfinie, donne aux testeurs suffisamment de temps pour mettre en place une suite d’automatisation, l’exécuter, analyser les rapports de test et la maintenir.

• Désapprendre à exécuter tous les cas de test en permanence

Votre application est vaste et vous n’avez pas besoin d’exécuter une énorme suite automatisée à chaque fois. L’identification des rapports et le contrôle des zones touchées suffisent amplement. Il est fondamental que votre cadre d’automatisation des tests soit conçu de manière à ce que les cas de test puissent être divisés et qu’à tout moment, vous puissiez exécuter uniquement les cas de test nécessaires.

L’automatisation des tests est déterministe. Entrées connues = sorties prévisibles.

Si vous essayez d’automatiser des tests dynamiques, où les entrées et les sorties varient constamment, arrêtez-vous et posez-vous des questions : Est-ce nécessaire ? Est-ce que je veux vraiment ajouter plus de complexité à l’application existante ?

Soyez attentif au niveau de complexité que vous souhaitez donner à votre approche d’automatisation des tests.

Les tests automatisés sont plus rapides. Vous devez également reconnaître que l’automatisation ne s’applique pas aux nouveaux tests fonctionnels.

Vous devez tester manuellement les nouvelles fonctionnalités et voir si elles échouent.

Les projets qui prennent du retard se produisent lorsque les tests unitaires ne sont pas automatisés et que les testeurs finissent par trouver manuellement 80 % des bogues dans la phase d’assurance qualité, alors qu’ils auraient idéalement dû être détectés bien plus tôt, lors du développement du composant.

Ainsi, lorsque le temps des testeurs est consacré à la recherche de ces bogues, le temps réel nécessaire à l’automatisation des API et des activités en pâtit, ce qui crée une pile d’arriérés pour les sprints successifs.

C’est logique, non ?

En tant que personne ayant une expérience de première main de l’écoute des clients, je peux vous dire qu’ils ont dressé la liste de leurs problèmes :

• Des retards massifs dans la réalisation des tests
• Le gel du code ne se produit pas
• Couverture de test insuffisante
• Derrière le calendrier de publication, etc.

L’équipe de Sujatha a joué un rôle déterminant dans la mise en place de barrières de qualité et dans la rationalisation d’un grand nombre d’activités STLC, ce qui a permis de remédier à ces problèmes de qualité.

Petit conseil : encouragez les tests en équipe et employez des ingénieurs de développement logiciel en test (SDET) pour réduire les dépendances et permettre une livraison continue.

Les outils d’automatisation tels que Cypress, Protractor et Jasmine préparent l’avenir en permettant aux testeurs et aux développeurs de travailler ensemble. Il s’agit là d’une avancée bienvenue vers la mise en place du SDETS et l’effacement des frontières entre les équipes.

Mais pour être vraiment agile, votre automatisation doit aller au-delà des cas de test de l’interface utilisateur et s’adapter à des tâches telles que l’automatisation des déploiements et des mises à niveau de la base de données.

À l’avenir, les compétences requises pour l’hyper-automatisation seront différentes, mais elles se recoupent. En fait, chez Zuci, nous pensons que l’automatisation des tests et la RPA se chevauchent et ne sont pas totalement différentes.

En outre, il existe aujourd’hui de nombreux outils basés sur l’IA/ML dotés de capacités d’autoréparation et d’outils de test basés sur des codes faibles ou inexistants. La connaissance de votre configuration de test existante et de ce que vous souhaitez accomplir avec l’aide de ces outils vous aidera grandement dans votre parcours d’automatisation.

En conclusion,

Chez Zuci, nous pensons que l’automatisation est une excellente idée. Pour en faire un bon investissement, appliquez la règle des 80/20.

80 % des effets proviennent de 20 % des causes, et 80 % des résultats proviennent de 20 % des efforts.

Trouvez ces 80 et 20 pour l’automatisation de vos tests. L’automatisation à 100 % est un mythe. Si vous poursuivez l’objectif d’une automatisation à 100 %, vous ne progresserez que très peu, voire pas du tout, et tous vos efforts seront réduits à néant.

L’automatisation ne permet pas d’identifier les bogues. L’automatisation ne permet pas de penser comme un utilisateur final. Il s’agit simplement de s’assurer que ce qui fonctionnait bien auparavant fonctionne toujours. Ou mieux, elle permet d’éviter les problèmes de régression.

L’automatisation ne fait pas ce que les testeurs avaient l’habitude de faire, à moins d’ignorer la plupart des choses qu’un testeur fait réellement. Les tests automatisés sont utiles pour étendre la portée du travail du testeur, et non pour le remplacer.

Les testeurs doivent explorer manuellement l’application et vérifier si elle échoue, ainsi que la raison de cet échec, afin d’aider à le corriger.

Comme l’a dit James Bach,

Si les tests sont un moyen de comprendre la qualité du logiciel, l’automatisation n’est qu’un moyen.

Question pour vous :

Que pensez-vous des sujets abordés dans cette édition de Z to A Pulse ?

Faites-nous part de vos commentaires ou suggestions ci-dessous. Veuillez vous “abonner” pour recevoir les prochaines éditions mettant en lumière certains des sujets les plus passionnants dans le domaine de l’excellence en matière d’ingénierie.

Merci de votre lecture !

Lisez la suite si vous êtes intéressé :

1. Test Automation Snake Oil, par James Bach
2. Adopter l’approche du “modèle pyramidal de test”.