Qui dit DevOps, dit tests… fonctionnels !

15/05/2024 | Développement, Paroles d’experts

Temps de lecture  5 minutes

Parlons de l’importance des tests fonctionnels dans l’approche DevOps. Première question que vous devez vous poser : pourquoi une consultante IA et DevOps nous parle de tests fonctionnels ?

Tout simplement, car je développe principalement du back qui ne se compile pas en quelques secondes, j’ai du temps d’attente, je peux donc être multi-tâche dans un projet. Ensuite, je ne veux pas que le travail de mon équipe soit totalement gâché par un simple oubli ou pire un petit bug d’affichage passé à la trappe du testeur humain au niveau de l’interface utilisateur, que ce soit un problème de comptabilité, d’interprétation ou autre. Dernier point, si vous souhaitez des tests « sincères et fiables », le testeur doit être un autre humain que celui qui a développé.

Par Ludivine Crepin, doctoresse en intelligence artificielle et auteur aux Editions ENI

DevOps… ce n’est pas simplement amener la paix dans la guerre entre les devs et les ops ? Oui, entre autres. Nous pouvons aussi voir la philosophie Devops comme revenir au but premier de l’ordinateur : toute tâche répétitive, rébarbative ou non, qui peut être automatisée doit l’être !

C’est sur ce principe que repose les CI/CD de DevOps.
Côté Ops, je peux automatiser les tests de production et le déploiement (et donc limiter mes heures d’astreinte 😉 ).
Côté devs, je peux automatiser les tests du code et la mise en production (et donc garantir aux ops que le code fonctionne correctement).

La trinité des tests

Lorsque nous parlons de tests aux devs, les premiers, et généralement les seuls, qui viennent à l’esprit des devs sont les tests unitaires garantissant le traitement en back des données. Vu que les traitements de données sont assurés, certains pensent que l’application est forcément fiable. Grosse erreur ! Comme Mike Cohn le décrit dans sa pyramide, les tests unitaires ne sont que les tests vitaux pour les devs.

pyramide de cohn

Une fois les tests unitaires développés, il nous faut passer aux tests d’intégration, i.e. vérifier les accès aux bases de données et applications externes. Et, afin que l’application sont entièrement fiable, il nous développer les ultimes tests fonctionnels qui garantissent le comportement du front, i.e. de l’interface utilisateur.

Nous rechignons tous à développer ces tests car leur mise ne place peut s’avérer chronophage et coûteuse en termes de ressources humaines alors qu’une application ne peut pas être mise en production automatiquement sans.

L’effet de bord que cela entraîne est une mauvaise satisfaction des clients : ils trouvent en général l’application utile mais les problèmes de l’interface graphique les rebutent. Ils vont donc délaisser notre application… Tout un travail technique pour rien au final…

Nous n’avons aujourd’hui aucune excuse technique pour ne pas exécuter les tests fonctionnels de nos projets. Il existe une multitude de frameworks comme Cypress, Playwright, testRigueur, subject7 Katalon, Selenium ou encore Watir, propriétaire ou non, qui permettent de tester tout type d’interface utilisateur.

De plus, avec des outils comme Selenium, nos tests fonctionnels peuvent être totalement indépendants de notre projet en termes de technologies et surtout facilement automatisables 😉

Attention cependant à ne pas tout mélanger quand on teste notre application.

J’ai déjà vu des équipes qui testaient en même temps, lors de la même exécution, les tests unitaires, d’intégration et fonctionnels. Pour vulgariser, on peut dire que les tests fonctionnels permettaient de tester les tests unitaires et d’intégration. Résultat, plus de deux jours de tests pour toute modification du code, même minime… Comment dégouter les devs des tests…

Non, chaque type de test doit avoir sa propre exécution et les tests ne doivent pas empiéter sur les autres. Nous commençons par lancer les tests unitaires, puis d’intégration et finalement les fonctionnels en mockant simplement les données et là nous passons de plusieurs jours à simplement quelques heures…

Diplômée d’un doctorat en intelligence artificielle pour le traitement d’images médicales, Daphné Wallach exerce depuis plus de 10 ans dans ce domaine. Elle est ingénieure en recherche et développement dans la start-up Intradys, qui développe des outils d’intelligence artificielle pour la neuroradiologie interventionnelle. Elle met également son expertise au bénéfice de formations sur l’intelligence artificielle et sur le traitement d’images, qu’elle dispense à l’université de Rennes et en entreprise. 

Ludivine Crépin

Freelance AI Dev & DevOps / Autrice Editions ENI et formatrice ENI Service

Pour aller plus loin

Scratch et Raspberry Pi Projets maker pour s'initier à l'électronique et à la robotique

Livre

Algorithmique
Techniques fondamentales de programmation
Flutter Développez vos applications mobiles multiplateformes avec Dart

Livre

Selenium
Maîtrisez vos tests fonctionnels avec Python
Flutter Développez vos applications mobiles multiplateformes avec Dart

Livre

DevSecOps
Développez et administrez vos services en toute sécurité
Flutter Développez vos applications mobiles multiplateformes avec Dart

Livre

Azure DevOps
Optimisez la gestion de vos projets informatiques

POUR LES ENTREPRISES

Découvrez nos solutions de formation pour vos équipes et apprenants :

Réfléchir en amont
elearning

En e-learning avec
notre offre pour les professionnels

formateur

Avec un formateur, en présentiel ou à distance

Restez connecté !

Suivez-nous
LinkedIn
Youtube
X
Facebook
Instagram
Contactez-nous
E-mail

Inscrivez-vous à notre newsletter

Je suis intéressé(e) par :

En vous inscrivant, vous acceptez la politique de protection des données du groupe Eni. Vous aurez la possibilité de vous désabonner à tout moment.