Une checklist QA qui reste attachée au ticket Jira

Qu’est-ce qu’une checklist de tests QA ?

Une checklist QA transforme le parcours de test en étapes à cocher directement sur le ticket : préparation de l’environnement, couverture fonctionnelle, cas limites, navigateurs, contrôles de sécurité et validation finale. La structure reste la même pour chaque bug ou story ; seules les cases cochées et les preuves changent.

Ce parcours complète les critères d’acceptation : leurs lignes décrivent le comportement attendu, tandis que la checklist QA consigne la manière dont vous l’avez vérifié. La Definition of Done peut imposer que cette checklist soit terminée avant la livraison de la story.

Pourquoi garder les tests QA sur le ticket

Un parcours de test stocké dans une feuille de calcul, une page Confluence ou un fil Slack se perd facilement lorsque quelqu’un reprend le ticket. Une checklist sur le ticket conserve la préparation, la couverture et les preuves là où le travail avance déjà : les testeurs attribuent aux éléments des statuts comme In Progress et Blocked, mentionnent le responsable d’une ligne bloquée et visualisent le reste à faire sur le tableau.

Le même parcours convient à la vérification d’un correctif comme d’une story : vous ouvrez le ticket, voyez ce qu’il reste, joignez des captures d’écran ou des logs en cas d’échec et consignez le résultat. Conservez les contrôles de sécurité et de plateforme pour les changements à risque ; allégez-les pour une simple modification de texte.

Quand l’utiliser

Utilisez une checklist QA pour les bugs, les stories qui nécessitent un parcours structuré avant Done, ou dès que le statut passe à Ready for test. Appliquez-la automatiquement aux tickets de type Bug ou lors de ce changement de statut, afin que les testeurs disposent toujours du même cadre. Allégez la liste pour les changements à faible risque ; conservez les contrôles de sécurité et de régression dès que l’authentification, les paiements ou un parcours partagé sont concernés.

Tests QA, critères d’acceptation et Definition of Done

Les critères d’acceptation décrivent ce que la story doit fournir : les exemples que vous présenterez. La checklist QA explique comment vous les vérifiez, avec les données, navigateurs, régressions et observations nécessaires. La Definition of Done constitue le seuil de sortie commun à toutes les stories : tests, revue et préparation à la mise en production. Gardez ces trois checklists séparées sur le ticket pour distinguer le comportement attendu, le parcours de test et la qualité de livraison.

Tests QA : un exemple pour démarrer

Pour créer votre première checklist QA, partez de l’exemple ci-dessous. Copiez la liste, puis collez-la dans le champ Checklist for Jira d’un bug ou d’une story. Enregistrez-la idéalement comme modèle et appliquez-la automatiquement à la création d’un Bug ou au passage à Ready for test : les testeurs retrouvent ainsi un cadre cohérent et les mêmes rubriques à chaque fois. Supprimez les lignes inutiles et ajoutez celles qu’exige votre processus.

Ce cadre a sa place sur chaque bug et sur les stories qui exigent un parcours structuré. Dans Checklist for Jira, vous ajoutez ou cochez les éléments dans le panneau du ticket, enregistrez les rubriques comme modèle de projet ou modèle global, puis l’appliquez automatiquement à la création d’un Bug ou au passage à Ready for test. Vous pouvez aussi l’ajouter manuellement via Add → Add from template dès que nécessaire.

Enregistrez un modèle, automatisez le parcours

1. Checklist for Jira ajoute un panneau de checklist à la vue du ticket. Collez l’exemple ci-dessus dans un bug ou une story, adaptez les lignes à votre processus, puis enregistrez la structure comme modèle de projet ou modèle global dans Checklist settings.
2. Marquez le modèle comme Protected si vous souhaitez verrouiller la liste des étapes pendant que les testeurs cochent les éléments et leur attribuent des statuts comme In Progress et Blocked.
3. Utilisez l’automatisation propre au modèle pour joindre la checklist QA lors de la création d’un Bug ou du passage à Ready for test. Ces automatisations sont intégrées à Checklist for Jira et ne consomment aucun crédit Jira Automation.
4. Si votre équipe souhaite un contrôle avant Done, ajoutez un validateur de complétion à cette transition et limitez-le à ce modèle : le ticket restera ouvert tant que le parcours ne sera pas terminé.
5. Associez-la aux critères d’acceptation pour les exemples à vérifier, à la Definition of Done pour le seuil final et à la checklist de mise en production lorsque le changement est prêt à être livré. Consultez également le guide d’automatisation.

Associez-la aux autres checklists de livraison

Gardez les critères d’acceptation sur le même ticket pour rappeler le comportement attendu. Ajoutez la Definition of Done dès l’entrée dans le sprint afin que le seuil de livraison soit visible dès le premier jour. Utilisez la Definition of Ready pendant l’affinage si votre équipe souhaite mieux cadrer les demandes. Poursuivez avec la checklist de mise en production lorsque le changement est prêt à partir en production. Parcourez le catalogue de modèles pour découvrir l’ensemble des modèles.

Questions fréquentes