![](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2025\/09\/OtG44KqsW2bqQvcGbjAXFzjAwUX-H4LnhzqNKFp8Ey-KZQBughAsV8OeVQmqUOaVXa238O9AMbWk4zmn25XzGwca78GKRodkn5sJOc9Al1c_3qan7_CP1r7DHblnvptfZ4Eyfrwl.jpg\")
<\/p>\n\n\n\nAvoir des comp\u00e9tences en TestOps est aujourd’hui une n\u00e9cessit\u00e9 pour les ing\u00e9nieurs assurance qualit\u00e9, au m\u00eame titre que la capacit\u00e9 \u00e0 \u00e9crire des tests automatis\u00e9s. Cela est d\u00fb \u00e0 l’am\u00e9lioration continue de l’approche CI\/CD et au nombre croissant d’ing\u00e9nieurs assurance qualit\u00e9 qui travaillent avec des pipelines (s\u00e9quence des \u00e9tapes de CI\/CD) et impl\u00e9mentent leurs propres pipelines. Pourquoi le CI\/CD est-il aussi efficace pour le contr\u00f4le de la qualit\u00e9 ? C’est ce que nous allons voir dans cet article.<\/p>\n\n\n\n
<\/p>\n\n\n\n
Les tests automatis\u00e9s ne sont plus ex\u00e9cut\u00e9s localement depuis bien longtemps. De nos jours, l’ex\u00e9cution automatique des tests est l’une des principales fonctions des pipelines de CI\/CD.<\/p>\n\n\n\n
La configuration du pipeline peut \u00eatre assign\u00e9e au DevOps. Mais il serait dommage de se priver de la deuxi\u00e8me fonction du CI\/CD : le contr\u00f4le de la qualit\u00e9, ou plus pr\u00e9cis\u00e9ment, les \u00ab murs qualit\u00e9 \u00bb.<\/p>\n\n\n\n
Mais, que sont les murs qualit\u00e9 ? Imaginons que le code d’un produit constitue un ch\u00e2teau. Chaque jour, les d\u00e9veloppeurs \u00e9crivent du nouveau code, ce qui est susceptible de fragiliser les fondations du ch\u00e2teau, voire de les d\u00e9t\u00e9riorer. L’objectif d’un ing\u00e9nieur assurance qualit\u00e9 est de tester chaque fonctionnalit\u00e9 et de r\u00e9duire la probabilit\u00e9 que des bugs se retrouvent dans le code du produit. Le manque d’automatisation du processus d’assurance qualit\u00e9 peut faire passer des nuits blanches aux ing\u00e9nieurs car il n’y a personne pour surveiller les diff\u00e9rents indicateurs, surtout \u00e0 des moments critiques comme le vendredi soir, lorsque tout le monde a envie de quitter le travail au plus vite. Une mauvaise fusion \u00e0 ce moment-l\u00e0 peut engendrer beaucoup de probl\u00e8mes par la suite.<\/p>\n\n\n\n
Ce probl\u00e8me peut \u00eatre r\u00e9solu par la cr\u00e9ation de contr\u00f4les de la qualit\u00e9 pour les indicateurs importants.<\/em><\/p>\n\n\n\n Chaque contr\u00f4le porte sur une m\u00e9trique diff\u00e9rente. Si le code ne passe pas un contr\u00f4le, le mur emp\u00eache la fonctionnalit\u00e9 d’entrer. Une fonctionnalit\u00e9 est int\u00e9gr\u00e9e au produit seulement si elle passe tous les contr\u00f4les et si les bugs potentiels ont \u00e9t\u00e9 \u00e9vit\u00e9s.<\/p>\n\n\n\n Il faut \u00e9laborer une liste de v\u00e9rifications pour s’assurer que le processus soit aussi automatis\u00e9 que possible. Elle peut \u00eatre organis\u00e9e de fa\u00e7on \u00e0 ce que les v\u00e9rifications cruciales aient lieu en premier. Une fonctionnalit\u00e9 doit passer toutes les v\u00e9rifications pour arriver au terme du pipeline avec succ\u00e8s. Les v\u00e9rifications initiales permettent de s’assurer que l’application est capable de fonctionner : build, v\u00e9rification du style de code et analyse statique. <\/p>\n\n\n\n S’agissant du \u00ab build \u00bb : si la phase de construction de l’application ne se passe pas bien, la fonctionnalit\u00e9 ne progresse pas. Il est important d’int\u00e9grer une v\u00e9rification du style du code dans votre pipeline de CI\/CD pour vous assurer que le code r\u00e9ponde bien aux standards de votre entreprise : cela vous \u00e9vitera de perdre du temps sur ce type de bugs lors des r\u00e9visions de code.<\/p>\n\n\n\n L’analyse statique est un outil extr\u00eamement important pour \u00e9valuer la qualit\u00e9 du code. Elle permet de mettre en \u00e9vidence un grand nombre d’erreurs critiques pouvant provoquer des bugs.<\/p>\n\n\n\n Continuons avec les v\u00e9rifications de la deuxi\u00e8me \u00e9tape : les tests unitaires avec analyse de la couverture et contr\u00f4le de la qualit\u00e9 de la couverture, les tests d’int\u00e9gration et les tests syst\u00e8mes. Nous examinons ensuite les rapports d\u00e9taill\u00e9s des r\u00e9sultats pour nous assurer que rien n’a \u00e9t\u00e9 oubli\u00e9. \u00c0 ce stade, on peut aussi effectuer une s\u00e9rie de tests non fonctionnels pour v\u00e9rifier les performances, la facilit\u00e9 d’utilisation et la s\u00e9curit\u00e9, ainsi que des tests de capture d’\u00e9cran. <\/p>\n\n\n\n Lors du d\u00e9veloppement d’un pipeline, nous devons pr\u00eater attention \u00e0 deux exigences contradictoires : <\/p>\n\n\n\n <\/p>\n\n\n\n Mise en \u00e9vidence du style de code<\/strong><\/p>\n\n\n\n Un style de code est un ensemble de r\u00e8gles qui doivent \u00eatre suivies dans chaque ligne de code d’un projet, qui vont des r\u00e8gles d’alignement \u00e0 des r\u00e8gles comme \u00ab ne jamais utiliser de variables globales \u00bb. Les grandes entreprises ont g\u00e9n\u00e9ralement leurs propres guides de style qui peuvent servir d’exemples. Par exemple, Airbnb dispose d’un guide de style JavaScript<\/a> et Google a \u00e9galement plusieurs guides<\/a>. Vous pouvez m\u00eame \u00e9crire votre propre guide.<\/p>\n\n\n\n Le choix des outils pour les v\u00e9rifications de code d\u00e9pend du langage. Vous pouvez trouver un outil adapt\u00e9 sur GitHub<\/a> ou d\u00e9couvrir les outils utilis\u00e9s par d’autres \u00e9quipes. Les linters utilisent un ensemble de r\u00e8gles et mettent en \u00e9vidence le code qui ne les respecte pas. Quelques exemples : ktlint<\/a> pour Kotlin, checkstyle<\/a> pour Java et eslint<\/a> pour JavaScript.<\/p>\n\n\n\n Analyse de code statique<\/strong><\/p>\n\n\n\n L’analyse du code statique est une m\u00e9thode de d\u00e9bogage qui consiste \u00e0 examiner le code source sans ex\u00e9cuter le programme. Il existe de nombreux analyseurs de code statique diff\u00e9rents sur le march\u00e9. Nous allons examiner plus en d\u00e9tail la plateforme que nous sommes en train de d\u00e9velopper nous-m\u00eame : Qodana<\/a>. Le principal avantage de cet analyseur de code est qu’il inclut un certain nombre d’inspections disponibles dans les environnements de d\u00e9veloppement JetBrains lorsque nous \u00e9crivons du code.<\/p>\n\n\n\n Beaucoup d’entre vous utilisent probablement une approche dans laquelle l’IDE vous aide \u00e0 \u00e9crire le code et vous signale les bugs tels que l’utilisation sous-optimale du code, les exceptions NullPointerExceptions, les doublons, etc.<\/p>\n\n\n\n Mais malheureusement, on ne peut jamais garantir que tous les probl\u00e8mes critiques identifi\u00e9s par l’IDE aient \u00e9t\u00e9 corrig\u00e9s avant le commit. L’int\u00e9gration de Qodana dans votre pipeline de CI\/CD<\/strong> vous assure que tous les probl\u00e8mes soient bien trait\u00e9s. Si l’ensemble des probl\u00e8mes ne peuvent \u00eatre r\u00e9solus en une seule fois, vous pouvez s\u00e9lectionner les plus importants, les ajouter \u00e0 la base de r\u00e9f\u00e9rence et r\u00e9duire progressivement la dette technique. Vous \u00e9vitez ainsi de ralentir le processus de d\u00e9veloppement tout en gardant les probl\u00e8mes identifi\u00e9s sous contr\u00f4le.<\/p>\n\n\n\n Couverture de tests<\/strong><\/p>\n\n\n\n La couverture du code est une m\u00e9trique qui vous aide \u00e0 comprendre dans quelle mesure votre code a \u00e9t\u00e9 couvert par vos tests (g\u00e9n\u00e9ralement des tests unitaires). En plus d’ex\u00e9cuter automatiquement les tests et d’assurer que certaines exigences de qualit\u00e9 du code soient respect\u00e9es, le CI\/CD permet aux testeurs d’organiser le processus de publication.<\/p>\n\n\n\n Ce processus peut \u00eatre complexe et d\u00e9pendre d’un grand nombre d’actions manuelles diff\u00e9rentes. Il s’agit souvent d’un processus enti\u00e8rement manuel : l’artefact est cr\u00e9\u00e9 par un d\u00e9veloppeur, puis transmis aux testeurs pour v\u00e9rification, et enfin \u00e0 la personne charg\u00e9e de le d\u00e9ployer. Une fois encore, il existe de nombreux goulots d’\u00e9tranglement potentiels. Par exemple, il est possible que l’une de ces personnes tombe malade ou parte en vacances. <\/p>\n\n\n\n Les crit\u00e8res d’efficacit\u00e9 du processus de publication diff\u00e8rent en fonction des \u00e9quipes, mais il comprend g\u00e9n\u00e9ralement les \u00e9tapes suivantes : <\/p>\n\n\n\n Tout syst\u00e8me de CI\/CD vous permet de configurer ce type de processus. Le processus doit \u00eatre pratique pour tous les membres l’\u00e9quipe, y compris pour les personnes qui sont charg\u00e9es des tests.<\/p>\n\n\n\n Compte tenu des diff\u00e9rents facteurs d\u00e9crits ci-dessus, il nous semble important de respecter les r\u00e8gles de base suivantes pour garantir la fluidit\u00e9 et l’efficacit\u00e9 du processus de publication :<\/em><\/p>\n\n\n\n Les m\u00e9triques de qualit\u00e9 sont inutiles si elles ne sont pas contr\u00f4l\u00e9es automatiquement et n’ont d’impact sur aucun \u00e9l\u00e9ment, car il n’y a aucun moyen de garantir qu’elles seront respect\u00e9es. <\/p>\n\n\n\n Impl\u00e9mentez des pipelines, automatisez vos processus et utilisez l’analyse statique du code !<\/p>\n\n\n\n L’\u00c9quipe Qodana<\/em><\/p>\n\n\n\n Auteur de l’article original en anglais<\/em> :<\/p>\n\n\n ![](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2025\/09\/xvVYg4Iv5QvdnY9m0t1jFHbQQBCCuqkcgHjkogmQihNIy9Bmf5xnk1cDKjJGJke0FpMJcVoyzSjkQyJh2giCPo9GErs68FgXWU2186k16L-xxou5LGhFm4H0mN4QNhqKe_x7KB2D.jpg\")
<\/p>\n\n\n\nQuels contr\u00f4les de la qualit\u00e9 peuvent \u00eatre inclus dans le CI\/CD ?<\/h3>\n\n\n\n
![](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2025\/09\/JOj7Yn_ie9RqZWOePgNEhL6Vb-24W6J92TcRTOV4WfTJ_uop5FtG8SHS2zHQ75ZZjy6D1eljT1YpXklbUVIKKL83vVW6MaQOaZyNcGJtXRqZAKX8eXUWvFoMDY3fPLJK8fsXzOh0.jpg\")
<\/p>\n\n\n\n\n
Exemples d’outils \u00e0 int\u00e9grer dans vos contr\u00f4les de la qualit\u00e9<\/h3>\n\n\n\n
Vous vous demandez peut-\u00eatre ce que le style a \u00e0 voir avec les testeurs. Eh bien beaucoup en fait ! Une v\u00e9rification du style pr\u00e9sente plusieurs avantages pour les experts de l’assurance qualit\u00e9, mais aussi pour le reste de l’\u00e9quipe :<\/p>\n\n\n\n\n
![](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2025\/09\/l2spCDgt3blzH9VthoB_x9Ggu2LPZeoFb1xXu2qCWtxiJmRyvFlz3kroFxXMt56ZG5xxavyJHvqbrsStGSiuNyN32d-28i2heLtb8sXVYMHcFwBVXHxBXtIlsQ68EgrQyJIQEO-nXXz_Es4_yQQ.png\")
<\/p>\n\n\n\n
Ici, vous devez d\u00e9finir le pourcentage de couverture minimum qui doit \u00eatre pris en charge. Le code ne peut \u00eatre mis en production que lorsqu’il a \u00e9t\u00e9 suffisamment couvert par les tests. Le pourcentage minimum est \u00e9tabli de mani\u00e8re empirique, mais il faut garder \u00e0 l’esprit que m\u00eame avec une couverture de 100 %, tous les bugs ne peuvent pas \u00eatre \u00e9vit\u00e9s. Selon cet article<\/a> d’Atlassian, une couverture de 80 % constitue un bon objectif \u00e0 viser.
Il existe diff\u00e9rents analyseurs de couverture pour diff\u00e9rents langages, tels que Jacoco<\/a> pour Java, Istanbul<\/a> pour JavaScript ou Coverage.py<\/a> pour Python. Vous pouvez int\u00e9grer tous ces analyseurs dans votre pipeline de CI\/CD et suivre facilement les m\u00e9triques.<\/p>\n\n\n\nFa\u00e7onnage du processus de publication<\/h2>\n\n\n\n
\n
\n
\n \n \n \n ![\"\"](\"https:\/\/secure.gravatar.com\/avatar\/?s=200&r=g\")