Leadership en Test : Outils d’exécution des tests

Automatisation de l’exécution des tests

Le sujet de l'automatisation des tests (généralement via une interface utilisateur graphique) figure en tête des priorités pour la plupart des testeurs et responsables des tests. En surface, ces outils semblent prometteurs, mais de nombreuses organisations qui souhaitent automatiser tout ou partie de leurs tests fonctionnels rencontrent des difficultés.

Nous n’entrerons pas dans des détails techniques dans cet article, mais nous évoquerons quelques-uns des aspects pertinents pour les responsables de tests et de projets qui doivent monter un dossier pour l’automatisation. Nous aborderons :

• Ce que vous apportent – et n’apportent PAS – les outils d’exécution de tests
• Automatisation des tests d'interface utilisateur graphique (GUI)
• Automatisation des tests d’API et de services
• Tests de régression
• Cadres d’automatisation des tests

Il est important de définir des attentes réalistes quant à ce que l’automatisation peut ou non accomplir, c’est pourquoi les sections suivantes pourront sembler quelque peu pessimistes.

A WEEKLY 5 MINUTE READ

Upgrade your inbox with more tech leadership wisdom for delivering better software and systems.

Instagram

This field is for validation purposes and should be left unchanged.

Your email*

By submitting you agree to receive occasional emails and acknowledge our Privacy Policy. You can unsubscribe at anytime.

Ce que vous apportent – et n’apportent PAS – les outils d’exécution de tests

Que vous testiez des applications Windows de bureau, des sites web ou des appareils mobiles, les principes de l’automatisation des tests, les avantages et les pièges restent similaires. Les outils vous offrent :

• Un robot infatigable, supposément exempt d’erreurs, capable d’exécuter à la demande n’importe quels tests scriptés, aussi souvent que vous le souhaitez.
• Une comparaison précise entre la sortie et/ou le résultat des tests et les résultats attendus, au niveau de granularité que vous aurez programmé dans l’outil.

Voici ce que vous n’obtenez pas :

• De la flexibilité et une réaction fluide face aux anomalies, défaillances ou comportements douteux.
• Le regard et la réflexion d’un(e) testeur/euse humain(e), capable de prendre des décisions, d’explorer, d’interroger, d’expérimenter et de remettre en cause le comportement du système testé.
• Des tests gratuits. Il vous faut malgré tout concevoir les tests, préparer les données ainsi que les résultats attendus, par exemple.
• Bien que les outils d’exécution de tests proposent diverses fonctionnalités, ils manquent souvent de capacités avancées de stockage de données. Pour une solution plus complète, vous pouvez consulter les meilleurs logiciels de gestion de base de données disponibles.

Voyons plus en détail l’importance de ces avantages et inconvénients.

Si vous êtes un programmeur raisonnablement compétent, il est relativement simple de transformer des tests procéduraux exécutés par des humains en procédures automatisées dans le langage de script de votre outil, pour que l’outil les exécute fidèlement.

Tant que l’environnement et les données utilisés par votre application de test demeurent constants, vous pouvez vous attendre à ce que vos tests s’exécutent de façon fiable encore et encore. C’est la promesse évidente de l’automatisation des tests.

Mais les tests automatisés ne simulent pas fidèlement ce que font les (bons) testeurs lors des tests.

Un test exécuté par un outil N’EST PAS équivalent au même test réalisé par une personne.

Un test scripté peut bien indiquer au testeur quoi faire. Mais les testeurs peuvent aller au-delà de la simple comparaison entre le résultat attendu et le résultat affiché à l’écran.

Les testeurs doivent naviguer jusqu’à l’emplacement du test et rester attentifs à tout comportement inhabituel : la réaction aux commandes, la vitesse de réponse, l’apparence de l’écran, le comportement des objets influencés par l’évolution de l’état de l’application.

