Qu'est-ce que la QA ? Qualité, assurance, contrôle
Le gain du jour : distinguer trois mots qu’on confond en permanence — Quality Assurance, Quality Control, Testing — et comprendre pourquoi cette distinction change la façon dont une équipe travaille au quotidien.
Trois mots, trois métiers
Dans une conversation d’équipe, « QA » désigne tour à tour une personne, un processus et une phase de projet. Ce flou coûte cher : on demande au « QA » de réparer un bug, alors que son rôle est de le détecter et de le décrire, pas de le corriger.
Quality Assurance (QA) — l’ensemble des activités préventives, orientées processus, qui visent à empêcher les défauts d’apparaître : revues de spécifications, définition des critères d’acceptation, choix de la stratégie de test, standards de code. La QA agit avant et pendant le développement.
Quality Control (QC) — les activités qui vérifient qu’un produit fini respecte les exigences : exécuter des tests, comparer un résultat obtenu à un résultat attendu. Le QC agit après qu’une fonctionnalité existe.
Testing — une technique parmi d’autres du QC : exécuter un logiciel dans des conditions contrôlées pour observer son comportement et détecter des anomalies.
La QA, c’est écrire la recette et vérifier les ingrédients avant de cuisiner. Le QC, c’est goûter le plat une fois cuit. Le testing, c’est l’acte de goûter lui-même — un outil du QC. Un testeur qui ne fait qu’exécuter des tests fait du QC ; un testeur qui participe aussi aux revues de specs et challenge les exigences fait de la QA.
Pourquoi cette distinction compte en mobile
Sur une application mobile, une part énorme des défauts naît de décisions prises avant la première ligne de code : quelles versions d’OS supporter, quelle taille d’écran minimale, quel comportement hors-ligne. Un testeur qui n’intervient qu’à la fin — en QC pur — découvre ces problèmes trop tard, quand une app entière a été conçue sans mode hors-ligne alors que 30 % des utilisateurs ciblés ont une connexion instable.
C’est pour ça que la QA moderne pousse le test vers la gauche (shift-left testing) : plus une anomalie est détectée tôt dans le cycle, moins elle coûte cher à corriger. Un défaut trouvé en revue de spec coûte une relecture ; le même défaut découvert en production coûte un correctif d’urgence, une mise à jour du store, et la confiance d’utilisateurs qui ont vu l’app planter.
Le testeur QA n’est pas un « gardien de fin de chaîne »
Une idée reçue tenace : le testeur QA serait celui qui « bloque les livraisons ». En réalité, un bon testeur QA travaille en continu avec les développeurs et le product owner : il lit les spécifications avant qu’elles soient codées, pose des questions sur les cas limites qu’elles oublient, et construit sa stratégie de test en parallèle du développement — pas après.
La question la plus utile qu’un testeur QA puisse poser en réunion de spec n’est pas « comment on teste ça ? » mais « qu’est-ce qui se passe si… » — si le réseau coupe, si l’utilisateur revient en arrière, si deux appareils sont connectés au même compte. Ces questions, posées avant le code, évitent des bugs plutôt que de les détecter.
Vérifie ta compréhension
Une équipe définit les critères d'acceptation d'une fonctionnalité avant qu'elle soit codée. De quelle activité s'agit-il ?
Pourquoi le « shift-left testing » réduit-il le coût des défauts ?
À toi de jouer
La prochaine fois qu’on te présente une nouvelle fonctionnalité (au travail ou dans un projet perso), essaie de poser au moins une question « qu’est-ce qui se passe si… » avant qu’elle soit codée.
Repère dans une app mobile que tu utilises un bug qui, selon toi, aurait pu être évité par une question posée en amont plutôt que détecté en test.
🗂 Fiche de référence associée : Glossaire QA mobile — antisèche.