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, défaillance et cause racine
Une erreurAction humaine qui produit un résultat incorrect (par exemple un défaut dans le code ou dans un document d'exigences). humaine produit un défautImperfection ou défaut dans un élément de travail (comme du code ou des exigences) qui peut conduire à une défaillance lors de son exécution. (bug) dans le code. Si ce défaut est exécuté dans certaines conditions, il cause une défaillanceÉvénement physique ou comportement constaté où le système ne réalise pas sa fonction requise dans les limites spécifiées (écart constaté par rapport aux attentes). observable. Tester vise à révéler les défauts avant qu'ils ne deviennent des défaillances.
La cause racine est l'origine du défaut introduit, à ne pas confondre avec le défaut lui-même : par exemple, une mauvaise connaissance du domaine métier a introduit une règle de gestion ambiguë, qui a été développée telle quelle et ne correspond pas à ce qu'attendait la personne utilisatrice. Ici, la cause racine est le manque de connaissance de la personne qui a rédigé la règle de gestion.
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.
Vérification vs Validation
La vérification s'assure que le produit est construit correctement, conformément aux spécifications (« Sommes-nous en train de construire le produit correctement ? »). La validation s'assure que le bon produit a été construit, celui qui répond au besoin réel des personnes utilisatrices (« Sommes-nous en train de construire le bon produit ? »). Le test contribue aux deux : il vérifie la conformité aux exigences et valide l'usage réel.
Test vs débogage
Le test révèle les défauts et fournit des informations sur la qualité. Le débogage consiste à localiser la cause d'un défaut, le corriger et vérifier que la correction fonctionne. Il est nécessaire ensuite de vérifier la correction, en rejouant le test qui avait échoué, pour s'assurer que le défaut ne se présente plus. Ce sont deux activités distinctes.
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étier.
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.
L'usure des tests
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 de défauts est une illusion
Un logiciel sans défaut détecté n'est pas forcément un bon logiciel : s'il ne répond pas aux besoins et attentes des personnes utilisatrices, il reste inutilisable ou inadapté, même sans aucun bug trouvé.
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 d'entrée et de sortie du test.
Pilotage & contrôle
Suivre l'avancement en continu, comparer aux objectifs et ajuster le plan tout au long des autres activités.
Analyse
Identifier les éléments à tester, les risques et les conditions de test à partir des exigences.
Conception
Concevoir les cas de test, les procédures de test et identifier les données nécessaires.
Implémentation
Rédiger les cas de test, préparer les jeux de données et l'environnement de test.
Exécution
Exécuter les cas de test, comparer résultats attendus et obtenus, consigner et signaler les anomalies.
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 cinq niveaux qui structurent la pyramide des tests.
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.
Tests non fonctionnels
Vérifient comment le système se comporte : performance, sécurité, fiabilité...
Tests structurels
Vérifient la structure interne (boîte blanche) : couverture de code, branches, conditions, flux de contrôle.
Tests de non-régression
Vérifient qu'une modification n'a pas introduit de nouveaux défauts dans des fonctionnalités précédemment validées.
Tests de composants (tests unitaires)
Vérifient une unité de code isolée (fonction, méthode). Rapide, répétable, souvent automatisé par l'équipe de développement.
Tests d'intégration de composants
Vérifie les interactions entre modules au sein d'une même application. Détecte les problèmes d'interfaces internes.
Tests d'intégration système
Vérifie les interactions entre applications ou systèmes distincts, notamment des systèmes externes : API, bases de données, services tiers.
Tests système
Vérifient le système complet dans son environnement cible. Valident les exigences fonctionnelles et non fonctionnelles.
Tests d'acceptation
Valident que le système répond aux besoins métier. Réalisé par les personnes utilisatrices ou la clientèle (UATUser Acceptance Testing, alphaTest réalisé en interne, chez l\'éditeur, avant toute diffusion externe, bêtaTest réalisé par de véritables personnes utilisatrices externes, avant la sortie officielle).
05 — Psychologie
L'aspect humain du test
L'équipe de test collabore avec l'équipe de développement. Son rôle est de fournir des informations objectives pour améliorer le produit.
Indépendance du test
Plus la personne en charge du test est indépendante de l'équipe de développement, plus elle est susceptible de détecter des défauts avec un regard extérieur. Cependant, l'indépendance totale peut couper le rôle QA 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 équipes de test et de développement.
Curiosité et scepticisme
Une bonne démarche de test demande de la curiosité : se demander « et si ? » à chaque étape. Garder un scepticisme professionnel : ne rien supposer et tout vérifier.
À retenir
Ce qu'il faut retenir
Quatre idées clés qui résument tout ce qu'on vient de voir sur le test logiciel.
Le test révèle des défauts
Le test aide à révéler des défauts, pas à prouver qu'un logiciel est parfait. Un test sans défaut ne garantit jamais son absence totale.
Prioriser selon les risques
On ne peut pas tout tester. Il faut prioriser selon les risques, en concentrant l'effort là où une défaillance coûterait le plus cher.
Test tôt = moindre coût
Tester au plus tôt améliore la qualité et réduit les coûts. Plus un défaut est détecté tard, plus sa correction coûte cher.
Méthode, types, communication
Une bonne démarche de test combine méthode, types de tests adaptés et communication claire entre équipes de test et de développement.
Mise en pratique
Testez votre compréhension
Une sélection de questions basées sur ce que vous venez de lire.
Qu'est-ce que le test logiciel permet de prouver ?
Un module de code concentre à lui seul la majorité des bugs remontés. Quel principe illustre cette situation ?
Une équipe rejoue depuis 2 ans exactement les mêmes cas de test, sans plus jamais trouver de nouveau bug. Que faut-il en conclure ?
À quelle étape du processus fondamental prépare-t-on les jeux de données et l'environnement de test ?
Quel niveau de test vérifie une fonction ou une méthode isolée, généralement automatisé par les développeurs ?
Un rapport de bug bien rédigé doit avant tout être...
Rejoignez Le Labo QA gratuitement
Quiz d'entraînement, exercices pratiques et sauvegarde automatique de votre progression sur l'ensemble des parcours.
Bienvenue dans Le Labo QA
Votre session est active. Retrouvez l'ensemble de votre progression, reprenez vos quiz et consultez votre tableau de bord personnel.
À savoir
La Minute QA est une aide à la compréhension, pas une formation professionnelle : certains points ne peuvent pas être couverts ici. Pensez à suivre une formation certifiante et à consulter le syllabus officiel ISTQB pour une préparation complète.
Pour aller plus loin