Les 7 principes du test logiciel, expliqués simplement

Votre application vient de passer 300 tests sans une seule erreur. Est-elle sans bug ? Non. Et aucun testeur sérieux ne vous dira le contraire.

Ce n’est pas du pessimisme. C’est le premier des sept principes du test que l’ISTQB, l’organisme international qui certifie les testeurs de logiciels, enseigne dans son programme de base. Ces principes condensent des décennies d’expérience : la plus ancienne référence citée à leur appui date de 1970.

Chacun est expliqué ici sans jargon, illustré par une app du quotidien, et suivi de ce qu’il change concrètement dans votre façon de tester. À la fin, vous saurez les reconnaître dans vos propres projets, et vous aurez un exercice de dix minutes pour faire le point sur votre app.

D’où viennent ces sept principes ?

L’ISTQB (International Software Testing Qualifications Board) publie les programmes, appelés syllabus, des certifications de testeur reconnues dans le monde entier. Le premier niveau, dit « Fondation », consacre une section entière à sept principes : des lignes directrices générales, valables pour tous les tests, tirées de l’expérience.

La version 4.0 de ce programme est sortie en 2023, avec une correction mineure (4.0.1) en 2024 ; en français, il est traduit par le CFTL, le Comité Français des Tests Logiciels.

Ce ne sont pas des lois mathématiques. Ce sont des leçons que des générations de projets ont apprises à leurs dépens. Les connaître vous évite de les réapprendre de la même façon.

Le tableau suivant résume les sept principes, sous leur nom officiel en français, et la question pratique que chacun vous pose.

Pourquoi « aucun bug trouvé » ne veut pas dire « aucun bug » (principe 1)

Le test montre la présence, et non l’absence, de défauts. Un test qui échoue prouve qu’il y a un problème. Un test qui réussit prouve seulement que, dans ces conditions, avec ces données et sur ce téléphone, rien n’a mal tourné. Le test réduit le risque que des défauts restent cachés. Il ne le fait jamais tomber à zéro.

Prenez une app de mobile money. L’équipe teste des transferts entre deux numéros, avec des montants saisis au clavier : tout passe. Après la publication, un client copie le montant « 15 000 » depuis un SMS, avec son espace au milieu. Le champ le refuse. Personne n’a menti : les tests étaient tous verts. Ils ne couvraient simplement pas ce cas.

Ce que ça change en pratique :

• Bannissez la phrase « l’app est sans bug ». Dites plutôt : « ces 40 parcours ont été vérifiés sur ces 5 téléphones ».
• Dans chaque rapport de test, listez aussi ce qui n’a pas été testé.
• Après la publication, continuez à écouter : rapports de plantage, avis, messages au support.

Pourquoi on ne peut pas tout tester (principe 2)

Le test exhaustif est impossible, sauf dans des cas triviaux. Même une app modeste cache un nombre de combinaisons vertigineux.

Puisqu’on ne peut pas tout tester, on choisit, avec méthode. Deux outils suffisent pour commencer :

• Les techniques de test. Par exemple, l’analyse des valeurs limites : les bugs aiment les frontières. Pour notre formulaire, testez 99, 100, 101, 499 999, 500 000 et 500 001, puis un champ vide, un montant négatif, des lettres et « 15 000 » avec une espace. Une douzaine de tests bien choisis valent mieux que des milliers au hasard.
• Le test basé sur les risques. Pour chaque fonctionnalité, demandez-vous : quelle serait la gravité d’une panne, et quelle est sa probabilité ? Le paiement d’abord, la page « À propos » en dernier.

Ce que ça change en pratique : écrivez la liste de vos risques, du plus grave au moins grave, et répartissez votre temps de test en conséquence. Notre guide des types de test logiciel vous aide à choisir quoi tester, et comment.

Pourquoi tester tôt coûte moins cher (principe 3)

Tester tôt économise du temps et de l’argent. Un défaut éliminé au début du projet n’en engendre pas d’autres dans la suite du travail. Il y aura donc moins de défaillances plus tard. Pour y arriver, l’ISTQB recommande de commencer le plus tôt possible les tests statiques, sans exécuter le logiciel, comme la relecture d’un cahier des charges, et les tests dynamiques, en le faisant tourner.

Imaginez une app d’épargne collective, une tontine numérique. Le cahier des charges dit : « les intérêts sont versés chaque mois ». Une heure de relecture par quelqu’un qui pense comme un testeur fait surgir les questions. Chaque mois calendaire, ou tous les trente jours ? Arrondi au franc supérieur ou inférieur ? Que se passe-t-il si un membre retire son argent en cours de mois ?

Découvertes à ce stade, ces questions coûtent une réunion. Découvertes après trois mois de calculs faux en production, elles coûtent des corrections sur des milliers de comptes, des explications et de la confiance.

On parle aussi de shift left, « décaler vers la gauche » : on avance le test sur la ligne du temps du projet. Cela ne veut pas dire abandonner les tests de fin de parcours.

Ce que ça change en pratique :

• Faites relire chaque fonctionnalité avant de la coder, en traquant ambiguïtés, oublis et contradictions.
• Écrivez les critères d’acceptation avant le code ; nous l’expliquons dans vérifier ou valider.
• Testez chaque écran dès qu’il fonctionne, pas tout en bloc à la fin.

Pourquoi les bugs vivent en bande (principe 4)

