« Tester, c’est douter ! » est une maxime que bon nombre de développeurs connaissent et utilisent avec humour. C’est souvent LA réponse quand on ne sait pas trop comment avouer qu’on « n’a pas véritablement établi de politique de tests”, que « les tests unitaires prenaient trop de temps et ralentissaient les développements”, qu’on « les a mis en commentaire car l’application ne compilait plus” ou encore “on en fait pas, notre équipe n’est pas dimensionnée pour”. (Toutes ces réponses, ont été entendues chez des clients). Alors pourquoi tester ? Comment tester ? C’est ce que nous allons voir dans cet article. 

Pourquoi tester ? 

Tester les logiciels est indispensable pour de nombreuses raisons : 

1.Assurance de la qualité : 

Les tests permettent de vérifier que le logiciel répond aux spécifications et aux attentes des utilisateurs. Ils garantissent que le produit final est de haute qualité, sans défauts critiques, et répond aux besoins fonctionnels. 

2.Détection précoce des bugs : 

Identifier les défauts dès les premières étapes du développement permet de les corriger avant qu’ils ne deviennent coûteux ou difficiles à résoudre. Les tests réduisent le risque de défaillances majeures lors de la mise en production. 

3.Réduction des coûts : 

Corriger un bug à un stade avancé du développement ou, pire encore, en production, peut être extrêmement coûteux. En testant de manière proactive, on réduit les coûts associés à la maintenance et au support post-livraison. 

4.Sécurité : 

Les tests, en particulier les tests de sécurité, aident à identifier les vulnérabilités qui pourraient être exploitées par des attaquants. Cela est essentiel pour protéger les données des utilisateurs et l’intégrité du système. 

5.Conformité réglementaire : 

Dans certains secteurs, les tests sont requis pour se conformer à des normes et réglementations spécifiques, garantissant que le logiciel respecte les exigences légales. 

Dans quel cas tester ? 

De manière générale, tester devrait être inclus dans la démarche de développement. On parle depuis plus d’une dizaine d’années maintenant de démarche TDD (Test Driven Development), une approche où l’écriture du test en amont permet le développement de fonctionnalités. Cette démarche suppose une certaine organisation qui va avec et qui a fait ses preuves. Mais sans aller jusqu’à mettre en place une démarche TDD, mettre en place des tests reste, LA bonne pratique à adopter pour assurer une plus grande longévité à une application.

Le seul cas pour lequel on pourrait éventuellement se poser la question d’investir sur les tests, c’est dans une phase de POC (Proof Of Concept) si le développement est jetable et/ou sera refait proprement après validation du POC. Mais attention, on parle uniquement de POC jetable, car de nombreux POC se transforment en applications, sans tests, avec souvent un destin incertain.

Dans tous les autres cas -> On teste !

Les différents types de tests 

Il existe une grande variété de tests logiciels, chacun ayant un objectif spécifique. On les classes souvent en deux grandes familles :

• Tests fonctionnels dont l’objectif est de tester les aspects fonctionnels d’une application. Vérifier le fonctionnement des différentes fonctionnalités et s’assurer que tout fonctionne comme prévu. Ces tests peuvent à la fois être exécutés manuellement, par des équipes qui exécutent des scénarii fonctionnels ou à l’aide d’outils d’automatisation. 

• Tests non fonctionnels dont l’objectif est de vérifier les aspects non fonctionnels d’une application logicielle, tels que sa performance, sa convivialité, sa fiabilité, sa sécurité… 

Tests fonctionnels :  

1.Tests unitaires : 

• But : Vérifier individuellement les plus petites unités du code, telles que les fonctions ou les méthodes. 

• Quand : Pendant la phase de développement, souvent automatisés. 

• Avantage : Permet de détecter rapidement des erreurs à un niveau très granulaire. 

C’est un test qui est mis en place par l’équipe de développement au sein de l’application et qui permet de couvrir, via un maillage très fin, les différentes fonctions de l’application constituant une fonctionnalité applicative. Plus le maillage sera fin et la couverture de test, bonne, plus précis et rapide sera l’identification et la correction d’une anomalie en cas de régression. 

Les tests unitaires sont la pierre angulaire d’une démarche de tests. C’est sur ces tests que repose une grande partie de la prévention des anomalies à venir. Si vous devez investir que sur un seul type de test dans un premier temps, c’est sur celui-là qu’il faut axer l’effort dès le démarrage du projet, car les reprendre après est plus lourd et coûteux. 

2.Tests d’intégration : 

• But : S’assurer que les différents modules ou services fonctionnent bien ensemble. 

• Quand : Après les tests unitaires, une fois que les différents composants du système sont intégrés. 

• Avantage : Permet de détecter des problèmes liés à l’interaction entre différents modules. 

Une fois que vous avez intégré les modules, il est essentiel de vérifier qu’ils fonctionnent correctement en tant que modules combinés. En effet, l’intégration de plusieurs modules peut créer des bogues. Ainsi, tester chaque module intégré d’une application pour vérifier sa fonctionnalité combinée s’appelle le test d’intégration. 

