Rapport de tests - Projet de Développement Apprentissage BUT3

Tester les jeux des deux autres équipes et transmettre à chacune des retours utiles pour le Sprint 4.

Chaque équipe teste les deux autres jeux. Vous préparez des scénarios, consignez leurs résultats et décrivez les problèmes sous forme de fiches de bugs dans votre rapport.

Vous remettez un seul rapport, dans docs/tests/rapport.md, comprenant une présentation de votre organisation et une section par jeu.

Le rapport de tests est une production évaluée collectivement : répartissez les tests et la rédaction entre les membres. Il ne fait pas partie des 15 documents de suivi attribués individuellement.

Échéance	Résultat attendu
15/03/2027 — Livrable 3	Présenter la démarche, les résultats et les priorités proposées.
20/03/2027 — Rapport de tests	Remettre le rapport finalisé après les retours de la présentation.

Les horaires limites figurent dans le calendrier. Les consignes de présentation sont précisées dans les livrables.

Ce qui est évalué¶

Le rapport finalisé porte l’unique note collective du livrable 3. La présentation du lundi permet de discuter les résultats et de recueillir des retours avant la remise. La conduite de cette présentation par le Scrum Master est évaluée séparément.

Consultez la grille du rapport de tests sur Moodle avant de préparer les tests, puis relisez-la avant le dépôt.

Critère	Éléments attendus dans votre travail
Démarche de test et traçabilité	Des scénarios pertinents pour les deux jeux, avec les versions, environnements, actions et résultats permettant de retrouver les essais.
Diagnostic et recommandations	Des constats étayés, des problèmes reproductibles lorsqu’ils existent, des priorités justifiées et des recommandations utiles à chaque équipe.
Planification et suivi du Sprint Backlog 3	Une répartition du travail adaptée aux deux jeux, un suivi des tâches et des explications sur les reports ou adaptations.
Organisation et utilisabilité du rapport	Un rapport structuré par jeu, dont les résultats, fiches et références sont faciles à retrouver.

La note ne dépend pas du nombre de bugs trouvés. Un travail rigoureux peut satisfaire pleinement la grille même sans bug : rendez les scénarios, les résultats positifs et les limites des vérifications consultables.

Pour le suivi du Sprint 3, appuyez-vous sur votre backlog et vos issues existantes ; résumez les adaptations dans l’organisation générale du rapport.

Organiser les tests¶

Préparez les tests dès la planification du Sprint 3 et rédigez le rapport pendant leur exécution.

Répartissez les membres, les domaines et le temps disponible entre les deux jeux dans votre Sprint Backlog. Prévoyez aussi le temps de reproduire les problèmes, de rédiger les fiches de bugs et de préparer la synthèse.

Vous pouvez réutiliser une même trame de scénarios pour les deux jeux, mais leurs résultats doivent être consignés séparément. Commencez par leurs fonctionnalités essentielles avant d’approfondir les situations qui présentent le plus de risques.

Où travailler ?	Que conserver ?
Votre dépôt	Les tâches du Sprint 3 dans GitLab Issues ; le rapport, les résultats et les fiches de bugs dans `docs/tests/rapport.md`.
Dépôts des équipes testées	Les versions du jeu, le code et les documents que vous consultez pour réaliser les tests.

Les fiches identifient le jeu concerné et comportent un lien complet vers le commit testé.

Préparer une version de référence

Effectuez les vérifications suivantes pour chacun des deux jeux.

Récupérez le commit exact fourni par l’équipe testée et les instructions de lancement correspondantes.
Relevez la version de Godot, le système utilisé et la date des tests.
Consultez le document de design, les commandes et les instructions du mode de développement.
Vérifiez que vous pouvez consulter et cloner les deux dépôts. Signalez rapidement tout problème d’accès aux encadrants.

Commencez par suivre les instructions de lancement telles qu’elles sont fournies. Si une explication manque ou si une étape supplémentaire est nécessaire, conservez cette observation dans vos résultats.

Répartissez les vérifications de lancement sous Windows, macOS et Linux (Ubuntu). Indiquez les systèmes et leurs versions, ainsi que les environnements que vous n’avez pas pu tester. Signalez tôt les difficultés d’accès à une machine afin d’organiser les tests avec les encadrants.

Si une version web est disponible, vérifiez également son lancement et une partie courte dans un navigateur sur ordinateur.

Il n’est pas nécessaire de répéter tous les scénarios sur chaque système. Vérifiez le lancement et une partie représentative sur chacun, puis ciblez les tests supplémentaires selon les problèmes rencontrés. Un résultat obtenu sur un environnement ne valide pas les autres.

