Πώς να γράψετε μια αναφορά σφαλμάτων με παραδείγματα

Τι είναι η Αναφορά σφάλματος; Γιατί χρειάζεστε μια καλή αναφορά σφαλμάτων;

Η αναφορά σφαλμάτων είναι ένα σημαντικό έγγραφο στο STLC που προσφέρει διάφορα πλεονεκτήματα στην ομάδα δοκιμών. Παρακολουθεί όλα τα ελαττώματα, πολλά σφάλματα, σφάλματα και άλλες αποκλίσεις που εντοπίστηκαν κατά τη δοκιμή λογισμικού και τα αναφέρει.

Ο σκοπός αυτής της τεκμηρίωσης μετά τη δοκιμή είναι να παρέχει πληροφορίες στην ενδιαφερόμενη ομάδα επαγγελματιών σχετικά με το επίπεδο σφαλμάτων που συναντήθηκαν κατά τη διαδικασία δοκιμών.

Σας μηχανικός ανάπτυξης λογισμικού μπορεί να ενημερωθεί για όλα τα ελαττώματα και τα ζητήματα που υπάρχουν στο λογισμικό χρησιμοποιώντας αυτόν τον τύπο αναφοράς. Σας επιτρέπει επίσης να καταλάβετε τι συμβαίνει με ένα σφάλμα, ώστε να μπορείτε να χρησιμοποιήσετε την καλύτερη μέθοδο για να το διορθώσετε. Σας βοηθά επίσης να εξοικονομήσετε χρόνο και χρήμα βοηθώντας σας να εντοπίσετε σφάλματα και προβλήματα.

Γιατί πρέπει να σας ενδιαφέρουν οι καλές εξηγήσεις σφαλμάτων;

Εδώ είναι το σημείο που πρέπει να λάβετε υπόψη για να γράψετε μια καλή, λεπτομερή αναφορά σφαλμάτων λογισμικού:

• Λειτουργεί ως οδηγός για να αποφύγετε το ίδιο σφάλμα σε μελλοντικές εκδόσεις.
• Εξοικονομήστε χρόνο για επικοινωνία (e-mail, κλήσεις).
• Less εργάζονται για προγραμματιστές (θα κάνουν ακριβώς αυτό που θέλετε).
• Θα έχετε λιγότερα σημεία συμφόρησης στο έργο. τα σφάλματα θα διορθωθούν πιο γρήγορα και πιο αποτελεσματικά.

Πώς να γράψετε αναφορά σφαλμάτων (Πρότυπο αναφοράς σφαλμάτων)

Δεν υπάρχει ακριβές πρότυπο αναφοράς σφαλμάτων, καθώς εξαρτάται από το σύστημα παρακολούθησης σφαλμάτων που διαθέτετε. Το πρότυπό σας μπορεί να είναι διαφορετικό.

Ωστόσο, τα ακόλουθα κοινά πεδία χρειάζονται πάντα όταν θέλετε να γράψετε μια αναφορά σφαλμάτων:

• Αναγνωριστικό σφάλματος/Τίτλος.
• Σοβαρότητα και προτεραιότητα.
• Descriptιόν
• Περιβάλλον
• Βήματα για αναπαραγωγή.
• Αναμενόμενο Αποτέλεσμα.
• Πραγματικό αποτέλεσμα.
• Συνημμένα (στιγμιότυπα οθόνης, βίντεο, κείμενο)

Ας δούμε όλα αυτά τα στοιχεία αντιμετώπισης σφαλμάτων ένα προς ένα:

1) Τίτλος/Αναγνωριστικό σφάλματος:

Σε κάθε σφάλμα θα πρέπει να δίνεται ένας μοναδικός αριθμός αναγνώρισης. Τα εργαλεία αναφοράς σφαλμάτων θα πρέπει να είναι μοναδικοί αριθμοί για τα σφάλματα που παρουσιάστηκαν πρόσφατα, ώστε να μπορούμε να εντοπίσουμε εύκολα το σφάλμα.

Παραδείγματα:

