Qu’est-ce que l’automatisation des tests ? Une introduction simple et claire
Il existe deux types de tests dans le monde du logiciel – les tests manuels et les tests automatisés. Certains types de tests manuels, tels que les tests de découverte et les tests d’utilisabilité, sont inestimables. Vous pouvez faire d’autres types de tests – comme les tests de régression et les tests fonctionnels – manuellement, mais c’est une pratique assez gaspilleuse pour les humains de continuer à faire la même chose encore et encore. Ce sont ces types de tests répétitifs qui se prêtent à l’automatisation des tests.
L’automatisation des tests est la pratique consistant à exécuter des tests automatiquement, à gérer les données de test et à utiliser les résultats pour améliorer la qualité des logiciels. C’est avant tout une mesure d’assurance qualité, mais ses activités impliquent l’engagement de toute l’équipe de production du logiciel. Des analystes commerciaux aux développeurs et aux ingénieurs DevOps, tirer le meilleur parti de l’automatisation des tests nécessite l’inclusion de tous.
Ce post vous donnera une compréhension de haut niveau de ce qu’est l’automatisation des tests. Il existe toutes sortes de tests, mais tous ne doivent pas être automatisés ; par conséquent, commençons par les critères généraux d’automatisation des tests.
Critères d’automatisation
Un test doit répondre à certains critères pour être automatisé – sinon, il pourrait finir par coûter plus qu’il ne sauve. Après tout, l’un des principaux objectifs de l’automatisation est d’économiser du temps, des efforts et de l’argent. Voici quelques critères généraux pour l’automatisation des tests. Il s’agit de points de départ. Vos critères peuvent différer en fonction de vos circonstances.
Répétitif
Le test doit être répétable. Il n’y a aucun sens à automatiser un test qui ne peut être exécuté qu’une seule fois. Un test répétable comporte les trois étapes suivantes :
- Mise en place du test, y compris les données et l’environnement.
- Exécution de la fonction et mesure du résultat.
- Nettoyage des données et de l’environnement.
Dans la première étape, nous voulons pouvoir mettre l’environnement dans un état cohérent. En d’autres termes, si nous avons un test pour tenter d’ajouter un utilisateur existant, nous devons nous assurer que l’utilisateur existe avant d’effectuer le test. Une fois le test terminé, l’environnement doit être ramené à l’état de base.
Déterminant
Quand une fonction est déterminante, cela signifie que le résultat est le même chaque fois qu’elle est exécutée avec la même entrée. Il en va de même pour les tests qui peuvent être automatisés. Par exemple, disons que nous voulons tester une fonction d’addition. Nous savons que 1 + 1 = 2 et que 394,19 + 5,81 = 400,00. L’addition est une fonction déterminante.
Les logiciels, en revanche, peuvent utiliser un nombre tellement élevé d’entrées variables qu’il est difficile d’avoir le même résultat au fil du temps. Certaines variables peuvent même être aléatoires, ce qui peut rendre difficile la détermination du résultat spécifique. La conception de logiciels peut compenser cela en permettant des entrées de test par le biais d’un harnais de test.
D’autres caractéristiques d’une application peuvent être additives ; par exemple, la création d’un nouvel utilisateur ajouterait au nombre d’utilisateurs. Au moins, lorsque nous ajoutons un utilisateur, nous savons que le nombre d’utilisateurs ne devrait augmenter que de un. Cependant, l’exécution de tests en parallèle peut entraîner des résultats inattendus. L’isolation peut empêcher ce genre de faux positif.
Unopinionated
On ne peut pas automatiser les questions d’opinion. C’est là que les tests d’utilisabilité, les tests bêta, et ainsi de suite, brillent vraiment. La rétroaction des utilisateurs est importante, mais elle ne peut tout simplement pas être automatisée… désolé!
Types de tests automatisés
Il y a tellement de types de tests, dont beaucoup peuvent être automatisés, que nous ne pouvons pas vraiment les inclure tous dans un seul post. Mais en voici suffisamment pour vous donner un bon point de départ.
Analyse de code
Il existe en fait de nombreux types d’outils d’analyse de code, notamment l’analyse statique et l’analyse dynamique. Certains de ces tests recherchent les failles de sécurité, d’autres vérifient le style et la forme. Ces tests s’exécutent lorsqu’un développeur vérifie le code. En dehors de la configuration des règles et de la mise à jour des outils, il n’y a pas beaucoup d’écriture de test à faire avec ces tests automatisés.
Tests unitaires
Vous pouvez également automatiser une suite de tests unitaires. Les tests unitaires sont conçus pour tester une seule fonction, ou unité, de fonctionnement de manière isolée. Ils s’exécutent généralement sur un serveur de construction. Ces tests ne dépendent pas des bases de données, des API externes ou du stockage des fichiers. Ils doivent être rapides et sont conçus pour tester le code uniquement, et non les dépendances externes.
Tests d’intégration
Les tests d’intégration sont un autre type d’animal lorsqu’il s’agit d’automatisation. Puisqu’un test d’intégration – parfois appelé test de bout en bout – doit interagir avec des dépendances externes, ils sont plus compliqués à mettre en place. Souvent, il est préférable de créer de fausses ressources externes, en particulier lorsqu’il s’agit de ressources hors de votre contrôle.
Si vous avez, par exemple, une appli de logistique qui dépend d’un service web d’un fournisseur, votre test peut échouer de manière inattendue si le service du fournisseur est en panne. Cela signifie-t-il que votre application est cassée ? C’est possible, mais vous devriez avoir suffisamment de contrôle sur l’ensemble de l’environnement de test pour créer chaque scénario de manière explicite. Ne dépendez jamais d’un facteur externe pour déterminer le résultat de votre scénario de test.
Tests d’acceptation automatisés
Il existe aujourd’hui plusieurs pratiques qui utilisent les tests d’acceptation automatisés (AAT), mais elles font fondamentalement la même chose. Le développement guidé par le comportement (BDD) et le développement guidé par les tests d’acceptation automatisés (AATDD) sont similaires. Ils suivent tous deux la même pratique consistant à créer le test d’acceptation avant le développement de la fonctionnalité.
A la fin, le test d’acceptation automatisé s’exécute pour déterminer si la fonctionnalité fournit ce qui a été convenu. Par conséquent, il est essentiel que les développeurs, l’entreprise et l’assurance qualité écrivent ces tests ensemble. Ils servent de tests de régression à l’avenir et garantissent que la fonctionnalité tient la route par rapport à ce qui est attendu.
Tests de régression
Sans AAT en place, vous devez écrire des tests de régression après coup. Bien que les deux soient des formes de tests fonctionnels, la façon dont ils sont écrits, le moment où ils sont écrits et par qui ils sont écrits sont largement différents. Comme les AAT, ils peuvent être pilotés par le code d’une API ou par une interface utilisateur. Des outils existent pour écrire ces tests à l’aide d’une interface graphique.
Tests de performance
Plusieurs types de tests de performance existent, mais ils testent tous un aspect de la performance d’une application. Est-ce qu’elle résistera à une pression extrême ? Est-ce que nous testons le système pour une chaleur élevée ? Est-ce le simple temps de réponse sous charge que nous recherchons ? Et l’évolutivité ?
Parfois, ces tests nécessitent d’émuler un nombre massif d’utilisateurs. Dans ce cas, il est important de disposer d’un environnement capable de réaliser un tel exploit. Des ressources cloud sont disponibles pour aider à ce type de tests, mais il est également possible d’utiliser des ressources sur site.
Tests de fumée
Qu’est-ce qu’un test de fumée ? C’est un test de base qui est généralement effectué après une fenêtre de déploiement ou de maintenance. L’objectif d’un test de fumée est de s’assurer que tous les services et dépendances sont opérationnels. Il ne s’agit pas d’un test fonctionnel complet. Il peut être exécuté dans le cadre d’un déploiement automatisé ou déclenché par une étape manuelle.
Processus général d’automatisation des tests
Maintenant que nous avons vu les critères d’automatisation et suffisamment de types de tests automatisés pour avoir une idée des choses, voici le processus général d’automatisation des tests. Il y a trois étapes majeures à l’automatisation des tests : préparer, prendre des mesures, rapporter les résultats.
Préparer
Premièrement, nous devons préparer l’état, les données de test, et l’environnement où les tests ont lieu. Comme nous l’avons vu, la plupart des tests exigent que l’environnement soit dans un certain état avant qu’une action ait lieu. Dans un scénario typique, cela nécessite une certaine configuration. Soit les données devront être manipulées, soit l’application devra être mise dans un état spécifique, soit les deux !
Prise d’action
Une fois que l’état et/ou l’environnement est dans l’état prédéfini, il est temps de prendre des mesures ! Le pilote de test va exécuter le test, soit en appelant l’API ou l’interface utilisateur d’une application, soit en exécutant directement le code. Le pilote de test est responsable de la « conduite » des tests, mais le système de gestion des tests prend la responsabilité de tout coordonner, y compris le rapport des résultats.
Rapport des résultats
Un système d’automatisation des tests enregistrera et rapportera les résultats. Ces résultats peuvent se présenter sous un certain nombre de formats différents et peuvent même créer des tickets de problème ou des bogues dans un système de suivi du travail. Le résultat de base, cependant, est un succès ou un échec. Habituellement, il y a un indicateur vert ou rouge pour chaque scénario de test pour indiquer la réussite ou l’échec.
Parfois, les tests ne sont pas concluants ou ne s’exécutent pas pour une raison quelconque. Lorsque cela se produit, le système d’automatisation aura un journal complet de la sortie pour les développeurs à examiner. Ce journal les aide à retrouver le problème. Idéalement, ils seront en mesure de rejouer le scénario une fois qu’ils auront mis en place une correction.
La ligne de fond
La ligne de fond est la suivante : l’automatisation des tests permet d’améliorer la qualité avec rapidité. Mais tous les tests ne peuvent pas être automatisés. Il y a certainement un investissement à faire. Avec autant de types de tests, il est important que vous obteniez le bon mélange. La pyramide des tests est une règle empirique simple qui permet d’y parvenir. Elle indique que la plupart des tests doivent être des tests unitaires, suivis des tests de service, puis des tests d’interface utilisateur.
Un système d’automatisation des tests coordonne les préoccupations liées aux tests, notamment la gestion des données de test, l’exécution des tests et le suivi des résultats. L’automatisation des tests est la prochaine étape pour les équipes qui deviennent submergées par le fardeau de répéter les mêmes tests manuels qui devraient être automatisés.
Bio de l’auteur : Ce billet a été rédigé par Phil Vuollet. Phil utilise des logiciels pour automatiser les processus afin d’améliorer l’efficacité et la répétabilité. Il écrit sur des sujets pertinents pour la technologie et les affaires, donne occasionnellement des conférences sur ces mêmes sujets, et est un père de famille qui aime jouer au football et aux jeux de société avec ses enfants.