Choisir les scénarios¶

Un scénario décrit une situation, les actions à effectuer et le résultat attendu.

Domaine	Exemples de vérifications
Lancement et prise en main	Suivre le README, ouvrir le projet, lancer une partie et comprendre les commandes.
Jeu de plateforme	Se déplacer, sauter, rencontrer des obstacles et utiliser les mécaniques essentielles.
Déroulement d’une partie	Atteindre l’objectif, perdre, recommencer et vérifier la remise à zéro de l’état du jeu.
Génération des niveaux	Essayer différentes graines, vérifier les passages entre salles et la possibilité d’atteindre la sortie.
Mode de développement	Utiliser les commandes documentées pour reproduire une situation et accélérer les tests.
Situations limites	Tester des cas pertinents pour le jeu : bord de plateforme, collision particulière, action répétée ou redémarrage.

Adapter les tests au jeu et au temps disponible

Commencez par une partie normale, puis examinez les comportements qui présentent le plus de risques. Répartissez les domaines entre les membres pour couvrir des situations différentes.

Pour la génération, vérifiez que les passages sont réellement praticables par le personnage, compte tenu de ses déplacements, des obstacles et des ouvertures entre salles.

Vérifiez également qu’une même graine permet de retrouver le même niveau dans les mêmes conditions et sur la même version du jeu. Conservez les graines utilisées dans les résultats concernés.

Des tests manuels bien décrits suffisent. Aucun nombre imposé de tests, de bugs ou de captures n’est demandé. Quelques générations réussies ne prouvent pas que tous les niveaux possibles sont jouables : précisez les limites de vos vérifications.

Consigner les résultats¶

Conservez les résultats positifs comme les problèmes rencontrés. Pour chaque scénario, indiquez les actions effectuées, le résultat attendu, le résultat observé et son statut.

Statut	Signification
Réussi	Le scénario a été exécuté et le résultat correspond à l’attendu.
Échoué	Le scénario a été exécuté et un écart a été observé.
Bloqué	Une difficulté empêche d’exécuter le scénario ; indiquez laquelle.
Non exécuté	Le scénario était prévu mais n’a pas été réalisé ; précisez pourquoi.

Garder des résultats vérifiables

Indiquez la version et l’environnement de référence en tête de la section de chaque jeu. Précisez les exceptions dans les lignes concernées, ou regroupez les résultats par environnement.

Pour un test lié à la génération, ajoutez la graine, les conditions initiales et les actions utiles. La graine seule ne décrit pas tout ce qui s’est passé pendant une partie.

Si le jeu ne démarre pas à cause d’un défaut, le test de lancement est échoué et les tests de jeu qui en dépendent sont bloqués. Signalez le problème et poursuivez les vérifications encore possibles, par exemple la lecture des instructions. Décrivez cette limite dans le rapport.

Si vous testez ensuite une correction, conservez l’observation initiale et ajoutez le nouveau résultat avec le commit correspondant. Une modification du générateur peut changer le niveau produit par une même graine : précisez comment vous avez adapté le scénario.

Décrire les bugs dans le rapport¶

Une fiche doit permettre à l’équipe de développement de comprendre et de reproduire le problème.

Dans la section de chaque jeu, ajoutez une fiche par problème distinct. Utilisez un identifiant stable : J1-B01, J1-B02… pour le premier jeu, puis J2-B01, J2-B02… pour le second.

Plusieurs scénarios peuvent renvoyer à la même fiche. Complétez-la avec les observations utiles au lieu de décrire plusieurs fois le même bug.

Les fiches sont rédigées au fil des tests dans votre propre dépôt. Vous ne créez pas d’issues dans les projets des équipes testées.

Modèle de fiche de bug

Ajoutez les fiches sous une rubrique « Fiches de bugs » dans la section du jeu concerné.

#### J1-B01 — Titre précis du problème

- Commit testé : lien complet.
- Godot : version exacte.
- Système : nom et version.

**Conditions initiales**

Scène ou niveau, graine, état du joueur et options de développement utiles.

**Étapes de reproduction**

1. ...
2. ...
3. ...

**Résultat attendu**

...

**Résultat observé**

...

**Impact et priorité proposée**

Conséquence pour le joueur et priorité justifiée.
Si le problème est intermittent : fréquence observée pendant les essais.

**Éléments complémentaires**

Capture ou courte vidéo, si utile.
Cause vérifiée, hypothèse ou piste de correction, si disponible.
Distinguer clairement ce qui est établi de ce qui reste à vérifier.

Il n’est pas nécessaire de connaître la correction pour signaler un bug.

Rédiger la synthèse¶