❌ Κακό: "Δεν μπορώ να δω το προϊόν όταν το ξαναδώ, αλλά όχι."

• Ασαφής
• Επιθετικός
• Πολύ φλύαρος

ζητά να δοθεί λύση.

✅ Καλό: “ΚΑΛΑΘΙ – Προστέθηκαν νέα προϊόντα στο καλάθι που δεν εμφανίζονται”.

• Αυτός ο τίτλος εντοπίζει αμέσως το ζήτημα (ΚΑΛΑΘΙ)
• Επικεντρώνεται στο πραγματικό τεχνικό πρόβλημα.

2) Σοβαρότητα σφαλμάτων:

Η σοβαρότητα του σφάλματος είναι ένας πολύ σημαντικός παράγοντας στην αναφορά σφαλμάτων. Περιγράφει την επίδραση του ελαττώματος στην απόδοση της εφαρμογής.

• Αποκλεισμός: Αυτό το σφάλμα προκαλεί την αποτυχία της εφαρμογής.
• Major: Ένα κρίσιμο σφάλμα υποδηλώνει μια σημαντική αλλαγή στην επιχειρηματική λογική.
• Ανήλικος: Ένα ζήτημα που δεν επηρεάζει τη λειτουργικότητα της εφαρμογής αλλά επηρεάζει τα αναμενόμενα αποτελέσματα.
• Ασήμαντος: Δεν επηρεάζει τη λειτουργικότητα ή τη λειτουργία της εφαρμογής. Μπορεί να είναι τυπογραφικό λάθος.

3) Προτεραιότητα σφάλματος:

Ακολουθεί η γενική διαβάθμιση για να αποφασίσετε την προτεραιότητα σφαλμάτων:

• Ψηλά: Καλύπτει οτιδήποτε επηρεάζει τη ροή ή αποκλείει τη χρήση της εφαρμογής.
• Μέσον: Επηρεάζει αρνητικά την εμπειρία του χρήστη.
• Ανήλικος: Όλα τα άλλα σφάλματα όπως (τυπογραφικά λάθη, εικονίδια που λείπουν, προβλήματα διάταξης κ.λπ.).

4) Περιβάλλον:

Ένα σφάλμα μπορεί να εμφανιστεί σε ένα συγκεκριμένο περιβάλλον και όχι σε άλλα. Για παράδειγμα, μερικές φορές εμφανίζεται ένα σφάλμα κατά την εκτέλεση του ιστότοπου Firefox, ή δυσλειτουργία μιας εφαρμογής μόνο όταν εκτελείται σε ένα Android συσκευή και λειτουργεί άψογα στο iPhone.

Αυτές οι αναφορές σφαλμάτων μπορούν να εντοπιστούν μόνο με δοκιμές μεταξύ προγραμμάτων περιήγησης ή μεταξύ συσκευών. Έτσι, κατά την αναφορά του σφάλματος, τα QAs θα πρέπει να είναι σε θέση να καθορίσουν εάν το σφάλμα πρέπει να παρατηρηθεί σε ένα ή περισσότερα συγκεκριμένα περιβάλλοντα.

5) Περίληψη:

Ωστόσο, η προσθήκη μόνο του Τίτλου στην αναφορά σφαλμάτων δεν εξυπηρετεί τον σκοπό. Επομένως, εάν ο τίτλος σας δεν είναι αρκετός, μπορείτε να προσθέσετε μια σύντομη περίληψη αναφοράς.

Η περίληψή σας με όσο το δυνατόν λιγότερες λέξεις, συμπεριλαμβανομένου του πότε και πώς παρουσιάστηκε το σφάλμα. Ο τίτλος και η περιγραφή σφαλμάτων θα πρέπει επίσης να χρησιμοποιούνται στις αναζητήσεις, επομένως πρέπει να βεβαιωθείτε ότι έχετε καλύψει σημαντικές λέξεις-κλειδιά.

Παραδείγματα:

