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.

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…

Livre