Vérifier une correction livrée

Vérifier une correction livrée
Vendredi 9 octobre 2026 • 8 h–10 h
B1.2 • SPOPI / DSIIR
Tests de correction, non-régression et validation du service rendu
Ce que nous ajoutons à la semaine 5
En S05 : reproduire un incident et chercher une explication.
Aujourd’hui : une correction est annoncée. Il faut décider si elle répond au besoin sans dégrader d’autres fonctions.
Nouveaux gestes : préparer une recette, repérer une régression, contrôler l’enregistrement réel, justifier une décision.
Travail sur papier.
La mission confiée
8 h–8 h 10 • Lecture et première décision.
Nouveau cas fictif : ticket SPOPI-B1-TCK-021, formulaire de demande de matériel.
Alice doit demander « Prêt d’un vidéoprojecteur ». La version 1.0 refuse la description contenant une apostrophe.
Le développeur annonce : « Version 1.1 disponible sur l’environnement de test ; problème corrigé. »
Sur feuille : cette annonce suffit-elle à clôturer le ticket ? Quelle preuve demander en premier ?
Les règles du formulaire
Ces règles sont les exigences fournies pour cet exercice.
Description obligatoire : de 1 à 200 caractères après retrait des espaces en début et fin.
Les apostrophes doivent être acceptées et le texte conservé exactement.
Une demande valide doit être créée une seule fois, avec une référence.
Elle doit être retrouvée dans la liste puis ouverte avec son contenu exact.
Une entrée invalide doit être refusée clairement, sans création de demande.
Tous les cas et résultats du cours sont fictifs et fournis pour analyse.
Correction de la première décision
Une annonce de correction ne prouve pas le service rendu.
Demander d’abord un essai reproduisant le cas initial sur la version 1.1.
Il faudra aussi contrôler les fonctions qui marchaient déjà, les entrées invalides et la présence effective de la demande.
Le ticket reste en cours de vérification.
Trois vérifications complémentaires
8 h 10–8 h 25 • Repères.
Test de correction : rejouer le cas qui échouait, par exemple une description avec apostrophe.
Test de non-régression : vérifier qu’un comportement auparavant correct fonctionne encore, par exemple une demande ordinaire ou le refus d’une description vide.
Validation du service rendu : vérifier que l’utilisateur peut accomplir son travail, jusqu’à retrouver sa demande enregistrée.
Le résultat attendu vient avant le résultat observé
On tire le résultat attendu des règles du service, pas du comportement du logiciel.
Pour une description vide, le succès du test est un refus clair sans création.
Un message vert ne suffit pas à réussir tous les tests.
Un défaut apparu après une modification sur un comportement auparavant correct est une régression.
Les limites et les entrées invalides
Limite basse : 0 et 1 caractère.
Limite haute : 200 et 201 caractères.
Une description composée uniquement d’espaces devient vide après nettoyage.
Pour tester 200 caractères, prévoir un texte fictif dont la longueur est vérifiée.
Ces tests complètent le cas de l’apostrophe ; ils ne prouvent pas que tous les cas possibles ont été couverts.
Une fiche de test exploitable
Chaque ligne comporte : identifiant, version et environnement, données, étapes, résultat attendu, résultat observé, verdict et preuve.
Verdicts : conforme / non conforme / non vérifié.
Exemple à préparer : description de 201 caractères → envoyer → refus explicite attendu, aucune nouvelle demande.
Preuve nécessaire : message ET contrôle de l’absence de création.
Activité A Construire la recette
8 h 25–8 h 45 • 10 min seul, 5 min en binôme, 5 min correction.
Sans connaître les résultats de la version 1.1, préparez six tests :
A1. Description avec apostrophe.
A2. Description ordinaire.
A3. Description vide.
A4. Description composée de trois espaces.
A5. Description de 200 caractères.
A6. Description de 201 caractères.
Pour chacun : données, résultat attendu, contrôle de la création ou de son absence.
Activité A Donner un sens aux tests
Pour chaque test, indiquez son objectif : correction, non-régression, limite ou entrée invalide. Un test peut avoir plusieurs objectifs.
Ajoutez le contrôle qui permet de vérifier le service rendu après chaque envoi valide.
Échangez avec votre voisin : ses résultats attendus découlent-ils des règles ?
Ne consultez les résultats qu’après avoir terminé votre plan.
Correction A La recette attendue
Après acceptation : relever la référence, retrouver la demande et l’ouvrir.
Correction A Les objectifs
T1 vérifie directement la correction du défaut initial.
T2 vérifie un usage ordinaire qui fonctionnait déjà.
T3 à T6 examinent des entrées invalides et la limite haute. Leur comparaison avec la version 1.0 permettra aussi de détecter une régression.
Pour compléter la limite basse : ajouter une description d’un caractère, qui doit être acceptée et conservée.
Ne pas accepter un test dont le résultat attendu se limite à « ça fonctionne ».
Activité B Résultats des versions 1.0 et 1.1
8 h 45–9 h 10 • 15 min analyse, 10 min correction.
Chaque essai utilise un jeu de données propre sur un environnement de test. Observations fictives fournies.
Activité B Justifier les verdicts
B1. Donnez le verdict de chaque test par rapport à la règle, avec une preuve précise.
B2. Le défaut de l’apostrophe est-il corrigé dans le cas testé ?
B3. Repérez les régressions en comparant 1.0 et 1.1.
B4. Peut-on accepter la version 1.1 pour le service ? Justifiez sans compter simplement le nombre de succès.
B5. Quelles informations transmettre au développeur ?
Écrivez « d’après les observations fournies » : vous n’avez pas exécuté ces tests.
Correction B Les verdicts
Un refus peut être conforme ; un message de succès peut accompagner un défaut.
Correction B La décision sur la version
Le cas initial avec apostrophe est corrigé dans le test T1.
T3, T4 et T5 révèlent des régressions : ils étaient conformes en 1.0.
La version 1.1 ne peut pas être acceptée au regard des exigences fournies : demandes vides et perte de contenu.
Transmettre version, environnement, données, étapes, attendu, observé et preuves.
Trois tests réussis sur six ne compensent pas une perte de données.
Activité C Le succès affiché suffit-il
9 h 10–9 h 30 • 12 min rédaction, 8 min correction.
Le développeur fournit ensuite une version 1.2. Nouveau dossier d’observations indépendant :
Apostrophe et texte ordinaire : succès affiché, références D201 et D202 ; personne n’a encore ouvert ces demandes.
Vide et espaces : refus clair ; absence de création contrôlée.
201 caractères : refus clair ; absence de création contrôlée.
200 caractères : D203 retrouvée et ouverte ; 200 caractères exacts.
Alice n’a pas encore essayé cette version.
C1. Que pouvez-vous valider ? Que reste-t-il non vérifié ?
Activité C Décider et informer
C2. Proposez les contrôles manquants avant clôture : une vérification technique et une validation du service rendu.
C3. Rédigez une mise à jour du ticket : version examinée, faits établis, contrôles manquants, statut et prochaine étape.
C4. Rédigez trois ou quatre phrases à Alice, sans annoncer une clôture ni inventer un délai.
Pour cette situation pédagogique, la clôture exige des contrôles techniques concluants et une confirmation du service rendu à Alice.
Correction C Les contrôles manquants
Les refus des entrées invalides et la conservation des 200 caractères sont documentés en 1.2.
Pour D201 et D202, l’affichage du succès ne suffit pas : retrouver et ouvrir chaque demande, vérifier l’unicité et le texte exact.
Faire ensuite réaliser à Alice une demande représentative et lui faire confirmer qu’elle peut la retrouver et poursuivre son travail.
Statut : en cours de vérification. Les éléments manquants sont non vérifiés, pas automatiquement en échec.
Correction C Ticket et message
Ticket : « Version 1.2 sur environnement de test. Refus des entrées invalides et conservation de D203 vérifiés dans le dossier. D201 et D202 restent à ouvrir et comparer. Validation utilisateur non réalisée. Ticket maintenu en cours de vérification. »
Message : « Bonjour Alice, une nouvelle version du formulaire est en cours de vérification. Les contrôles des entrées invalides et du texte de 200 caractères sont concluants. Nous devons encore vérifier le contenu de deux demandes, puis vous proposer un essai représentatif. Nous confirmerons avec vous que le service répond au besoin avant de clôturer. »
Activité D Transférer la méthode
9 h 30–9 h 45 • 8 min seul, 7 min correction.
Autre cas fictif : un export CSV omettait les noms contenant un accent. Une correction est livrée.
Règles : exporter chaque ligne sélectionnée une seule fois, avec nom exact et quantité exacte.
D1. Proposez un test de correction, un test de non-régression et un contrôle du service rendu.
D2. Le fichier se télécharge et contient désormais « Élodie », mais une ligne ordinaire présente auparavant manque. Quel verdict ?
D3. Une seule ligne retrouvée suffit-elle à valider l’export complet ? Justifiez.
Correction D Vérifier un export
Correction : exporter une ligne avec « Élodie » et contrôler le nom exact.
Non-régression : exporter aussi des lignes ordinaires connues et comparer toutes leurs données.
Service rendu : ouvrir le fichier, comparer les lignes sélectionnées, leur nombre, l’unicité et les quantités.
La ligne ordinaire manquante est une régression. Le téléchargement et la présence d’Élodie ne suffisent pas.
Transmettre les écarts ; ne pas accepter cet export comme complet.
La méthode de recette
9 h 45–9 h 55 • Synthèse.
01Lire les exigences et définir l’attendu.
02Rejouer le défaut initial.
03Vérifier les usages auparavant corrects.
04Tester les limites et les entrées invalides.
05Contrôler les données réellement enregistrées ou exportées.
06Documenter les écarts et valider le service rendu.
Une recette est un ensemble de vérifications permettant de décider si la livraison répond aux exigences.
La trace à conserver
Sur papier, rédigez cinq lignes et un exemple personnel :
« Une correction annoncée doit être vérifiée. Je rejoue le cas initial et je recherche des régressions. Les résultats attendus viennent des exigences. Je contrôle les données, au-delà du message affiché. Je justifie l’acceptation ou les vérifications encore nécessaires. »
À recopier dans Obsidian lors du prochain accès à un ordinateur : B1.2 - Vérification d’une correction.
Conservez votre plan de tests et vos verdicts.
Billet de sortie individuel
9 h 55–10 h • Non noté, sans échange.
Sur une feuille avec votre nom :
Expliquez la différence entre test de correction et test de non-régression.
1.Donnez un cas où un refus du formulaire est le résultat attendu.
2.Le message « enregistré » apparaît : quelle preuve manque encore ?
3.
Remettez votre billet à l’enseignant.