• κακό: «Προσπαθούσα να προσθέσω πράγματα στη δοκιμή και τίποτα δεν εμφανιζόταν όταν το έκανα αυτό ή όταν έκανα κλικ στο κουμπί».
• Καλός: "Όταν προσπάθησα να προσθέσω [ΠΡΟΪΟΝ] στο καλάθι αγορών, αλλά δεν συνέβη τίποτα όταν έκανα κλικ στο κουμπί "προσθήκη" στη συγκεκριμένη ιστοσελίδα επισκόπησης προϊόντος."

6) Βήματα για την αναπαραγωγή:

Όταν αναφέρετε ένα σφάλμα, είναι σημαντικό να καθορίσετε τα βήματα για την αναπαραγωγή του. Θα πρέπει επίσης να συμπεριλάβετε ενέργειες που μπορεί να προκαλέσουν το σφάλμα. Εδώ, μην κάνετε γενικές δηλώσεις.

Να είστε συγκεκριμένοι στα βήματα που πρέπει να ακολουθήσετε:

Εδώ, είναι ένα παράδειγμα καλογραμμένης διαδικασίας:

Βήματα:

1. Επιλέξτε το προϊόν X1.
2. Κάντε κλικ στο Προσθήκη στο καλάθι.
3. Κάντε κλικ στην Κατάργηση για να αφαιρέσετε το προϊόν από το καλάθι.

7) Αναμενόμενο αποτέλεσμα:

Στις αναφορές σφαλμάτων, η περιγραφή του αναμενόμενου αποτελέσματος ανά τεχνική εργασία, σχεδιασμός αποτελεσμάτων περίπτωσης δοκιμής ή σύμφωνα με τη γνώμη του ελεγκτή είναι σημαντική. Όλα αυτά βοηθούν τους προγραμματιστές να επικεντρωθούν στη γρήγορη εύρεση των απαραίτητων πληροφοριών.

Για παράδειγμα:

Τα υποχρεωτικά πεδία θα πρέπει να επισημαίνονται με κόκκινο χρώμα αφού κάνετε κλικ στο κουμπί "Υποβολή".

8) Πραγματικό αποτέλεσμα:

Όπως υποδηλώνει το όνομά του, αυτό το πεδίο s περιγράφει την πραγματική επίδραση του σφάλματος. Είναι πολύ σημαντικό να γράψετε μια σαφή περιγραφή του πραγματικού αποτελέσματος.

Για παράδειγμα:

Τα υποχρεωτικά πεδία επισημαίνονται με πράσινο χρώμα αφού κάνετε κλικ στο κουμπί «Υποβολή».

9) Συνημμένα (στιγμιότυπα οθόνης και βίντεο):

Στις αναφορές σφαλμάτων, είναι βέλτιστη πρακτική να επισυνάπτετε αρχεία σε αναφορές σφαλμάτων, γεγονός που διευκολύνει την αντίληψη πληροφοριών όταν χρειάζεται να τις εμφανίσετε οπτικά:

Για παράδειγμα:

• Screenshot: Τα στιγμιότυπα οθόνης μπορούν εύκολα να επεξεργαστούν λάθη στο πρόγραμμα. είναι βολικό όταν το σφάλμα επισημαίνεται με συγκεκριμένο σχολιασμό, κύκλο ή εικόνα βέλους).
• Βίντεο: Μερικές φορές, είναι δύσκολο να περιγραφεί το σφάλμα με λέξεις, επομένως είναι καλύτερο να δημιουργήσετε ένα βίντεο ώστε ο προγραμματιστής να μπορεί να διορθώσει το ελάττωμα του προγράμματος).

10) Επηρεασμένη έκδοση:

Είναι η επηρεαζόμενη έκδοση λογισμικού όπου αναφέρεται το σφάλμα.

11) Διορθώστε την έκδοση:

Είναι η έκδοση λογισμικού στην οποία επιλύεται το σφάλμα. Έτσι, όταν ο QA που ανέφερε το σφάλμα, ελέγχει αν έχει διορθωθεί, χρησιμοποιεί τη σωστή έκδοση λογισμικού.

