--- title: "Cas de test" weight: 40 description: "Créer et organiser les points à tester : intitulé, instructions, cycle de vie, référence." --- # Cas de test Un cas de test (ou point de test) est une chose à vérifier dans un projet : une fonctionnalité, un comportement, un écran. Cette page s'adresse aux développeurs et aux administrateurs, qui créent et font évoluer ces points. Les testeurs, eux, les consultent et les cochent (voir [Todolist et verdicts](/captests/todolist-et-verdicts)). ## Créer un cas Depuis la todolist d'un projet, cliquez sur **Nouveau cas**. Le formulaire comporte les champs suivants : - **Intitulé** : le titre court du point à tester (obligatoire). - **Section** : un regroupement logique, par exemple "Authentification" ou "Facturation". Les points sont affichés groupés par section dans la todolist. - **Plateformes cibles** : les appareils concernés par le point (Mobile, Tablette, Desktop). Cochez une ou plusieurs cases, ou aucune (voir [Plateformes cibles](#plateformes-cibles) ci-dessous). - **Cycle de vie** : l'état du point dans son parcours (voir ci-dessous). - **Couvrable par un test automatique** : cochez cette case si le point peut, à terme, être vérifié par un test automatique. Décochez-la pour un point intrinsèquement manuel (placement visuel, ergonomie, rendu natif). Un point non automatisable n'apparaîtra jamais comme un trou de couverture. - **Lien d'aide (URL)** : un lien complémentaire facultatif (documentation, vidéo, page d'aide) affiché aux testeurs. - **Instructions (Markdown)** : la description détaillée de ce qu'il faut tester, pas à pas. Le format Markdown est accepté. ![Formulaire de création d'un cas de test avec l'intitulé, la section et les instructions](screenshots/formulaire-cas.webp) Cliquez sur **Créer le cas** pour valider. capTests attribue automatiquement une **référence** au point. ## La référence automatique Chaque point reçoit une référence stable et unique au sein du projet, par exemple `TC-SI-001`, `TC-SI-002`, etc. Elle est composée du préfixe défini sur le projet (par exemple `TC-SI`) suivi d'un numéro incrémenté automatiquement. Cette référence joue un rôle clé : c'est elle qui relie un point de test à son test automatique. Le développeur pose sur le test un repère dérivé de cette référence, ce qui permet à capTests de rapprocher le résultat du test du bon point (voir [Automatisation](/captests/automatisation)). La référence ne change jamais, même si l'intitulé évolue. ## Le cycle de vie d'un point Le champ Cycle de vie décrit l'avancement d'un point, du besoin identifié à sa recette : | Cycle de vie | Signification | |--------------|----------------------------------------------------------------------| | Backlog | Point identifié, fonctionnalité pas encore développée. | | Roadmap | Évolution structurante, à horizon lointain. | | En cours | Développement en cours. | | À tester | Développé, prêt pour la recette. | | Abandonné | Clos volontairement (par exemple "comportement attendu"). | | Archivé | Obsolète. | Seuls les points **À tester** entrent par défaut dans la campagne d'une version. Les points en Backlog ou Roadmap vivent à part : ils représentent ce qui n'est pas encore prêt à être recetté. Pour voir des points dans un autre état, changez le filtre de statut dans la todolist. ## Plateformes cibles Un point peut viser un ou plusieurs appareils : **Mobile**, **Tablette**, **Desktop**. Ces étiquettes apparaissent sous forme de badges sur la fiche du point et dans la todolist, et servent à deux choses : - **Filtrer la todolist par plateforme** : chaque équipe de test (par exemple une équipe dédiée au mobile) n'affiche que les points qui la concernent (voir [Todolist et verdicts](/captests/todolist-et-verdicts)). - **Décider la mise en production par plateforme** : la page de couverture indique, pour chaque appareil, si la campagne est prête à livrer (voir [Couverture automatique](/captests/couverture-automatique)). Vous pouvez ainsi livrer "zéro bug mobile" même si des points tablette ou desktop restent en échec. ![Formulaire d'un cas avec les cases à cocher des plateformes cibles Mobile, Tablette, Desktop](screenshots/cas-plateformes.webp) > **Aucune case cochée = toutes les plateformes.** Un point sans étiquette est > considéré comme concernant tous les appareils, pour qu'aucun point n'échappe à > un contrôle de mise en production par plateforme. Un point ne porte qu'**un seul verdict**, partagé entre les plateformes qu'il cible. Si un même écran se comporte différemment selon l'appareil (par exemple une mise en page propre au mobile), créez plutôt **un point par plateforme** : le verdict reste alors net pour chacune. ## Discussion sur un point La fiche complète d'un point comporte une zone **Discussion**. N'importe quel membre du projet peut y laisser un commentaire et **répondre** à un commentaire existant, formant un fil de discussion. C'est l'endroit pour qu'un testeur signale un détail, qu'un développeur réponde, ou pour échanger sur le contexte d'une anomalie sans quitter le point concerné. ![Zone de discussion d'un point avec un commentaire et le bouton Répondre](screenshots/cas-discussion.webp) Les commentaires sont conservés tels quels (ils ne sont pas modifiés ni supprimés), ce qui garde une trace fidèle des échanges. L'agent IA d'un développeur peut lui aussi lire le fil et y répondre. ## Modifier un cas Depuis la fiche d'un point, cliquez sur **Modifier** pour changer son intitulé, sa section, ses plateformes cibles, son cycle de vie, son caractère automatisable, son lien d'aide ou ses instructions. La référence, elle, reste inchangée. ## Liens externes et tests automatiques liés La fiche d'un point peut afficher deux blocs complémentaires : - **Liens** : des liens externes typés (documentation, wiki, forum, vidéo, issue ou PR git) qui contextualisent le point. - **Tests automatiques liés** : les tests automatiques déclarés comme couvrant le point, avec leur source (Playwright ou PHPUnit), leur référence et leur niveau (full ou partial). Le bloc Tests automatiques liés, ainsi que les liens de type documentation, wiki, forum ou vidéo, sont alimentés par les développeurs via l'agent IA, l'API ou la CI. Voir [Automatisation](/captests/automatisation). ### Lier une issue ou une PR GitHub / GitLab Les liens vers une **issue** ou une **pull/merge request** se posent directement depuis la fiche du point (rôle développeur ou administrateur). Dans le bloc Liens, choisissez **Issue git** ou **PR git**, puis saisissez : - soit le **numéro** seul (par exemple `123`) : capTests construit l'URL complète à partir du dépôt du projet (champ dépôt renseigné par un administrateur), en reconnaissant automatiquement GitHub ou GitLab ; - soit l'**URL complète** collée depuis votre navigateur, qui fonctionne toujours, même si le projet n'a pas de dépôt configuré. ![Bloc Liens d'un point avec le formulaire pour ajouter une issue ou une PR git par numéro](screenshots/cas-lien-git.webp) Le lien apparaît alors sous forme d'un badge cliquable (par exemple `#123` pour une issue, `!45` pour une merge request GitLab) qui ouvre l'issue ou la PR dans un nouvel onglet. Une croix permet de retirer un lien. Pour ne saisir que le numéro, demandez à un administrateur de renseigner le dépôt du projet (voir [Administration](/captests/administration)). ## Vidéos de test (référence et échec) La fiche d'un point comporte un bloc **Vidéos de test**. Il sert à comparer le comportement attendu et le comportement observé lors d'un échec : - la **vidéo de référence** montre le déroulé attendu quand tout fonctionne. Elle est captée une seule fois par les tests automatiques (voir [Automatisation](/captests/automatisation)), par plateforme le cas échéant ; - une **vidéo d'échec** est publiée quand un test échoue, rattachée à la version concernée. Quand un échec existe, sa vidéo s'affiche **côte à côte** avec la vidéo de référence de la même plateforme : on rejoue les deux séquences pour repérer ce qui diffère. ![Bloc Vidéos de test d'un point avec la vidéo de référence et la vidéo d'échec côte à côte](screenshots/cas-videos.webp) Le **chef de projet** (rôle administrateur) peut supprimer la vidéo de référence depuis ce bloc. C'est utile quand le comportement attendu a légitimement changé : une fois l'ancienne référence supprimée, une nouvelle est recaptée au prochain test qui passe.