Pourquoi adopter l’approche CI/CD pour les tests ?
Avoir des compétences en TestOps est aujourd’hui une nécessité pour les ingénieurs assurance qualité, au même titre que la capacité à écrire des tests automatisés. Cela est dû à l’amélioration continue de l’approche CI/CD et au nombre croissant d’ingénieurs assurance qualité qui travaillent avec des pipelines (séquence des étapes de CI/CD) et implémentent leurs propres pipelines. Pourquoi le CI/CD est-il aussi efficace pour le contrôle de la qualité ? C’est ce que nous allons voir dans cet article.
Exécution automatique des tests
Les tests automatisés ne sont plus exécutés localement depuis bien longtemps. De nos jours, l’exécution automatique des tests est l’une des principales fonctions des pipelines de CI/CD.
La configuration du pipeline peut être assignée au DevOps. Mais il serait dommage de se priver de la deuxième fonction du CI/CD : le contrôle de la qualité, ou plus précisément, les « murs qualité ».
Le contrôle de la qualité à l’aide des murs qualité
Mais, que sont les murs qualité ? Imaginons que le code d’un produit constitue un château. Chaque jour, les développeurs écrivent du nouveau code, ce qui est susceptible de fragiliser les fondations du château, voire de les détériorer. L’objectif d’un ingénieur assurance qualité est de tester chaque fonctionnalité et de réduire la probabilité que des bugs se retrouvent dans le code du produit. Le manque d’automatisation du processus d’assurance qualité peut faire passer des nuits blanches aux ingénieurs car il n’y a personne pour surveiller les différents indicateurs, surtout à des moments critiques comme le vendredi soir, lorsque tout le monde a envie de quitter le travail au plus vite. Une mauvaise fusion à ce moment-là peut engendrer beaucoup de problèmes par la suite.
Ce problème peut être résolu par la création de contrôles de la qualité pour les indicateurs importants.
Chaque contrôle porte sur une métrique différente. Si le code ne passe pas un contrôle, le mur empêche la fonctionnalité d’entrer. Une fonctionnalité est intégrée au produit seulement si elle passe tous les contrôles et si les bugs potentiels ont été évités.
Quels contrôles de la qualité peuvent être inclus dans le CI/CD ?
Il faut élaborer une liste de vérifications pour s’assurer que le processus soit aussi automatisé que possible. Elle peut être organisée de façon à ce que les vérifications cruciales aient lieu en premier. Une fonctionnalité doit passer toutes les vérifications pour arriver au terme du pipeline avec succès. Les vérifications initiales permettent de s’assurer que l’application est capable de fonctionner : build, vérification du style de code et analyse statique.
S’agissant du « build » : si la phase de construction de l’application ne se passe pas bien, la fonctionnalité ne progresse pas. Il est important d’intégrer une vérification du style du code dans votre pipeline de CI/CD pour vous assurer que le code réponde bien aux standards de votre entreprise : cela vous évitera de perdre du temps sur ce type de bugs lors des révisions de code.
L’analyse statique est un outil extrêmement important pour évaluer la qualité du code. Elle permet de mettre en évidence un grand nombre d’erreurs critiques pouvant provoquer des bugs.
Continuons avec les vérifications de la deuxième étape : les tests unitaires avec analyse de la couverture et contrôle de la qualité de la couverture, les tests d’intégration et les tests systèmes. Nous examinons ensuite les rapports détaillés des résultats pour nous assurer que rien n’a été oublié. À ce stade, on peut aussi effectuer une série de tests non fonctionnels pour vérifier les performances, la facilité d’utilisation et la sécurité, ainsi que des tests de capture d’écran.
Lors du développement d’un pipeline, nous devons prêter attention à deux exigences contradictoires :
- Le pipeline doit garantir la meilleure qualité possible pour les fonctionnalités compte tenu de vos besoins.
- Le temps consacré à l’exécution du pipeline ne doit pas ralentir votre workflow. Généralement, cela ne doit pas prendre plus de 20 minutes.
Exemples d’outils à intégrer dans vos contrôles de la qualité
Mise en évidence du style de code
Un style de code est un ensemble de règles qui doivent être suivies dans chaque ligne de code d’un projet, qui vont des règles d’alignement à des règles comme « ne jamais utiliser de variables globales ».
Vous vous demandez peut-être ce que le style a à voir avec les testeurs. Eh bien beaucoup en fait ! Une vérification du style présente plusieurs avantages pour les experts de l’assurance qualité, mais aussi pour le reste de l’équipe :
- Un style unifié facilite le travail des développeurs avec le code et leur permet d’avoir plus de temps à consacrer à l’implémentation de nouvelles fonctionnalités et à la correction des bugs.
- Un style unifié vous permet de vous dispenser des vérifications du code manuelles et d’utiliser un outil de CI/CD pour exécuter les vérifications à la place.
Les grandes entreprises ont généralement leurs propres guides de style qui peuvent servir d’exemples. Par exemple, Airbnb dispose d’un guide de style JavaScript et Google a également plusieurs guides. Vous pouvez même écrire votre propre guide.
Le choix des outils pour les vérifications de code dépend du langage. Vous pouvez trouver un outil adapté sur GitHub ou découvrir les outils utilisés par d’autres équipes. Les linters utilisent un ensemble de règles et mettent en évidence le code qui ne les respecte pas. Quelques exemples : ktlint pour Kotlin, checkstyle pour Java et eslint pour JavaScript.
Analyse de code statique
L’analyse du code statique est une méthode de débogage qui consiste à examiner le code source sans exécuter le programme. Il existe de nombreux analyseurs de code statique différents sur le marché. Nous allons examiner plus en détail la plateforme que nous sommes en train de développer nous-même : Qodana. Le principal avantage de cet analyseur de code est qu’il inclut un certain nombre d’inspections disponibles dans les environnements de développement JetBrains lorsque nous écrivons du code.
Beaucoup d’entre vous utilisent probablement une approche dans laquelle l’IDE vous aide à écrire le code et vous signale les bugs tels que l’utilisation sous-optimale du code, les exceptions NullPointerExceptions, les doublons, etc.
Mais malheureusement, on ne peut jamais garantir que tous les problèmes critiques identifiés par l’IDE aient été corrigés avant le commit. L’intégration de Qodana dans votre pipeline de CI/CD vous assure que tous les problèmes soient bien traités. Si l’ensemble des problèmes ne peuvent être résolus en une seule fois, vous pouvez sélectionner les plus importants, les ajouter à la base de référence et réduire progressivement la dette technique. Vous évitez ainsi de ralentir le processus de développement tout en gardant les problèmes identifiés sous contrôle.
Couverture de tests
La couverture du code est une métrique qui vous aide à comprendre dans quelle mesure votre code a été couvert par vos tests (généralement des tests unitaires).
Ici, vous devez définir le pourcentage de couverture minimum qui doit être pris en charge. Le code ne peut être mis en production que lorsqu’il a été suffisamment couvert par les tests. Le pourcentage minimum est établi de manière empirique, mais il faut garder à l’esprit que même avec une couverture de 100 %, tous les bugs ne peuvent pas être évités. Selon cet article d’Atlassian, une couverture de 80 % constitue un bon objectif à viser.
Il existe différents analyseurs de couverture pour différents langages, tels que Jacoco pour Java, Istanbul pour JavaScript ou Coverage.py pour Python. Vous pouvez intégrer tous ces analyseurs dans votre pipeline de CI/CD et suivre facilement les métriques.
Façonnage du processus de publication
En plus d’exécuter automatiquement les tests et d’assurer que certaines exigences de qualité du code soient respectées, le CI/CD permet aux testeurs d’organiser le processus de publication.
Ce processus peut être complexe et dépendre d’un grand nombre d’actions manuelles différentes. Il s’agit souvent d’un processus entièrement manuel : l’artefact est créé par un développeur, puis transmis aux testeurs pour vérification, et enfin à la personne chargée de le déployer. Une fois encore, il existe de nombreux goulots d’étranglement potentiels. Par exemple, il est possible que l’une de ces personnes tombe malade ou parte en vacances.
Les critères d’efficacité du processus de publication diffèrent en fonction des équipes, mais il comprend généralement les étapes suivantes :
- Chaque modification dans la branche Git déclenche un build de l’application.
- Le build est soumis à des contrôles de la qualité et ne devient pas une partie de la branche principale tant qu’il n’a pas passé tous les contrôles avec succès.
- Une version candidate stable est extraite de la branche de version ou de la branche principale : cela fixe la version et garantit que rien ne sera publié sans avoir été testé et qu’il n’y aura pas de modification ultérieure. Il est ainsi plus facile de contrôler les versions et toutes les modifications qu’elles contiennent. En outre, en stockant les artefacts de la version stable, vous permettez d’y revenir rapidement si la version publiée ne fonctionne pas correctement.
- La version stable est testée et fait l’objet de vérifications finales.
- La version candidate stable est publiée. Il peut s’agir d’un lancement de pipeline manuelle ou automatisé, si la version candidate a passé tous les contrôles de l’étape précédente. Le choix entre un processus de publication automatique et manuel dépend de la fréquence et de l’importance des publications, ainsi que des préférences des membres de l’équipe et de la facilité du déploiement.
Tout système de CI/CD vous permet de configurer ce type de processus. Le processus doit être pratique pour tous les membres l’équipe, y compris pour les personnes qui sont chargées des tests.
Compte tenu des différents facteurs décrits ci-dessus, il nous semble important de respecter les règles de base suivantes pour garantir la fluidité et l’efficacité du processus de publication :
- Les artefacts doivent être prêts à être téléchargés et testés, idéalement au même endroit.
- Il faut automatiser le plus grand nombre de contrôles et de tests possibles. Ils doivent se dérouler sans intervention humaine.
- Toutes les opérations complexes avec les builds doivent être aussi automatisées que possible.
- Tous les builds mis en production doivent être enregistrés et rester disponibles pendant un certain temps après leur publication. Cela vous sera utile si vous devez rechercher des erreurs dans la version de production, reproduire des bugs ou simplement faire un suivi de l’historique.
Les métriques de qualité sont inutiles si elles ne sont pas contrôlées automatiquement et n’ont d’impact sur aucun élément, car il n’y a aucun moyen de garantir qu’elles seront respectées.
Implémentez des pipelines, automatisez vos processus et utilisez l’analyse statique du code !
L’Équipe Qodana
Auteur de l’article original en anglais :
Subscribe to Qodana Blog updates
