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).

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 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

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). 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).
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). 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

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

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.

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

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).

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), 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

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.