Étapes pour maintenir une bonne base de données de bogues

La maintenance de la base de données de bogues est un élément important pour chaque projet. Je suis habitué à stocker les éléments suivants dans la base de données de bogues

• Date d'émission heure
• Qui est affecté à
• Qu'il ait été résolu ou non
• Si résolu alors, date et heure résolues

Est-ce suffisant pour maintenir une bonne base de données de bogues?

Une bonne base de données de bogues peut avoir les éléments suivants

// Date et heure

• Date de sortie heure du bogue
• Date / heure de correction / résolution attendue
• Si résolu alors, date et heure résolues

// Attribué par + à

• Attribué par (détecté par)
• Assigné à

// Comportement de bogue

• Comportement observé (buggy)
• Capture d'écran (possible)
• Étapes complètes pour reproduire le bogue
• Comportement attendu

// Priorité

• Priorité du bug

// Lien, statut et autres

• Lien des bogues associés
• Statut du bug
• Qu'il ait été résolu ou non
• Si résolu alors, comment résolu avec explication

EDIT: je veux aussi recommander

• Dans quelle révision / branche le bug a-t-il été découvert
• Dans quelle révision / branche le bug a-t-il été corrigé

EDIT: J'aime le commentaire de @ jgauffin

• Ne sera pas corrigé, pas un bug, dupliqué, résolu

EDIT: Un bon système de base de données de bogues maintient également

• Matrice d'attribution des responsabilités

Il peut y avoir un certain nombre de champs personnalisés que vous devrez peut-être enregistrer, selon les besoins du projet. J'ai trouvé la liste suivante que vous devrez peut-être également prendre en considération:

• Problème DateTimede bug / défaut
• Description du bug - étapes pour recréer.
• Environnement où il a été trouvé (Dev, QA, QC, Staging, Prod)
• Capture d'écran du problème
• Qui l'a connecté (détecté par)
• À qui est-il attribué (attribué par)
• Gravité du bug (faible, moyenne, élevée)
• Résolution attendue DateTime
• Triage d'État (proposé, en cours, résolu, fermé)
• Le bogue est fermé DateTime- lorsqu'un bogue est résolu et fermé
• Attribué pour être testé (testé par)

Edit: La plupart des informations courantes qui ont une valeur à suivre sont bien décrites dans des logiciels comme Bugzilla . Bugzilla est un outil de suivi de bogues et de test à usage général basé sur le Web, développé et utilisé à l'origine par le projet Mozilla et sous licence sous la licence publique de Mozilla. Il est GRATUIT . Je conseillerais fortement de les prendre comme exemple principal et de l'étendre en fonction des besoins de votre projet.

La plupart des champs utiles semblent avoir déjà été couverts par d'autres réponses, mais certains que je trouve utiles sont:

• Dans quelle révision / branche le bug a-t-il été découvert.
• Dans quelle révision / branche a-t-il été corrigé.

C'est un peu plus précis qu'à quelle date / heure le bug a été découvert / corrigé.

Si votre logiciel fonctionne sur plusieurs plates-formes (OS ou matériel), vous souhaiterez peut-être également un champ répertoriant les plates-formes sur lesquelles le bogue se produit.

Mais la maintenance d'une base de données de bogues ne se limite pas aux champs qu'elle doit contenir. Vous devez également réfléchir à la façon dont vous utilisez la base.

Essayez de limiter au maximum le nombre de bogues ouverts / non résolus. Cela peut sembler évident, mais peut être plus difficile que prévu, du moins pour les grands projets. Je vois souvent des gens trop effrayés pour clore des problèmes qui ne sont pas reproductibles ou où le manque d'informations n'est jamais fourni par le demandeur d'origine du problème. De plus, les bogues qui traînent depuis toujours et qui ont été vus pour la dernière fois dans des versions anciennes du logiciel ne doivent pas rester. Cela fait évoluer la base de données avec des problèmes qui peuvent être réels ou non, et ralentit le développement.

Vous auriez souvent besoin de voir l'historique d'un bogue _ il peut être résolu, puis rouvert, puis résolu à nouveau, etc. Donc, en plus de ce qui a déjà été suggéré, je vous conseillerais d'avoir une table séparée pour garder une trace de l'historique d'un bug à chaque (ré) ouverture. La table serait en relation plusieurs à une avec la table des bogues et aurait probablement des champs comme:

• Date d'ouverture
• Ouvert par
• Date de résolution
• Résolu par
• Temps passé
• Comment a été résolu
• etc.

Vous pouvez également avoir besoin d'une table similaire pour suivre à qui et quand le bug a été (ré) attribué, surtout si vous travaillez dans une grande équipe.

Je vous suggère également de jeter un œil aux systèmes existants. IMHO Jira est l'un des meilleurs systèmes de suivi des problèmes. Il a des fonctionnalités très riches, et vous pouvez en utiliser certaines comme guide pour votre propre système.

Le processus de suivi des bogues est tout aussi important que les données. Essayez également de penser aux éléments suivants:

• Comment les utilisateurs signalent-ils le bogue?
• Qui entre le bogue dans le référentiel?
• Qui peut confirmer que le bogue existe?
• Qui peut confirmer que le bogue est résolu?
• Qui informe l'utilisateur final que le bogue est résolu?

Construisez un graphique RACI pour que chaque membre de votre équipe (y compris les utilisateurs finaux connaisse leurs responsabilités. Combinez cela avec des techniques de saisie de données appropriées et vous verrez beaucoup plus de valeur avec le petit effort supplémentaire.