Software Testing - Comment identifiez-vous un bogue (défaut)

Agrandir l'image

Comme test logiciel améliore la qualité des logiciels et fournit une solution rentable qui répond aux exigences des clients, il devient nécessaire de se connecter un défaut d'une manière appropriée, suivre le défaut, et tenir un journal des défauts pour référence future, etc

En tant que testeur teste une application et si il / elle trouve un défaut, le cycle de vie du défaut démarre et il devient très important de communiquer le défaut aux développeurs de le faire réparer, faire le suivi de la situation actuelle du défaut, savoir si un tel défaut (défaut similaire) n'a jamais été trouvée dans les tentatives derniers essais, etc A cet effet, les documents créés précédemment manuelles ont été utilisés, qui ont été distribués à toutes les personnes associées au projet logiciel (développeurs et testeurs). De nos jours, de nombreux outils de reporting de bugs sont disponibles, ce qui aidera dans le suivi et la gestion des bugs de manière efficace.

Comment signaler un bug?

C'est une bonne habitude à prendre des captures d'écran d'exécution à chaque étape de tests de logiciels. Si un cas de test échoue lors de l'exécution, il n'a pas besoin d'être dans l'outil de rapport de bogues et d'un bug doit être signalé / connecté pour la même chose. Le testeur peut choisir tout d'abord signaler un bug et ensuite ne pas le cas de test dans l'outil de rapport de bug ou d'échec d'un cas de test et rapporter un bug. Dans tous les cas, l'ID de bogue qui est généré pour le bogue signalé doit être fixé au cas de test qui a échoué.

Au moment de rapporter un bug, tous les champs obligatoires à partir du contenu de bug (comme le projet, Sommaire, Description, Status, détectées par Assignée à ce jour détecté, Test Lead,, détecté dans la version, fermé dans la version, la date prévue de la fermeture, la date effective de fermeture, gravité, priorité et Bug ID, etc) sont remplis et la description détaillée du bogue est donné avec les résultats attendus et obtenus. Les captures d'écran, prises au moment de l'exécution de cas de test, sont attachés à la bogue pour référence par le développeur.

Après avoir signalé un bug, un ID de bogue unique est généré par l'outil de rapport de bogues, qui est ensuite associée avec le cas test a échoué. Ce ID de bug permet à associer le bogue avec le cas de test a échoué.

Après le bug est signalé, il se voit attribuer un statut de «nouveau», qui continue à changer à mesure que progresse processus de bug de fixation.

Si plus d'un testeur teste le logiciel, il est possible que certains autre testeur peut-être déjà signalé un bug pour le même défaut dans l'application. Dans une telle situation, il devient très important pour le testeur pour savoir si un bug a été signalé pour un même type de défaut. Si oui, alors le cas de test doit être bloquée avec le bug déjà soulevé (dans ce cas, le test doit être exécuté une fois le bug est corrigé). Et s'il n'y a pas de bug comme indiqué précédemment, le testeur peut signaler un nouveau bogue et d'échouer au test pour le virus nouvellement posée.

Si aucun outil de rapport de bug est utilisé, alors dans ce cas, le test est écrit d'une manière tableau dans un fichier avec quatre colonnes contenant Step Test Aucun résultat Description Step Test, Résultat attendu et réel. Les résultats attendus et réels sont écrites pour chaque étape et le cas test est effectué à l'échec de l'étape au cours de laquelle le cas de test échoue.

Ce fichier contient les cas de test et des captures d'écran prises sont envoyées aux développeurs pour référence. Alors que le processus de suivi n'est pas automatisé, il devient important de garder l'information à jour sur le bug qui a été soulevé jusqu'à ce que le moment où elle est fermée.

(S'il vous plaît Note: La procédure ci-dessus pour rapporter un bogue est d'ordre général et ne repose sur aucun projet particulier plupart du temps, les procédures de signalement de bogues, les valeurs utilisées pour les différents champs utilisés au moment de la déclaration d'un système de suivi des bogues et de bug,. etc, susceptibles d'être modifiées par le projet de tests de logiciels et besoins de l'entreprise.)...