Les tests d’intégration vérifient les modules qui sont généralement des applications ou des modules de code sur un réseau donné. Il est principalement utilisé pour les systèmes distribués et les applications client ou serveur. Ils nécessitent moins de tests que les tests unitaires et peuvent adopter différentes approches, telles que l’approche descendante, l’approche sandwich et l’approche ascendante. 

3. Tests d’interface ou test d’API : 

• But : Vérifier la communication entre deux systèmes logiciels distants. 

• Quand : Après les tests d’intégration, avant la mise en production. 

• Avantage : Permet de détecter des anomalies de communication entre deux systèmes distincts. 

Dans une approche de développement micro-services, ce type de test prend tout son sens pour vérifier le fonctionnement des différents services exposés et du contrat d’interface.

4.Tests de non-régression : 

• But : Vérifier que les nouvelles modifications n’ont pas introduit de nouveaux bugs dans des fonctionnalités précédemment testées. 

• Quand : Après chaque changement majeur ou mise à jour du logiciel. 

• Avantage : Garantit la stabilité du produit au fur et à mesure de son évolution. 

Le test de non-régression permet de vérifier que les développements ajoutés sur une nouvelle version ne causent pas de régression(s) fonctionnelle(s) sur le fonctionnement de l’application dans sa version précédente. Ce type de test, qui doit être exécuté avant chaque nouvelle mise en production, peut rapidement devenir chronophage et accaparant lorsqu’une application se développe et s’enrichit fonctionnellement. Heureusement, des moyens d’automatisation existent et c’est souvent une très bonne pratique  sur le long terme.

5.Tests d’acceptance ou UAT : 

• But : Valider que le logiciel répond aux besoins et aux attentes des utilisateurs finaux. 

• Quand : À la fin du cycle de développement, avant la mise en production. 

• Avantage : Garantit que le produit est prêt à être livré et accepté par le client ou les utilisateurs. 

On parle de test d’acceptance ou UAT (pour User Acceptante Test) pour qualifier les tests des nouvelles fonctionnalités que l’on fait après leur développement pour valider que celui-ci est conforme à l’attendu. Et pour qualifier et détailler cet attendu, les « critères d’acceptance » (ou Acceptante Criterias) décrivent, à travers différents scénarios le fonctionnement avec précision.

7.Tests exploratoires : 

• But : Permettre aux testeurs de découvrir de manière proactive des bugs en explorant le logiciel sans script prédéfini. 

• Quand : À tout moment, généralement après les tests formels. 

• Avantage : Complète les tests automatisés en identifiant des problèmes inattendus. 

Tests non fonctionnels :  

1.Tests de performance : 

• But : Évaluer la réactivité, la stabilité, et la scalabilité du système sous différentes charges. 

• Quand : Avant la mise en production, et lors de montées en charge significatives. 

• Avantage : Identifie les goulots d’étranglement et assure que le système peut gérer les pics de trafic. 

2.Tests de sécurité : 

• But : Identifier les vulnérabilités et failles de sécurité potentielles dans le logiciel. 

• Quand : En continu, tout au long du cycle de développement, et avant la mise en production. 

• Avantage : Protège les données des utilisateurs et renforce la sécurité globale du produit. 

Mise en place de tests logiciel 

La mise en place des tests logiciels nécessite une planification soignée et une approche systématique : 

1.Définir une stratégie de tests : 

Commencez par établir une stratégie de tests claire qui définit les types de tests à réaliser, les outils à utiliser, et les critères de réussite. Cette stratégie doit aligner les objectifs de test avec les exigences du projet. 

2.Choisir les outils de test : 

Sélectionnez des outils adaptés aux différents types de tests que vous prévoyez de réaliser. Par exemple, des Framework comme JUnit ou TestNG pour les tests unitaires, Selenium pour les tests d’interface utilisateur, ou JMeter pour les tests de performance. 

3.Automatiser les tests : 

L’automatisation est essentielle pour les tests unitaires, d’intégration, et de régression. Elle permet de gagner du temps, de réduire les erreurs humaines, et de réaliser des tests répétitifs de manière plus efficace. 

4.Établir un environnement de test : 

Créez des environnements de test qui reproduisent fidèlement les conditions de production. Cela inclut les configurations matérielles, logicielles, et réseau, ainsi que les bases de données. 

5.Rédiger des cas de test : 

Rédigez des cas de test détaillés qui couvrent tous les scénarios d’utilisation possibles, y compris les cas positifs et négatifs. Chaque cas de test doit avoir des critères d’acceptation clairs. 

6.Exécuter les Tests : 

Exécutez les tests conformément au plan de test et enregistrez les résultats. Assurez-vous de bien documenter les bugs détectés, leur priorité, et leur état de résolution. 

7.Analyser les Résultats : 

Après chaque cycle de tests, analysez les résultats pour identifier les tendances et les zones à risque. Utilisez ces informations pour améliorer le processus de développement et la stratégie de tests. 

