Tests logiciels automatisés

Cernez les différences entre les tests logiciels automatisés et manuels et apprenez à planifier une solution de test automatisée pour votre équipe.

Max Rehkopf Max Rehkopf

Que sont les tests automatisés ?

Les tests automatisés désignent l'application d'outils logiciels pour automatiser un processus manuel de revue et de validation d'un produit logiciel. La plupart des projets logiciels Agile et DevOps modernes incluent désormais des tests automatisés dès leur création. Cependant, pour apprécier pleinement la valeur des tests automatisés, il est utile de comprendre ce qu'était la vie avant qu'ils ne soient largement adoptés.

À l'époque où les tests manuels étaient la norme, il était courant pour les éditeurs de logiciels d'employer une équipe de QA à plein temps. Cette équipe développait une série de « plans de test », c'est-à-dire des checklists étape par étape qui garantissaient qu'une fonctionnalité d'un projet logiciel se comportait comme prévu. L'équipe de QA exécutait ensuite manuellement ces checklists chaque fois qu'une nouvelle mise à jour ou qu'un nouveau changement était pushé(e) dans le projet logiciel, puis renvoyait les résultats des plans de test à l'équipe d'ingénierie pour revue et développement ultérieur afin de résoudre les problèmes.

Ce processus était lent, coûteux et source d'erreurs. L'automatisation des tests apporte des gains énormes en termes d'efficacité et de ROI des équipes de QA.

Avec les tests automatisés, la propriété revient à l'équipe d'ingénierie. Les plans de test sont élaborés parallèlement au développement régulier des fonctionnalités sur la feuille de route, puis exécutés automatiquement par les outils d'intégration continue des logiciels. Les tests automatisés favorisent la réduction de la taille de l'équipe de QA et permettent à cette dernière de se concentrer sur des fonctionnalités plus sensibles.

Une illustration graphique des tests automatisés.

Pourquoi l'automatisation des tests est-elle importante pour la livraison continue ?

La livraison continue (CD) repose sur la livraison de nouvelles versions de code aussi rapidement que possible aux clients. Les tests automatisés sont essentiels pour atteindre cet objectif. Il est impossible d'automatiser la livraison aux utilisateurs si le processus de livraison comprend une étape manuelle chronophage.

La CD fait partie d'un pipeline de déploiement plus large. Elle succède à l'intégration continue (CI), dont elle dépend également. La CI est entièrement responsable d'exécuter les tests automatisés pour tout nouveau changement de code et de garantir que ces changements ne font pas crasher les fonctionnalités établies ou n'introduisent pas de nouveaux bugs. La CD est déclenchée lorsque le plan de tests automatisés valide l'étape de CI.

Cette relation entre les tests automatisés, la CI et la CD présente de nombreux avantages pour une équipe de développement haute vélocité. Les tests automatisés garantissent la qualité à chaque phase du développement en s'assurant que les nouveaux commits n'introduisent pas de bugs. Le logiciel reste ainsi prêt à être déployé à tout moment.

Diagramme décrivant la relation entre les tests automatisés, l'intégration continue et la livraison continue.

Quels types de tests logiciels doivent être automatisés en premier ?

Tests de bout en bout


Les tests les plus utiles à implémenter sont sans doute les tests de bout en bout (E2E). Les tests E2E simulent l'expérience d'un utilisateur sur la suite complète d'un produit logiciel. Les plans de tests E2E couvrent généralement des user stories telles que : « un utilisateur peut se connecter », « un utilisateur peut effectuer un dépôt », « un utilisateur peut modifier les paramètres de son adresse e-mail ». L'implémentation de ces tests est très utile, car ils offrent l'assurance que les utilisateurs réels bénéficient d'une expérience fluide et sans bugs, même lorsque de nouveaux commits sont pushés.

Les outils de test E2E capturent et ré-exécutent les actions des utilisateurs, de sorte que les plans de test E2E consignent les flux d'expérience utilisateur clés. Si un produit logiciel ne dispose d'aucune couverture de test automatisée, il aura le plus de valeur en implémentant des tests E2E des flux métier les plus critiques. Les tests E2E peuvent être initialement coûteux pour capturer et enregistrer la séquence du flux utilisateur. Si le produit logiciel ne fait pas des livraisons quotidiennes rapides, il peut être plus économique d'avoir une équipe humaine qui exécute manuellement les plans de test E2E.

Tests d'unités

Comme leur nom l'indique, les tests unitaires couvrent des unités individuelles de code. Il est préférable de mesurer les unités de code en définitions de fonctions. Un test unitaire couvrira une fonction individuelle. Les tests unitaires vérifieront que l'entrée attendue d'une fonction correspond à la sortie attendue. Il est préférable de couvrir le code qui comporte des calculs sensibles (dans le domaine de la finance, de la santé ou de l'aérospatiale) par des tests unitaires. Ces derniers sont peu coûteux, rapides à implémenter et offrent un ROI élevé.

