Système d’assurance qualité logicielle (QA)

Avant chaque version, une carte « Plan » est construite : elle définit le périmètre du test — les nouvelles fonctionnalités, les zones les plus risquées et les appareils et navigateurs couverts. Quand la release candidate est prête, elle passe dans « Exécution », où les testeurs parcourent les scénarios et consignent le résultat de chaque cas. Tout défaut découvert engendre une carte « Anomalie » décrivant les étapes de reproduction, le résultat attendu et le résultat constaté, et le degré de gravité ; un développeur l’adopte et le corrige. L’anomalie corrigée revient dans « Vérification », où un testeur autre que son auteur la reteste et s’assure que le correctif n’a rien cassé d’autre. Quand les anomalies critiques tombent à zéro, la carte mère passe dans « Lancement » avec une recommandation formelle, et les chiffres sont transférés dans « Rapport » : combien de cas exécutés, combien d’anomalies trouvées, et dans quelles zones se concentrent les défauts.

La Discussion est la salle de crise pendant le test : une anomalie critique qui bloque la version y est annoncée aussitôt, et la question « comportement voulu ou bug ? » se tranche avec le développeur en une minute au lieu d’une carte rejetée. Mais la règle est stricte : ce qui se tranche dans la Discussion comme décision est consigné sur la carte de l’anomalie elle-même — le tableau est le registre, pas la mémoire.

Le responsable QA rédige le « Plan », répartit l’exécution et détient la décision de recommandation de lancement — c’est lui qui arrête la version s’il reste des anomalies critiques. Les testeurs exécutent et rédigent les anomalies selon un standard unifié ; les développeurs prennent les anomalies, corrigent et les renvoient dans « Vérification ». Le principe du système : le testeur ne vérifie pas le correctif d’une anomalie qu’il a lui-même rédigée, et le lancement est une décision documentée par des chiffres, pas un sentiment général que ça a l’air d’aller.