Software Testing - Contenu d'un bug

Agrandir l'image

Quand un testeur détecte une erreur, il / elle doit signaler un bug et entrer dans certains domaines, ce qui aide à identifier de manière unique le bogue signalé par le testeur. Le contenu d'un bogue sont comme ci-dessous:

Projet: Nom du projet en vertu de laquelle le test est effectué.

Sujet: Description du bug en somme qui aidera à identifier le bug. Cela commence généralement par le numéro d'identification de projet / string. Cette chaîne doit être suffisamment clair afin d'aider le lecteur à anticiper le problème / défaut pour lequel l'anomalie a été signalée.

Description: Description détaillée du bug. Cela comprend généralement les étapes qui sont impliqués dans le cas de test et les résultats réels. A la fin de la synthèse, l'étape au cours de laquelle le cas est décrit test échoue avec le résultat effectivement obtenu et le résultat attendu.

Résumé: Ce champ contient des informations clé sur le bug, ce qui peut aider à réduire au minimum le nombre d'enregistrements à rechercher.

Détectée par: Nom du testeur qui a détecté / rapporté le bogue.

Assigné à: Nom du développeur qui est censé corriger le bogue. En général, ce champ contient le nom du développeur chef de groupe, qui délègue alors la tâche à un membre de son équipe, et modifie le nom en conséquence.

Test Lead: Nom du chef d'équipe de test, sous la direction duquel le testeur signale le bug.

Détectée dans la version: Ce champ contient les informations de version de l'application logicielle dans laquelle le bogue a été détecté.

Fermé dans la version: Ce champ contient les informations de version de l'application logicielle dans laquelle le bug a été corrigé.

Date de Detected: Date à laquelle le bogue a été détecté et signalé.

Date prévue de fermeture: date à laquelle le bogue devrait être fermé. Cela dépend de la gravité du bogue.

Date réelle de fermeture: Comme son nom l'indique, la date effective de clôture de la date soit de bug à laquelle le bug a été corrigé et re-testés avec succès.

Priorité: La priorité de la correction de bugs. Cela dépend spécifiquement sur les fonctionnalités qu'il est gênant. En général Moyen, Bas, Haut, Urgent sont le type de gravité qui sont utilisés.

Gravité: Il s'agit généralement d'un champ numérique qui affiche la gravité du bogue. Il peut varier de 1 à 5, où 1 est la gravité élevé et 5 le plus bas.

Statut: Ce champ affiche l'état actuel du bogue. Un état de New est automatiquement assigné à un bug quand il est temps d'abord rapporté par le testeur, encore le statut est changé en assigné, Ouvrir, Retest, attendant Retest, attente Rejeter, Rejeté, fermé, reportée, etc reporté en par les progrès du processus de correction de bugs.

ID de bogue: Il s'agit d'un numéro d'identification unique soit créé pour le bug au moment de la déclaration, qui identifie de manière unique le bug.

Pièce jointe: Parfois, il est nécessaire de fixer captures d'écran de la fonctionnalité testée qui peut aider à expliquer le testeur de tests qu'il avait fait et il permet également aux développeurs de recréer les conditions des essais similaires.

Boîtier Échec du test: Ce champ contient le cas de test qui a échoué pour le bug.

L'un des champs ci-dessus indiquées peuvent être rendues obligatoires, dans lequel le testeur doit entrer des données valides au moment de rapporter un bug. Rendre un champ obligatoire ou facultative dépend des besoins de l'entreprise et peut avoir lieu à n'importe quel moment dans un projet de tests de logiciels.

(S'il vous plaît Note: Tous les contenus sont enrôlés ci-dessus sont en général présents pour tout bug signalé dans un outil de rapport de bogue Dans certains cas (pour les rapports personnalisés bug-outils) le nombre de champs et leur signification peut changer selon les besoins de l'entreprise.. )...