Tests d'intégration

Il arrive souvent qu'une unité de code fasse appel à un service tiers. La base de code primaire testée n'aura pas accès au code de ce service tiers. Les tests d'intégration consistent à simuler ces dépendances tierces et à vérifier que le code qui s'y connecte se comporte comme prévu.

Les tests d'intégration sont similaires aux tests unitaires dans la manière dont ils sont écrits et dans les outils impliqués. Ils peuvent être une alternative peu coûteuse aux tests E2E. Cependant, le ROI est discutable lorsque les tests unitaires et E2E sont déjà combinés.

Tests de performance

Dans le contexte du développement logiciel, le terme « performance » est utilisé pour décrire la vitesse et la réactivité d'un projet logiciel. Voici quelques exemples de métriques de performance : le « temps de chargement de la page », le « temps de premier rendu », le « temps de réponse des résultats de recherche ». Les tests de performance créent des mesures et des assertions pour ces cas pratiques. Les tests de performance automatisés exécutent des cas de test sur ces métriques et alertent ensuite l'équipe en cas de régression ou de perte de vitesse.

Quels types de tests logiciels doivent être réalisés manuellement ?

On peut soutenir que tous les tests qui peuvent être automatisés devraient l'être. Il s'agit d'un gain énorme en termes de productivité et de coût en jours-hommes. Cela dit, il arrive que le développement d'une suite de tests automatisés ne soit pas suffisamment rentable par rapport à l'exécution d'un test manuel.

Tests exploratoires

Les tests automatisés sont scriptés et suivent une séquence d'étapes pour valider le comportement. Les tests exploratoires sont plus aléatoires et essaient des séquences non scriptées pour trouver des bugs ou des comportements inattendus. Bien qu'il existe des outils logiciels pour établir une suite de tests exploratoires, ils ne sont pas encore totalement au point et largement adoptés. Il peut être beaucoup plus efficace d'assigner un testeur manuel au sein de l'équipe de QA et de faire appel à la créativité humaine pour explorer comment crasher un produit logiciel.

Tests de régression visuelle

Une régression visuelle se produit lorsqu'un design visuel défaillant est introduit dans l'interface utilisateur d'un logiciel. Il peut s'agir d'éléments mal positionnés, d'une mauvaise police de caractères, ou encore de mauvaises couleurs. Comme pour les tests exploratoires, il existe des outils permettant d'écrire des tests automatisés pour détecter ces régressions. Ces outils font des captures d'écran de différents états d'un produit logiciel et utilisent ensuite la reconnaissance optique de caractères pour les comparer aux résultats attendus. Ces tests sont coûteux à développer, et les outils ne sont pas largement adoptés. La vérification par l'homme peut être beaucoup plus efficace dans le cadre de la recherche de problèmes visuels.

Développez un framework d'automatisation pour votre équipe DevOps

Il n'existe pas de solution globale pour les tests automatisés. Lors de la planification d'une solution de tests automatisés pour votre équipe, certaines considérations sont essentielles.

Fréquence de livraison

Les produits logiciels qui livrent à intervalles fixes, tels que mensuels ou hebdomadaires, peuvent trouver que les tests manuels sont plus adaptés. Les produits logiciels qui livrent plus rapidement bénéficieront grandement de l'automatisation des tests puisque la CI et la CD en dépendent.

Outils disponibles et écosystème

Chaque langage de programmation possède son propre écosystème d'outils et d'utilitaires complémentaires. Chaque type de modèle de tests automatisés a son propre ensemble d'outils qui peuvent ou non être disponibles dans l'écosystème d'un langage de programmation en particulier. Pour réussir, l'implémentation d'un modèle de tests automatisés nécessitera de prendre à la fois en compte le langage et la prise en charge des outils.

Adéquation du produit au marché et maturité de la base de code

Si votre équipe développe un nouveau produit qui n'a pas encore trouvé un public cible ou un modèle commercial, mieux vaut ne pas investir dans des tests automatisés. Ces derniers font office de mécanisme d'assurance pour limiter les régressions de code inattendues. Si votre équipe évolue à haute vélocité, il peut être frustrant et très coûteux de devoir mettre à jour et gérer des tests automatisés lorsque le code change rapidement et de façon importante.

Intégrez les tests automatisés à votre pipeline de CD

Les tests automatisés sont monnaie courante parmi les pratiques de développement logiciel modernes. Les meilleures équipes et entreprises les utilisent. La CI/CD dépend de tests automatisés et est essentielle pour aider les meilleures équipes à livrer des logiciels fiables et robustes à leurs clients. Commencez à explorer les solutions de CI/CD sans attendre.