12) Target έκδοση:

Η έκδοση προορισμού στην οποία πρέπει να στοχευτεί ένα σφάλμα για να διορθωθεί. Έτσι, όταν η ομάδα ανάπτυξης εργάζεται για τη διόρθωση ενός σφάλματος, στοχεύει κυρίως σε μια συγκεκριμένη έκδοση εφαρμογής.

13) Ημερομηνία κλεισίματος:

Είναι η ημερομηνία κατά την οποία το σφάλμα έχει κλείσει από την ομάδα δοκιμών λογισμικού. Το κλείσιμο ενός σφάλματος είναι ένα ζωτικό και αναπόσπαστο μέρος της δοκιμής λογισμικού.

14) Κατάσταση:

Όταν δημιουργείται ένα νέο σφάλμα, η κατάστασή του θα πρέπει να είναι ανοιχτή. Μετά από αυτό, περνάει από στάδια όπως Σε εξέλιξη, Διορθώθηκε, Εκτέλεση, Εκ νέου άνοιγμα κ.λπ.

Συμβουλές για τη σύνταξη αναφορών σφαλμάτων

Ακολουθούν ορισμένες σημαντικές συμβουλές που πρέπει να θυμάστε κατά τη σύνταξη μιας αποτελεσματικής αναφοράς σφαλμάτων:

• Να είστε συγκεκριμένοι όταν δημιουργείτε αναφορές σφαλμάτων. Βεβαιωθείτε ότι δεν έχετε συμπεριλάβει άχρηστα ή άσχετα γεγονότα.
• Πρέπει να αναφέρετε το σφάλμα αμέσως μόλις εντοπιστεί.
• Προετοιμάστε την αναφορά λεπτομερώς για να εξουσιοδοτήσετε τον προγραμματιστή να χρησιμοποιήσει τα γεγονότα και τις πληροφορίες για τον εντοπισμό σφαλμάτων του ζητήματος.
• Θα πρέπει να δοκιμάσετε την ίδια εμφάνιση σφαλμάτων σε άλλες παρόμοιες λειτουργικές μονάδες για επικύρωση.
• Revδείτε την αναφορά σφαλμάτων τουλάχιστον μία φορά πριν την υποβάλετε.
• Θα πρέπει να βεβαιωθείτε ότι η αναφορά σφαλμάτων περιέχει την περιγραφή μόνο ενός σφάλματος.
• Τέλος, δεν πρέπει να φοβάστε να ζητήσετε βοήθεια από τον Project Manager εάν αισθάνεστε ασαφείς για κάτι.

Εργαλεία αναφοράς σφαλμάτων

Η διαδικασία αναφοράς σφαλμάτων, που εκτελείται με μη αυτόματο τρόπο, εκτελείται τώρα με διάφορα εργαλεία αναφοράς σφαλμάτων που είναι διαθέσιμα στην αγορά.

• ΖΗΡΑ
• Zoho Bug Tracker
• Bugzilla

Μπορείτε να ελέγξετε τη λεπτομερή κριτική μας για το καλύτερο εργαλείο αναφοράς σφαλμάτων.

Συνηθισμένο πρόβλημα και λύση κατά τη σύνταξη αναφοράς σφαλμάτων:

Ακολουθούν ορισμένα κοινά προβλήματα και οι λύσεις τους κατά τη σύνταξη μιας αναφοράς σφαλμάτων:

