Séances Cycle 4
C4-S10 — Tests et validation
Cycle 4 (5e - 4e - 3e)C4-S10
Plan de tests, cas limites et validation logicielle
Niveau : 5e, 4e, 3e
Durée : 55 minutes
Outil : Scratch
Organisation : Binômes
⚡ Actions rapides :📥Télécharger la fiche (PDF)
⚡EN 2 MINUTES CHRONO (L'ESSENTIEL POUR LA CLASSE)
⏱️ 15' Matrice de recette • 25' Audit croisé • 15' Restitution🎯 Objectif unique : Rédiger et exécuter une matrice de tests complète pour valider la robustesse d'un projet.
📦 Matériel exact : Cahier de plan de tests + projet partenaire à auditer.
⚠️ Piège n°1 à éviter : Ne tester que le cas idéal sans tester les cas limites (score négatif, bord d'écran).
🎯 Objectifs d'apprentissage observables
- Rédiger un plan de tests structuré comportant cas nominaux, cas limites (Edge Cases) et entrées erronées.
- Mener une campagne de tests croisés sur le projet d'un autre binôme (recette logicielle).
- Tracer un rapport de bugs documenté et reproductible.
🎒 La matrice des 4 types de tests
| Type de test | Objectif | Exemple |
|---|---|---|
| 1. Cas nominal (Normal) | Vérifier que le programme marche dans les conditions idéales | Le joueur avance, touche 1 pièce → Score passe à 1 |
| 2. Cas limite (Aux bornes) | Tester les extrêmes de l'espace ou des valeurs | Toucher la pièce exactement sur la coordonnée X = 240 ou quand temps = 0 |
| 3. Entrée erronée (Stress) | Vérifier la résistance aux mauvaises saisies | Taper des lettres quand on demande un nombre |
| 4. Non-régression | Vérifier qu'une correction n'a pas cassé le reste | Après correction du tir, le saut fonctionne-t-il toujours ? |
⏱️ Déroulé de la séance
1. Théorie du test logiciel (15 min)
Dans l'industrie numérique, jusqu'à 50% du temps des équipes de développement est consacré à la conception et à l'exécution de tests.
2. Atelier de test croisé (30 min)
📝 Mission : L'audit qualité du projet partenaire
MoyenChanger de place avec le binôme voisin et tester son jeu en appliquant la grille : 1. Tester la victoire (atteindre le score maximal). 2. Tester la défaite (laisser le temps s'écouler). 3. Tenter de faire sortir le joueur de l'écran ou de bloquer les commandes. 4. Rédiger le rapport d'audit avec les 3 dysfonctionnements trouvés.
3. Restitution & Débriefing constructif (10 min)
Chaque équipe reçoit le rapport de bugs rédigé par ses pairs et planifie les correctifs à apporter.
💡 Postures d'évaluation bienveillante
Sensibilisez les élèves à la formulation constructive : un testeur ne cherche pas à « critiquer » mais à aider son partenaire à rendre son logiciel plus robuste.
📊 Grille d'évaluation
| Critère observable | Avec aide | Autonome | Transfert / Dépassement |
|---|---|---|---|
| Rédige et exécute un plan de tests complet | Teste le jeu en jouant sans méthode | Suit une grille méthodique couvrant tous les cas limites | Rédige des scénarios de test automatisables |
| Documente les anomalies de façon reproductible | Dit simplement *« Ça ne marche pas »* | Décrit les étapes exactes permettant de reproduire le bug | Suggère la ligne de code probable à l'origine du problème |
📥 Téléchargements
Cahier de plan de tests et recette logicielle (C4-S10)
c4-s10-cahier-plan-de-tests-v1.pdf • PDF • 1.2 KB • v1.0 • CC-BY-SA 4.0
Last modified on