Générateur de tickets de bug Jira

Écrivez un résumé qui nomme la zone et le symptôme, comme « Checkout : Passer la commande reste désactivé après un code promo ». Dans la description, indiquez l’environnement, les étapes de reproduction numérotées, le résultat attendu, le résultat obtenu et des preuves comme des captures d’écran, des logs ou un fichier HAR. Renseignez la sévérité, la priorité, le composant et la version affectée, et liez la story concernée. Un seul bug par ticket. Ce générateur vous donne cette structure et la met en forme en Markdown ou en wiki markup Jira.

Un rapport de bug complet a un titre précis ; l’environnement (build ou version, navigateur, OS, appareil, compte de test) ; les préconditions ; les étapes de reproduction numérotées ; le résultat attendu ; le résultat obtenu ; la sévérité et la priorité ; et des pièces jointes comme des captures, une vidéo, des logs console ou des réponses d’API. Ajoutez la fréquence de reproduction et un éventuel contournement. L’objectif : qu’un développeur puisse reproduire le bug sans vous poser de question. Voir rédiger un rapport de bug qui sera corrigé.

La sévérité mesure l’impact d’un bug sur le système ; la priorité mesure l’urgence avec laquelle le métier veut le voir corrigé. Elles vont généralement de pair, mais pas toujours. Un crash dans un rapport d’administration rarement utilisé est de sévérité haute mais de priorité basse, tandis qu’un nom d’entreprise mal orthographié sur la page d’accueil est de sévérité basse mais de priorité haute. Les testeurs proposent généralement la sévérité et les product owners fixent la priorité. Utilisez le guide de sévérité et priorité des bugs pour classer de façon cohérente.

Partez d’un état connu, comme déconnecté, un compte neuf ou une URL précise, et écrivez chaque action comme une étape numérotée avec des données exactes : « 3. Saisir SAVE10 dans Code promo et cliquer sur Appliquer. » N’incluez que les étapes nécessaires pour déclencher le bug, et suivez-les une fois de plus avant de créer le ticket. Si le bug est intermittent, notez le taux de reproduction, par exemple 3 tentatives sur 5. Placez le résultat attendu et le résultat obtenu après les étapes, pas dedans.

En pratique, c’est la même chose, et le glossaire ISTQB traite « bug » comme synonyme de « défaut » : une imperfection dans un produit d’activité, comme du code ou une exigence, qui fait qu’il ne répond pas à ses exigences. Certaines équipes parlent de « bug » pour ce qui est trouvé en test et de « défaut » après la mise en production, mais c’est une convention locale. Termes associés : une erreur est la méprise humaine qui provoque un défaut, et une défaillance est ce que voient les utilisateurs quand le défaut se déclenche.

En partie. Ce générateur transforme vos notes en un ticket structuré de façon cohérente, formaté pour Jira Cloud (Markdown) ou Jira Server et Data Center (wiki markup), que vous collez vous-même dans Jira. Il ne crée pas le ticket, car SDETRole n’a pas accès à votre instance Jira. Une création entièrement automatique nécessite l’API REST de Jira ou une intégration, par exemple un job de CI qui ouvre un ticket quand un test nocturne échoue. Relisez les tickets créés automatiquement pour éviter les doublons.

Soyez factuel, précis et neutre. Utilisez un titre précis, des étapes reproductibles avec des données réelles, le comportement attendu face au comportement obtenu, et des preuves. Évitez de désigner un coupable (« le développeur a cassé la connexion ») et les opinions ; décrivez le comportement observé et son impact sur les utilisateurs. Gardez une mise en forme cohérente pour accélérer le triage, et joignez les logs plutôt que d’en coller des milliers de lignes. Le générateur de rapports de bug et ce générateur de tickets Jira appliquent tous deux un modèle professionnel avec une checklist de complétude.

Le Markdown. L’éditeur actuel de Jira Cloud convertit les titres, listes et blocs de code Markdown collés. Le wiki markup est destiné à Jira Server/Data Center, et aux champs ou applications Cloud qui utilisent encore l’ancien moteur de rendu.

Dans le wiki markup Jira, { ouvre une macro et [ ouvre un lien : un extrait JSON comme {"error": [1]} dans du texte normal peut casser le rendu. Le générateur les échappe avec une barre oblique inverse. Le texte des blocs {noformat} ou {code} est laissé exactement tel que vous l’avez collé.