8.Rétrospective et amélioration continue : 

Organisez des rétrospectives régulières pour discuter des leçons apprises et identifier les améliorations possibles. Le processus de test doit évoluer en permanence pour s’adapter aux besoins du projet. 

Bonnes pratiques en matière de tests logiciels 

Voici quelques bonnes pratiques à suivre pour garantir l’efficacité des tests logiciels : 

1.Impliquer les testeurs tôt : 

Faites participer les testeurs dès le début du projet, idéalement lors de la phase de planification. Cela permet de s’assurer que les tests sont bien alignés avec les exigences du projet. 

2.Prioriser les tests :

Toutes les fonctionnalités ne sont pas égales en termes de criticité. Priorisez les tests en fonction des fonctionnalités les plus critiques pour l’utilisateur et des risques les plus élevés. 

3.Maintenir la documentation à jour :

Assurez-vous que la documentation des tests est toujours à jour et reflète fidèlement l’état actuel du logiciel. Cela inclut les cas de test, les scripts automatisés, et les rapports de bugs. 

4.Combiner tests manuels et automatisés :

Les tests automatisés sont efficaces pour les tâches répétitives, mais les tests manuels restent essentiels pour les scénarios complexes ou les tests exploratoires. Une combinaison des deux offre la meilleure couverture possible. 

5.Effectuer des revues de code :

Intégrez des revues de code dans le processus de développement. Cela permet de détecter des erreurs potentielles avant même que le code n’entre en phase de test formel. 

6.Tester dans des conditions réelles :

Lorsque cela est possible, effectuez des tests en conditions réelles pour simuler l’expérience utilisateur. Cela inclut les tests sur différents appareils, navigateurs, et configurations réseau. 

7.Adopter une culture de la qualité : 

Promouvez une culture où la qualité est l’affaire de tous, pas seulement des testeurs. Chaque membre de l’équipe doit être engagé à livrer un produit de haute qualité. 

Coût et impact sur la productivité ?

Le coût de mise en place des tests peut varier en fonction de plusieurs facteurs :

1.Type de Tests : Les tests unitaires sont généralement peu coûteux à réaliser, alors que les tests de performance et de sécurité peuvent nécessiter des outils coûteux.

2.Automatisation vs. Tests Manuels : L’automatisation permet d’exécuter les tests rapidement et de manière répétée, mais les outils et la configuration de scripts de tests automatisés peuvent avoir un coût initial important.

3.Complexité du Logiciel : Plus le logiciel est complexe, plus il est coûteux de le tester en profondeur.

4.Fréquence des Tests : Plus le logiciel est testé régulièrement, plus les coûts de maintenance peuvent augmenter.

5.Formation et Ressources Humaines : Les tests nécessitent des testeurs qualifiés, et la formation peut être un coût supplémentaire.

Estimation du Coût Total : En moyenne, les tests peuvent représenter entre 20 % et 40 % du budget total de développement d’un logiciel, mais cela peut varier en fonction de la complexité et des exigences spécifiques.

Le coût qu’il est moins évident d’estimer, c’est le coût à ne pas tester (Voir notre article sur l’importance du COI pour plus de détail) ! Et c’est pourtant celui-là qui devrait l’emporter sur la mise en place d’une démarche de test logiciel. 

Conclusion 

La démarche de tests logiciels est un élément fondamental pour assurer la qualité, la sécurité et la fiabilité des produits numériques. En comprenant les différents types de tests, en les intégrant efficacement dans le cycle de développement, et en suivant les bonnes pratiques, les équipes peuvent réduire les risques, améliorer la satisfaction des utilisateurs et garantir le succès de leurs projets logiciels. Les tests logiciels ne sont pas une simple formalité, mais une composante essentielle de la création de produits robustes et durables. 

Alors tester c’est effectivement douter, mais peut-être douter d’un potentiel futur pour votre application si elle n’est pas couverte par des tests. Sur chaque projet sur lequel je suis intervenu, j’ai toujours regardé de près les tests. Une application non couverte par un minimum de tests n’a, pour moi, aucune valeur. C’est une application qu’on ne contrôle pas dans le temps, qu’on ne peut pas protéger contre la régression et qui va demander, avec les versions, énormément d’investissement humain qui vont s’avérer plus coûteux que le coût initial de leur mise en place.  

Au début, on fait le choix de l’économie, d’aller vite, de faire confiance aux développeurs… et les versions s’enchaînent, le turn-over se met en place… et se produit la première régression, puis deux, trois… le support s’enflamme, les utilisateurs perdent patience et confiance en l’application et la communication négative autour de l’outil peine à le faire reprendre. 

Des scénarios comme celui-ci j’en ai connu beaucoup (trop ?) ! Dans une grosse structure, on se sortira de ce mauvais pas en remplaçant l’outil par un autre, mais dans une petite entreprise c’est un coup dur, une perte importante qui parfois signe sa fin de l’aventure.