Chaque section du rapport doit aider l’équipe concernée à choisir les corrections du Sprint 4.

Présentez les comportements satisfaisants, les principaux défauts, leurs conséquences et les limites des tests. Les étapes détaillées de reproduction figurent dans les fiches de bugs ; la synthèse en conserve un résumé et les références.

Les captures d’écran et les courts extraits vidéo montrant les bugs en jeu sont encouragés. Conservez-les dans votre dépôt, par exemple dans docs/tests/medias/, et référencez-les dans les fiches concernées. Privilégiez des fichiers courts et de taille raisonnable.

Vous pouvez réutiliser ces éléments pendant la présentation du livrable 3. Ils complètent la description du problème et les étapes de reproduction.

Proposer des priorités et des améliorations

Justifiez les priorités par l’effet sur le jeu : impossibilité de lancer une partie, progression bloquée, mécanique peu fiable, difficulté de compréhension ou défaut visuel mineur, par exemple.

Distinguez les bugs des suggestions d’amélioration. Une préférence personnelle ou une nouvelle fonctionnalité souhaitée n’est pas automatiquement un défaut. Expliquez l’intérêt des suggestions en tenant compte du périmètre du jeu et du temps restant.

L’équipe propriétaire du jeu examine les deux rapports reçus, regroupe les doublons et décide des corrections à réaliser. Elle crée ou complète ses propres issues, avec un lien permanent vers le rapport consulté et les identifiants des fiches concernées, puis organise son Sprint 4.

Votre travail de test ne vous impose pas de corriger son code.

Modèle de rapport à copier dans votre dépôt

Créez le fichier docs/tests/rapport.md et complétez-le au fil des tests.

# Rapport de tests

- Équipe ayant réalisé les tests : ...

## Organisation générale

Répartition du travail et du temps entre les deux jeux.
Lien vers notre Sprint Backlog 3.
Travail réalisé ou reporté par rapport au plan et adaptations décidées.

## Jeu 1 — Titre du jeu

### Version et périmètre

- Équipe testée : ...
- Dépôt testé : lien complet.
- Commit de référence testé : lien complet vers le commit.
- Version de Godot : ...
- Système(s) et version(s) : ...
- Date(s) des tests : ...
- Domaines testés : ...

### Scénarios et résultats

| Scénario et actions | Résultat attendu | Résultat observé | Statut | Fiche(s) |
| --- | --- | --- | --- | --- |
| T01 — ... | ... | ... | Réussi / Échoué / Bloqué / Non exécuté | Identifiant ou lien vers la fiche si nécessaire. |

Ajouter les graines et conditions particulières dans les lignes concernées.
Si un test est repris sur une autre version, ajouter son nouveau résultat
avec le commit correspondant en conservant le résultat initial.

### Fiches de bugs

Ajouter ici les fiches des problèmes rencontrés, selon le modèle fourni.

### Synthèse des résultats

- Comportements satisfaisants vérifiés : ...
- Principales difficultés pour le joueur : ...

| Problème important | Priorité proposée et justification | Fiche |
| --- | --- | --- |
| Résumé du défaut et de son impact. | ... | Identifiant ou lien vers la fiche. |

### Améliorations proposées

Suggestions distinctes des bugs et intérêt pour le joueur.
Indiquer si aucune suggestion ne paraît utile.

### Limites et suite recommandée

- Tests bloqués ou non exécutés et raisons : ...
- Autres limites des vérifications : ...
- Corrections ou vérifications à traiter en priorité au Sprint 4 : ...

## Jeu 2 — Titre du jeu

Reprendre ici les mêmes sous-sections que pour le premier jeu
et les compléter avec ses propres versions, résultats et recommandations.

Un même bug peut être révélé par plusieurs scénarios : réutilisez alors la référence de la même fiche.

Dépôt sur Moodle¶

Effectuez un dépôt par équipe, comprenant :

Le nom de votre équipe, ceux des deux équipes testées et les titres des deux jeux.
Un lien permanent vers la version remise du rapport Markdown, en suivant le guide d’organisation du dépôt.

Vérifiez que les encadrants et les deux équipes testées peuvent consulter le rapport, les fiches de bugs et les captures ou vidéos liées.

Les résultats et la synthèse doivent être prêts pour le livrable 3. Le délai du samedi permet de finaliser le rapport en tenant compte des échanges. Aucun compte rendu de Sprint Review supplémentaire n’est demandé après ce livrable.

Chaque membre, y compris le Scrum Master, remet également son bilan individuel du Sprint 3 sur Moodle pour le 20/03/2027. Ce dépôt est privé et distinct du rapport collectif.