Παράδειγμα αναφοράς σφαλμάτων	Πρόβλημα
Πολλαπλασιάζοντας το 2 επί 3, η απάντηση θα είναι θετική.	Αναφέρετε το μοτίβο, όχι ένα παράδειγμα.
Η λίστα θα ταξινομηθεί αλφαβητικά κατά την προσθήκη ενός νέου στοιχείου για να αποφευχθεί αυτό.	Μην περιγράφετε μόνο τι φταίει
Για παράδειγμα: Για να γίνει αυτό, θα χρειαστεί να ανοίξετε το πρόγραμμα περιήγησής σας και να πληκτρολογήσετε τη διεύθυνση URL του ιστότοπου. Θα βρείτε το πρώτο πεδίο, "όνομα χρήστη", ανορθόγραφο.	Πάντα κατευθείαν στο σημείο (Μην πεις ποτέ την ιστορία!).
Το όνομα του πελάτη στην αναφορά είναι ανορθόγραφο. Προτεραιότητα: Υψηλή, Σοβαρότητα: Υψηλή	Ποτέ μην ανακατεύετε προτεραιότητα και σοβαρότητα.
Ο τύπος υπολογισμού φόρου είναι ΛΑΘΟΣ !!??	Δεν χρησιμοποιεί ΚΕΦΑΛΑΙΑ, κόκκινα γράμματα, κόκκινους κύκλους, '!',
Δεν νομίζω ότι η αρχική σελίδα Ul design είναι καλή.	Μην χρησιμοποιείτε την κρίση σας.
Παράδειγμα ασαφούς περιγραφής: Σχετικά με τη σημερινή μας συζήτηση, κάντε την απαιτούμενη ενέργεια για αυτήν τη σελίδα.	Κάντε την περιγραφή σας κατανοητή σε όλους.
Το φόντο της σελίδας πρέπει να είναι μπλε, πορτοκαλί ή πράσινο ή μπορείτε να το κάνετε μαύρο ή λευκό. Αυτό δεν είναι καλό, καθώς δεν είναι σαφές τι χρειάζεται από την ομάδα ανάπτυξης και σχεδίασης ιστού	Ελαχιστοποιήστε τις επιλογές
Ο τύπος υπολογισμού φόρου μερικές φορές δεν λειτουργεί όπως αναμένεται.	Ο χρυσός κανόνας: Μη χρησιμοποιείτε τη λέξη «Μερικές φορές».

Παράδειγμα αναφοράς σφαλμάτων

Ακολουθεί ένα μικρό παράδειγμα αναφοράς σφαλμάτων:

[Ο ΛΟΓΑΡΙΑΣΜΟΣ ΜΟΥ] Εμφανίζεται η υπογράμμιση όταν το ποντίκι κάνει υπέρβαση στο κουμπί Ενημέρωση.

Descriptιόν: Πρέπει να αφαιρέσουμε την υπογράμμιση όταν το ποντίκι υπερβαίνει το κουμπί Ενημέρωση στην ενότητα Ο λογαριασμός μου.

Σύνδεσμος: http://test.com/mv-account/

Browser/OS: Chrome 25. OSX Yosemite 10.10.2

Βήματα για αναπαραγωγή:

1. Μεταβείτε στη διεύθυνση www.test.com

2. Είσοδος μέσω διαπιστευτηρίων σύνδεσης

3. Μεταβείτε στο My Account

4. Τοποθετήστε το ποντίκι στο κουμπί Ενημέρωση

Πραγματικό αποτέλεσμα: υπάρχει μια υπογράμμιση.

Αναμενόμενο Αποτέλεσμα: χωρίς υπογράμμιση.

Δεδομένα σύνδεσης: test@test.com / mysecretpass12

Πρέπει να αποφεύγονται λάθη στη σύνταξη αναφοράς σφαλμάτων

Ακολουθούν ορισμένα σημαντικά λάθη που πρέπει να αποφύγετε κατά τη σύνταξη μιας αναφοράς σφαλμάτων:

• Μην γράφετε για τη δυσαρέσκειά σας και μην συμπεριλάβετε ποτέ τα προσωπικά σας συναισθήματα.
• Ενοχλεί τους ανθρώπους που θέλουν να επικεντρωθούν στην εργασία όταν υπερφορτώνετε τη δημοσίευσή σας με πολλά emoticon.
• Ποτέ μην υπερφορτώνετε την ανάρτησή σας με θαυμαστικά. δεν επιταχύνει την εργασία.
• Κανείς δεν θέλει να νιώθει προσβεβλημένος. Καταστρέφει τα κίνητρα και επιβραδύνει την συνειδητοποίηση του ζητήματος.