Tests logiciels 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.

1. 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.

2. Tests unitaires

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é.

3. 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.

4. 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.

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

Atlassian Open DevOps fournit une plateforme de chaîne d'outils ouverte qui vous permet de créer un pipeline de développement de CD avec les outils que vous aimez. Découvrez comment Atlassian et des outils tiers peuvent intégrer les tests à votre workflow grâce à nos tutoriels de tests DevOps.