Le testeur humain, face à une anomalie, peut s’arrêter, revenir sur ses pas ou approfondir l’analyse de l’application ou des données avant de conclure que l’application fonctionne ou non correctement, et décider de poursuivre le test scripté, d’ajuster les données ou le script, ou de continuer comme prévu.

Les humains sont flexibles tandis que les outils ne font exactement que ce pour quoi vous les avez programmés. Lors d'une transaction à l'écran, l'outil saisit des données, clique sur un bouton et vérifie un message ou un résultat affiché – et rien de plus. Avec des testeurs humains, vous obtenez bien plus, ce que nous tenons pour acquis. 

En principe, il est possible de programmer un outil pour effectuer tous les contrôles qu'un humain fait instinctivement – mais il faudra écrire beaucoup de code et passer du temps à déboguer vos tests. Même dans ce cas, vous ne disposez pas de la capacité humaine à décider de la suite à donner – faire une pause, continuer, modifier le test en cours de route ou explorer plus en profondeur une anomalie.

Rien ne démontre davantage le manque de flexibilité des outils que leur réaction à une perte de synchronisation entre le script et le système à tester. Il se peut qu’un résultat attendu ne corresponde pas, que le système plante ou que le comportement de l’interface utilisateur (un ordre de champs modifié ou un nouveau champ, par exemple) diffère de ce à quoi s’attendait le script. Que fait l’outil ? Il tente de poursuivre et une avalanche d’échecs de scripts ou de plantages s’ensuit. 

Oui, vous pouvez – et devez – intégrer dans votre script des gestionnaires d’événements imprévus pour piéger les défaillances de test. Perte de synchronisation, incohérences entre l’état du système et les données de test, changements d’ordre, nouveaux ou suppression de champs sont autant de situations qu’un testeur humain sait reconnaître et prendre en compte sans que les tests ne s’arrêtent complètement. Les outils ne peuvent pas faire cela sans de gros efforts de programmation de votre part.

Il existe aussi des inconvénients à utiliser des humains pour suivre des tests scriptés. Les testeurs peuvent devenir obsédés par l’obéissance au script et oublier d’utiliser leurs compétences d’observation. Ils peuvent passer à côté d'anomalies flagrantes à force de se concentrer sur le suivi du script. Cette approche sous-optimale, c'est précisément ce que nous obtenons par l'automatisation de l'exécution des tests.

Un suivi aveugle des scripts de test est une mauvaise idée pour les testeurs humains, mais c'est le mieux que nous puissions faire avec l'automatisation des tests.

Dans cette comparaison entre des testeurs suivant des scripts et des outils exécutant des tests, nous n'avons pas évoqué ce que font les testeurs exploratoires. L'approche exploratoire donne aux testeurs la liberté d’investiguer et de tester où et comme ils veulent. 

De toute évidence, les outils ne peuvent pas simuler cette activité. Plus important encore, les outils ne peuvent pas définir l’étendue, prioriser, modéliser la fonctionnalité et les risques d’un système, ni concevoir les tests en conséquence.

Les activités d'analyse et de conception des tests sont nécessaires, que le test soit exécuté par un humain ou par un outil.

Il existe d'autres limitations sur ce que les outils d'exécution de tests peuvent faire :

• Les outils d'exécution de tests font exactement ce que vous programmez – pas plus, pas moins
• Les outils ne réalisent généralement pas la construction, la configuration de l’environnement et des applications, ni le chargement des données de test
• Les outils ne conçoivent pas de scénarios ou scripts de test, ni la préparation des données de test ou des résultats attendus
• Les outils ne peuvent pas prendre de décisions réfléchies en cas d’événements inattendus.

Pour optimiser vos processus d'exécution des tests, l'intégration avec un logiciel de gestion de tests robuste peut offrir des méthodes de travail rationalisées et des rapports améliorés.

Automatisation des tests d’interface utilisateur graphique (GUI)

