Les 7 principes du test logiciel
Le gain du jour : connaître les 7 principes fondamentaux du test (issus du corpus ISTQB, référence du métier) pour raisonner sur pourquoi on teste comme on teste, plutôt que d’appliquer des recettes sans les comprendre.
1. Tester montre la présence de défauts, jamais leur absence
Un test qui passe prouve qu’un bug précis n’est pas là. Il ne prouve jamais que l’app est sans bug. « On a testé, ça marche » est une phrase dangereuse : elle sous-entend une garantie que le test ne peut pas donner.
2. Un test exhaustif est impossible
Une app mobile combine des dizaines d’appareils, plusieurs versions d’OS, des états réseau variables, des permissions activées ou non — le nombre de combinaisons est trop grand pour tout tester. On ne peut pas « tout » tester : on doit choisir, en priorisant par risque (voir principe 5).
3. Tester tôt fait économiser
Reprend l’idée du shift-left vue en leçon 1 : plus un défaut est détecté tôt (spec, design, code), moins il coûte cher à corriger. Sur mobile, un mauvais choix d’architecture réseau détecté en phase de conception coûte une discussion ; détecté après publication sur le store, il coûte une refonte en urgence.
4. Les défauts s’agglutinent
En pratique, la majorité des bugs se concentrent dans une minorité de modules — souvent ceux qui ont été codés dans l’urgence, ou qui touchent une logique complexe (paiement, synchronisation hors-ligne, permissions). Un testeur QA expérimenté oriente son effort vers ces zones à risque plutôt que de répartir son temps uniformément.
5. Le paradoxe du pesticide
Rejouer indéfiniment les mêmes tests finit par ne plus rien trouver — comme un insecte qui développe une résistance à un pesticide répété. Les tests doivent être révisés et complétés régulièrement, sinon ils ne détectent plus que les régressions déjà connues, jamais les nouveaux types de défauts.
6. Tester dépend du contexte
On ne teste pas une app bancaire comme un jeu mobile casual. Le niveau de rigueur, la proportion de tests de sécurité, l’exigence de disponibilité — tout dépend du contexte métier et du risque associé à un défaut non détecté.
7. L’illusion de l’absence de bug
Livrer une app quasi sans bug mais qui ne répond à aucun besoin réel est un échec, même si le test a été rigoureux. Le test vérifie que le produit fonctionne comme spécifié (verification) — mais quelqu’un doit aussi vérifier que ce qui est spécifié est bien ce dont l’utilisateur a besoin (validation). Les deux sont nécessaires.
Verification : « construit-on le produit correctement ? » (conforme aux specs). Validation : « construit-on le bon produit ? » (utile pour l’utilisateur). Un testeur QA rigoureux sur la verification mais silencieux sur la validation laisse passer des fonctionnalités inutiles, parfaitement testées.
Ces principes, appliqués au mobile
Le principe 2 (exhaustivité impossible) est particulièrement violent sur mobile : croiser modèles d’appareils × versions d’OS × orientations × langues × états réseau donne des dizaines de milliers de combinaisons théoriques. C’est pourquoi les leçons suivantes introduisent des outils concrets pour prioriser — matrices de compatibilité, tests basés sur le risque, automatisation ciblée — plutôt que de chercher une exhaustivité qui n’existe pas.
Vérifie ta compréhension
Une équipe teste une app pendant des mois sans trouver de nouveau bug avec la même suite de tests. Que faut-il en conclure ?
Pourquoi est-il impossible de « tout tester » sur une app mobile ?
🗂 Fiche de référence associée : Glossaire QA mobile — antisèche.