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 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.
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 l'utilisateur•rice. Ici, la cause racine est le manque de connaissance de la personne qui a rédigé la règle de gestion.
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.
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 de l'utilisateur•rice (« 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é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.
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 utilisateur•rices, 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.
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éveloppeur•ses.
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.
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.
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 utilisateur•rices ou le•la client•e (UATUser Acceptance Testing, alphaTest réalisé en interne, chez l'éditeur, avant toute diffusion externe, bêtaTest réalisé par de vrais·es utilisateur•rices externes, avant la sortie officielle).
05 — Psychologie
L'aspect humain du test
Le•la testeur•se collabore avec le•la développeur•se. Son rôle est de fournir des informations objectives pour améliorer le produit.
Indépendance du test
Plus le•la testeur•se est indépendant•e de l'équipe de développement, plus il·elle est susceptible de détecter des défauts avec un regard extérieur. Cependant, l'indépendance totale peut couper le•la testeur•se 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 testeur•ses et développeur•ses.
Curiosité et scepticisme
Un•e bon•ne testeur•se est curieux·se : il·elle se demande "et si ?" à chaque étape. Il·elle est "sceptique professionnel·le" : il·elle le vérifie.
A 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 testeur•ses et développeur•ses.
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...
À 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