Voilà plus de vingt-cinq ans que les outils d’automatisation des tests GUI sont sur le marché, et pourtant, le nombre d’échecs de leur mise en œuvre reste élevé. Cela s’explique principalement par des attentes trop élevées envers l’automatisation – et des outils utilisés sans discipline ne permettront jamais de les atteindre.

Les outils d’automatisation des tests GUI ont la réputation d’être faciles à utiliser côté produit, mais difficiles à gérer lorsque les applications à tester (et donc les scripts de test) doivent évoluer. Ces outils sont extrêmement sensibles aux modifications de l’interface utilisateur. Un changement d’emplacement, d’ordre, de taille, l’ajout ou la suppression d’objets à l’écran peuvent tous impacter les scripts. Des changements plus techniques, comme le renommage d’objets ou la modification de bibliothèques GUI « invisibles » intégrées, posent aussi problème.

L’automatisation des tests GUI fonctionne mieux lorsqu’il y a de la rigueur concernant :

• Le processus de développement, et les changements et versions sont soigneusement gérés. Par exemple, les changements sont analysés pour leur impact et signalés aux testeurs. 
• L’approche de développement des scripts de test. Les ingénieurs expérimentés en automatisation appliquent des conventions de nommage systématiques, des structures de répertoires, des composants modulaires et réutilisables, des techniques de programmation défensive, etc.

L’écriture de scripts d’automatisation de test est une tâche qui requiert bien plus que des compétences de programmation de base, et surtout, de l’expérience en automatisation et sur l’outil utilisé. Lorsque les tests sont automatisés à grande échelle, des compétences en conception sont également nécessaires. 

Peu importe la façon dont les éditeurs décrivent leurs outils – « sans script », « utilisable par des non-programmeurs » ou « les utilisateurs aussi peuvent automatiser » – il faut malgré tout une mentalité de programmeur, des compétences en conception et une approche systématique.

Automatisation des tests d’API et de services

Lorsque des composants ou des fonctionnalités sont déployés sous forme de services, appelés par des clients légers ou mobiles, les tests sont réalisés via une API ou des appels de services. Ce mode de test s’effectue avec du code personnalisé écrit par les développeurs ou à l’aide d’outils spécialisés dans les tests d’API ou de services. Quoi qu’il en soit, l’approche courante consiste à automatiser ces tests d’une manière ou d’une autre.

Parce que l’API est « plus proche » du code à tester, les tests peuvent être beaucoup plus ciblés sur la fonctionnalité à vérifier. Bien entendu, les complexités de la navigation via l’interface utilisateur et des tests par l’interface elle-même peuvent être contournées. Pour cette raison, la règle générale est :

Si la fonctionnalité à tester (au niveau du code ou du composant) peut être vérifiée via un appel de fonction, une API ou un service, l’automatisation sera plus facile – et est recommandée.

Les tests via l’API présentent des avantages certains.

• Bien qu’il faille utiliser ou écrire du code, les tests eux-mêmes seront bien plus simples à appliquer (il n’y a pas d’interface utilisateur à gérer).
• Une fois qu’un appel d’API est scripté, il s’agit simplement de répertorier la gamme de cas de test à appliquer. Il n’y a aucune limite au nombre de tests que vous pouvez exécuter.
• Les tests basés sur l’API s’exécutent généralement beaucoup plus rapidement, ce qui rend ce style de test particulièrement adapté aux approches de livraison continue où le pipeline de déploiement est hautement automatisé et doit réagir rapidement.

La « pyramide d’automatisation des tests » (une recherche Google montre des centaines d’exemples graphiques) a été adoptée presque universellement pour illustrer la recommandation selon laquelle les efforts d’automatisation des tests devraient se concentrer davantage sur les tests au niveau du développement ou de l’API, plutôt que via l’interface graphique.