Regroupement des défauts. Un petit nombre de composants concentre généralement la plupart des défauts trouvés, ou provoque la plupart des pannes en production. C’est une illustration du principe de Pareto : une petite partie des causes produit l’essentiel des effets.

Dans une app de livraison, le catalogue et la page de profil restent souvent calmes. Les ennuis se concentrent ailleurs : le paiement, qui jongle entre mobile money, carte et espèces à la livraison ; le suivi du livreur en temps réel, qui dépend du GPS et du réseau ; le calcul des frais, entre distance, promotions et heures de pointe. Ces zones cumulent tout ce qui attire les bugs : de la complexité, des services externes et des changements fréquents.

Ce que ça change en pratique :

• Tenez un journal simple des bugs, classés par module. Un tableur suffit. Après quelques semaines, vos zones à risque apparaissent d’elles-mêmes.
• Quand vous trouvez un bug, cherchez ses voisins : le même écran, la même règle, le même service externe.
• Servez-vous de ces zones pour prioriser vos tests (principe 2).

Pourquoi les mêmes tests finissent par ne plus rien trouver (principe 5)

Usure des tests. Répétés encore et encore, les mêmes tests deviennent de moins en moins efficaces pour trouver de nouveaux défauts. Ce principe a longtemps été appelé « paradoxe du pesticide » : comme un insecticide utilisé trop souvent, la même série de tests finit par ne plus rien attraper.

Une équipe teste une app bancaire depuis six mois. Chaque fois, même compte de test, même virement de 1 000 FCFA vers le même bénéficiaire, sur le même téléphone. Tout est vert. Pendant ce temps, de vrais clients tombent sur des cas que personne n’a jamais essayés : deux bénéficiaires portant le même nom, un téléphone réglé en anglais avec un autre format de date, un virement juste au-dessus du plafond journalier.

Ce que ça change en pratique :

• Variez vos données : montants, noms avec accents ou apostrophes, numéros, langues.
• Variez vos appareils et vos chemins : bouton retour, notifications, app reprise après un appel.
• À chaque bug trouvé par un utilisateur, ajoutez un test qui l’aurait attrapé.
• Organisez des sessions de test exploratoire, et faites intervenir des testeurs qui n’ont jamais vu l’app, comme ceux de GeekTest : un regard neuf brise la routine.

Une nuance importante : répéter les mêmes tests reste utile pour les tests de non-régression automatisés. Leur rôle n’est pas de découvrir de nouveaux bugs, mais de vérifier que les anciens ne reviennent pas.

Pourquoi il n’existe pas de recette de test universelle (principe 6)

Le test dépend du contexte. Il n’existe pas d’approche unique, valable partout. On ne teste pas un jeu comme une app de paiement, ni une startup de trois personnes comme une banque soumise à un régulateur.

Le tableau suivant compare ce qui compte le plus dans quatre contextes différents.

Ce que ça change en pratique : avant de tester, écrivez trois lignes. Qui sont vos utilisateurs (téléphones, réseau, langues) ? Quel est le pire qui puisse arriver ? Quelles sont vos contraintes (délais, réglementation, budget) ? Puis bâtissez votre approche à partir de ces réponses, au lieu de copier le plan de test d’un autre projet. Pour une app de santé, par exemple, l’accessibilité passe au premier plan.

Pourquoi une app sans bug peut quand même échouer (principe 7)

L’illusion de l’absence de défaut. Croire qu’un logiciel bien vérifié réussira forcément est une erreur. On peut tester toutes les exigences écrites, corriger tous les défauts trouvés, et livrer pourtant un produit qui ne répond pas aux besoins des utilisateurs, qui n’atteint pas les objectifs du client, ou qui fait moins bien que la concurrence.

Une école commande une app de paiement des frais de scolarité. Le cahier des charges prévoit le paiement par carte bancaire, un reçu par e-mail et une interface en français. L’app est testée avec soin : zéro défaut connu. Mais dans cette école, les parents paient par mobile money, beaucoup n’ont pas d’adresse e-mail qu’ils consultent, et une partie d’entre eux préfère l’anglais. Résultat : zéro bug, et presque aucun utilisateur.

Ce que ça change en pratique : posez toujours deux questions. « Est-ce que ça marche ? », c’est la vérification. « Est-ce que ça sert ? », c’est la validation. Mettez l’app entre les mains de vrais utilisateurs tôt et souvent ; notre guide pour organiser un test utilisateur vous montre comment.

Exercice : passez votre app au crible des sept principes

Prenez dix minutes et répondez honnêtement, par oui ou par non. Chaque « non » est votre prochain chantier.

Ces sept principes sont aussi la porte d’entrée de la certification ISTQB Fondation, que nous présentons dans notre guide des certifications en test logiciel. Que vous fassiez tester votre app ou que vous vouliez devenir testeur, vous parlez désormais la même langue que les professionnels.

Pour aller plus loin

• Syllabus ISTQB Niveau Fondation v4.0, en français (CFTL) (nouvel onglet) : les sept principes sont décrits dans la section 1.3, avec leurs références d’origine.
• Syllabus ISTQB Foundation Level v4.0.1 (nouvel onglet) (en anglais) : la version en vigueur du programme, corrigée en 2024.
• ISTQB : la certification Foundation Level (nouvel onglet) (en anglais) : la présentation officielle de la certification et de ses documents.
• Glossaire ISTQB en français (CFTL) (nouvel onglet) : les définitions officielles de défaut, défaillance, test basé sur les risques et des autres termes du métier.