Les fondamentaux du test logiciel
Pourquoi teste-t-on ? Qu'est-ce qu'un bug ? Quels sont les 7 principes du test et le processus fondamental ? Les bases solides sur lesquelles construire une démarche qualité. En 5 minutes, comprenez ce qu'est le test logiciel, les 7 principes ISTQB et les principaux niveaux de test.
01 — Définitions
Tester, c'est quoi ?
Test logiciel
Un ensemble d'activités visant à évaluer un produit ou un service et à déterminer s'il répond aux exigences spécifiées. Le test détecte des défauts, fournit des informations sur la qualité et réduit le risque de défaillance en production.
Objectifs du test
- Détecter des défauts avant la mise en production
- Gagner la confiance dans la qualité du logiciel
- Fournir des informations pour la prise de décision (go / no-go)
- Prévenir des défauts par des revues et une réflexion précoce
- Vérifier la conformité aux exigences réglementaires
Défaut, erreur et défaillance
Une erreur humaine produit un défaut (bug) dans le code. Si ce défaut est exécuté dans certaines conditions, il cause une défaillance observable. Tester vise à révéler les défauts avant qu'ils ne deviennent des défaillances.
Qualité et QA vs QC
La QAQuality Assurance désigne l'ensemble des activités qui garantissent que les processus sont adaptés pour produire un produit de qualité. Le QCQuality Control inclut les activités de test et de vérification du produit final. Le test est donc une composante du QC, lui-même au service de la QA.
02 — Les 7 principes
Les 7 principes du test (ISTQB)
Ces principes guident toute stratégie de test. Les comprendre, c'est éviter les pièges courants et justifier ses choix auprès des équipes et du management.
Le test révèle la présence de défauts
Tester prouve qu'un logiciel contient des bugs, jamais qu'il n'en contient pas. Un test sans défaut ne garantit pas la perfection.
Le test exhaustif est impossible
On ne peut pas tester toutes les combinaisons. Le test se concentre sur l'analyse des risques et les priorités métiers.
Tester tôt économise
Détecter un défaut tôt réduit le coût de sa correction. Les revues et tests dès la création de la spécification payent plus que les tests finaux.
Le regroupement des défauts
Un petit nombre de modules concentre la majorité des bugs (loi de Pareto). Concentrer les efforts sur ces zones est plus efficace.
Le paradoxe du pesticide
Répéter les mêmes tests finit par ne plus trouver de nouveaux défauts. Il faut régulièrement réviser et diversifier les cas de test.
Les tests dépendent du contexte
Un logiciel critique médical ne se teste pas comme une application interne. Les techniques, outils et rigueur s'adaptent au contexte.
L'absence d'erreur est une illusion
Des tests réussis ne prouvent pas l'absence de défauts, ils montrent seulement que, dans les conditions testées, aucun problème n'a été observé.
03 — Le processus
Le processus fondamental du test logiciel
Un processus structuré assure que le test est planifié, documenté et répétable. Chaque étape produit des livrables vérifiables.
Planification
Définir la portée, les ressources, le calendrier et les critères de sortie du test.
Analyse
Identifier les éléments à tester, les risques, les conditions de test et les données nécessaires.
Conception
Rédiger les cas de test, les procédures et les jeux de données. Préparer l'environnement.
Mise en œuvre
Exécuter les cas de test, consigner les résultats, signaler et analyser les anomalies.
Rapport & clôture
Évaluer les critères de sortie, rédiger le rapport de test et archiver les livrables.
04 — Niveaux & types
Niveaux et types de tests
Types de tests courants, puis les quatre niveaux qui structurent la pyramide des tests.
Fonctionnels
Vérifient ce que le système fait (boîte noire) : tests basés sur les exigences, les scénarios utilisateur, les parcours métier.
Non-fonctionnels
Vérifient comment le système se comporte : performance, sécurité, fiabilité...
Structurels
Vérifient la structure interne (boîte blanche) : couverture de code, branches, conditions, flux de contrôle.
Régression
Vérifient qu'une modification n'a pas introduit de nouveaux défauts dans des fonctionnalités précédemment validées.
Test unitaire
Vérifie une unité de code isolée (fonction, méthode). Rapide, répétable, souvent automatisé par les développeurs.
Test d'intégration
Vérifie les interactions entre composants ou systèmes. Détecte les problèmes d'interfaces et de flux de données.
Test système
Vérifie le système complet dans son environnement cible. Valide les exigences fonctionnelles et non-fonctionnelles.
Test d'acceptation
Valide que le système répond aux besoins métier. Réalisé par les utilisateurs ou le client (UATUser Acceptance Testing, alpha, bêta).
05 — Psychologie
L'aspect humain du test
Le testeur collabore avec le développeur. Son rôle est de fournir des informations objectives pour améliorer le produit.
Indépendance du test
Plus le testeur est indépendant de l'équipe de développement, plus il est susceptible de détecter des défauts avec un regard extérieur. Cependant, l'indépendance totale peut couper le testeur du contexte métier.
Communication constructive
Un rapport de bug bien rédigé décrit le problème factuellement. Le ton neutre et la façon de reproduire l'anomalie préservent la collaboration entre testeurs et développeurs.
Curiosité et scepticisme
Un bon testeur est curieux : il se demande "et si ?" à chaque étape. Il est "sceptique professionnel" : il le vérifie.
A retenir
En bref
- Le test aide à révéler des défauts, pas à prouver qu’un logiciel est parfait ;
- On ne peut pas tout tester ; il faut prioriser selon les risques ;
- Tester au plus tôt améliore la qualité et réduit les coûts ;
- Une bonne démarche de test combine méthode, types de tests adaptés et communication claire.
Pour aller plus loin