• Utilisez les tests d’interface utilisateur lorsque le parcours utilisateur doit être vérifié, mais en faible volume car ces tests sont coûteux et peuvent être lents à exécuter.
• Utilisez des appels d’API ou de services quand la fonctionnalité testée peut être isolée et que la rapidité et la facilité d’automatisation sont essentielles.

Tests de régression

L’utilisation classique des outils d’automatisation est l’exécution de tests de régression. Ces tests sont exécutés une fois et considérés comme des représentations fiables du comportement attendu. Lorsque le code applicatif à tester, les bibliothèques réutilisables associées ou l’environnement de test évoluent, ces tests offrent une certaine assurance que les fonctionnalités requises n’ont pas été altérées par ce changement.

Vous pouvez imaginer les tests automatisés comme un moule dans lequel le système testé doit s’insérer. Bien sûr, les tests doivent « réussir » tous les contrôles précédemment effectués. En les relançant, vous essayez de démontrer l’équivalence fonctionnelle de la nouvelle version logicielle par rapport à l’ancienne. Voici quelques principes simples à suivre :

• Premièrement, les tests et vérifications effectués doivent être choisis pour vous donner confiance que des changements indésirables de comportement n’existent pas. Ces tests agissent comme un « fil-piège » permettant de détecter les écarts de comportement.
• Lorsqu’un bug est corrigé ou que d’autres changements logiciels sont appliqués, certains comportements peuvent être modifiés (correctement) mais, détectés par vos tests, ceux-ci échoueront. Il vous faut alors modifier vos tests à l’avance ou bien les laisser échouer puis les adapter ensuite. Parfois, il est plus rapide de supprimer totalement les tests en échec et d’en créer de nouveaux pour les remplacer. Quoi qu’il en soit, ces tests modifiés doivent alors être exécutés jusqu’au bout et réussir.
• Si le système testé n’est pas stable, avec beaucoup de bugs ou subissant de nombreuses modifications entre les versions, il n’est peut-être pas rentable de maintenir un ensemble de tests automatisés. Même si la fonctionnalité ne change pas, l’interface utilisateur peut encore évoluer – une interface instable complique aussi la maintenance des tests automatisés. Le coût d’investigation des échecs et de maintenance des tests peut dépasser leur utilité. Il est parfois préférable de tester manuellement les parties instables du système jusqu’à ce qu’elles se stabilisent.

Les tests via l’interface utilisateur peuvent être lourds, coûteux et longs à exécuter. Avant de vous lancer dans l’automatisation de tests graphiques, ou même d’automatiser un simple script, il est judicieux de se demander si la vérification des fonctionnalités clés ne serait pas plus simple, rapide et économique en utilisant une API.

L’utilisation classique des outils automatisés est l’exécution des tests de régression. Pour vous assurer d’utiliser les outils les plus efficaces pour cela, consultez notre liste des meilleurs outils de test logiciel

Frameworks d’automatisation des tests

Les frameworks de test sont une composante essentielle de tout processus d’automatisation réussi. Considérez-les comme un ensemble de bonnes pratiques pour créer et concevoir des scénarios de test. Leur utilisation peut augmenter la rapidité et l’efficacité de l’équipe de test, améliorer la précision, diminuer les risques et réduire les coûts de maintenance des tests. Examinons maintenant deux de ces frameworks.

En parlant de frameworks d’automatisation des tests, il est indispensable de considérer le rôle des outils d’automatisation QA dans la définition d’une stratégie de test efficace.

Frameworks de tests unitaires

Les frameworks de tests unitaires existent depuis plusieurs années et sont largement utilisés par les programmeurs pour tester leur code. Les tests côté développeur sont en général très localisés – ils testent la plupart du temps un seul composant avec les interfaces vers d’autres composants ou bases de données simulées ou remplacées. Ainsi, bien que des étapes de préparation et de nettoyage soient nécessaires avant et après l’exécution des tests, ces tâches se limitent généralement au test d’un seul composant. Des batteries de tests spécifiques existent pour chaque composant.

Les tests unitaires créés par les développeurs sont généralement placés sous contrôle de version et gérés en parallèle du code des composants. Typiquement, les solutions d’intégration continue prennent le code source et tous les tests unitaires et les exécutent après chaque validation de nouveau code et/ou de nouveaux tests. Tous les développeurs voient le résultat de ces tests, de sorte qu’un échec de test dans l’IC devient très visible. Corriger les tests et le code en échec est une priorité élevée dans les équipes qui utilisent l’IC de cette façon, afin que la dernière version du système réussisse tous les tests de l’IC en permanence.

Cadres d'automatisation des tests d’intégration et système

Ces dernières années, les outils de test d'interface graphique (GUI) ont été intégrés aux outils d’intégration continue à l’aide d’environnements de test virtualisés, de dispositifs virtuels et de l’exécution via des interfaces en ligne de commande. Beaucoup d’organisations ont pu complètement intégrer l’exécution des tests unitaires, au niveau API et GUI grâce aux services d’IC.

Cependant, de nombreuses équipes de test utilisent encore leurs propres environnements de test distincts des services de développement ou d’IC. Ces équipes ont tendance à développer leurs propres cadres d’automatisation des tests, car les outils d’IC sont trop axés sur les développeurs ou les outils propriétaires sont inadéquats.

Les tests GUI sont souvent utilisés pour mettre en œuvre des tests de bout en bout ou des parcours utilisateurs avec différentes applications, dispositifs matériels et environnements. Ces tests doivent mettre en place sans heurt des environnements de test intégrés et des données de test préparées sur des plateformes variées, ce qui requiert des procédures privilégiées, complexes et des environnements techniques divers. La grande majorité des équipes utilisant l’automatisation des tests GUI conçoivent leurs propres cadres d’automatisation uniques, mais efficaces.

Les cadres d’automatisation GUI varient en complexité, allant d’outils semblables aux tests unitaires jusqu’à des solutions complexes et complètes permettant de gérer les environnements, les constructions applicatives, de hauts volumes de données de tests, la messagerie et la synchronisation entre plateformes et environnements, ainsi que la notification et la messagerie à destination des membres de l’équipe.

Certains outils propriétaires disposent d’utilitaires ou de harnais permettant de gérer, d’exécuter et de générer des rapports à partir de batteries de tests automatisés. Leur valeur varie, c’est pourquoi de nombreuses organisations développent leurs propres cadres d’automatisation des tests pour étendre leur fonctionnalité. Ces dernières années, le périmètre de ces cadres d’automatisation s’est élargi, et il n’existe plus de définition unique ou simple, nous allons donc à présent examiner ce qu’un cadre d’automatisation des tests peut offrir à une équipe logicielle.

Un cadre d’automatisation des tests étend la fonctionnalité des moteurs d’exécution de tests.

Configuration de la suite de tests

Le cadre intègre les tests automatisés dans des ensembles ou groupes pertinents de tests. Ces ensembles sont configurables, car les tests peuvent être exécutés en hiérarchies de séquences, de groupes, ou par sélections arbitraires. Ces outils peuvent inclure des fonctionnalités pour piloter des tests à partir de tableaux de données de test préparées. C'est le cadre le plus simple — les outils populaires proposent habituellement une forme de configuration de suite de tests.

Mise en place et nettoyage

Le cadre prend en charge toutes les activités de mise en place et de nettoyage (tear-down) pour un test individuel, un ensemble ou une suite complète. La mise en place peut consister à créer des environnements de test à partir de zéro, des configurations complètes et à précharger les bases de données de test et autres sources de données dès le départ. Le nettoyage peut impliquer la purge des données de test ou la réinitialisation ou la suppression partielle ou complète d’environnements. Le cadre peut être intégré à des outils d’orchestration de pipelines et être contrôlé par eux.

Gestion des exceptions

Un échec dans n’importe quel test – que ce soit dans le système testé ou une perte de synchronisation – peut être géré de façon cohérente par la signalisation de l’événement et, généralement, en permettant l’exécution des autres tests de ce groupe. Le cadre peut être programmé pour gérer les échecs de vérification de test, les pertes de synchronisation, les dépassements de temps d’exécution et d’autres résultats sélectionnés – chacun avec des procédures personnalisées.

Journalisation et messagerie

Le cadre journalise l’exécution et le statut des tests de manière cohérente sur l’ensemble des groupes de tests. Le cadre déclenche soit des rapports à partir des outils qui exécutent les tests, soit fournit un journal de compte-rendu cohérent de toutes les activités de préparation, d’exécution et de nettoyage des tests. Le cadre peut interagir avec des bots ChatOps pour informer l’équipe des exceptions et permettre aux membres de l’équipe de mettre en pause, arrêter, répéter ou relancer les suites de tests.

Abstraction des tests avec langage spécifique au domaine

Deux types distincts de cadres qui abstraient le code d’exécution des tests en modèles, ou en texte lisible par l’humain ou non technique, ont émergé sur le marché :

• Les cadres pilotés par mots-clés permettent de définir des tests à l’aide de mots-clés. Les appels aux fonctionnalités du moteur d’exécution sont implémentés comme des commandes ressemblant à l’anglais, avec des paramètres ou des données en variable. Des modules personnalisés et réutilisables peuvent être définis et appelés de la même façon, à l’aide de commandes en texte clair. Des cadres existent pour toutes sortes d’interfaces, y compris GUI, service, API, interpréteurs de ligne de commande, etc. Les scripts peuvent exploiter des fonctionnalités sur différentes plateformes système et dispositifs.
• Les cadres de Développement Dirigé par le Comportement (BDD) permettent de capturer des histoires et des scénarios (exemples) décrivant le comportement fonctionnel à l’aide d’un langage spécifique au domaine (DSL). Le langage le plus répandu est le langage dit Gherkin, qui utilise la structure « étant donné … quand … alors … » pour formaliser les exemples. « Étant donné / quand / alors » représente respectivement les pré-conditions, les étapes et les post-conditions des cas de test. Les outils BDD convertissent le texte « étant donné/quand/alors » en ‘appel d’étape’ dans un langage de programmation. Le développeur (ou testeur) doit implémenter les « fixtures » ou le code permettant d’effectuer les appels au moteur d’exécution de test. Ainsi, le langage d’une exigence (l’histoire) peut être directement relié au code d’exécution de test.

Cadres basés sur des modèles

Dans ce cas, les outils permettent de créer un modèle du système à tester. Celui-ci peut être généré automatiquement à partir d'une page web, où l'outil analyse le HTML, détecte les formulaires et les champs, et construit un modèle à partir duquel les parcours à travers les formulaires peuvent être soit générés automatiquement, soit sélectionnés par le testeur. Les cartes d’objets pour les applications mobiles ou autres appareils intelligents peuvent également être créées manuellement. En utilisant ces parcours à travers la carte d’objets, des appels aux fonctionnalités du moteur d’exécution des tests sont effectués de manière similaire aux outils BDD et pilotés par mots-clés. En principe, les tests peuvent être construits graphiquement sans code. Les outils dans ce domaine sont relativement récents et s’améliorent rapidement. Leur utilisation devrait s’accélérer à l’avenir.

Inscrivez-vous à la newsletter The QA Lead pour être informé de la publication des nouveaux volets de la série. Ces articles sont des extraits du cours Leadership In Test de Paul que nous recommandons fortement pour approfondir ce sujet et d'autres. Si vous vous inscrivez, utilisez notre code promo exclusif QALEADOFFER pour bénéficier de 60 $ de réduction sur le prix total du cours !

Lecture connexe : 10 MEILLEURS OUTILS DE SURVEILLANCE DES SERVEURS WEB