Μενού

Η τέχνη της αναφοράς σφαλμάτων: Πώς να αγοράσετε και να διορθώσετε τα σφάλματα σας;

art bug reporting

Δοκιμάστε Το Όργανο Μας Για Την Εξάλειψη Των Προβλημάτων

Γιατί υπάρχει ανάγκη μάρκετινγκ ενός σφάλματος;

Τα πρώτα πράγματα που έρχονται στο μυαλό μου καθώς αρχίζω να γράφω αυτό το άρθρο είναι τα λόγια του Cem Kaner - «Ο καλύτερος υπεύθυνος δοκιμών δεν είναι αυτός που βρίσκει τα περισσότερα σφάλματα ή που ντροπιάζει τους περισσότερους προγραμματιστές. Ο καλύτερος ελεγκτής είναι αυτός που διορθώνει τα περισσότερα σφάλματα. '

Τώρα - Ποια είναι η διαφορά μεταξύ εύρεση περισσότερων σφαλμάτων και να διορθώσετε τα περισσότερα σφάλματα ;

Δεν είναι προφανές ότι οποιοδήποτε σφάλμα έχει συνδεθεί σε ένα σύστημα διαχείρισης σφαλμάτων πρέπει να διορθωθεί από τον προγραμματιστή; Η απάντηση είναι Όχι. Παράγοντες όπως ο χρόνος αγοράς του προϊόντος, ο χρόνος ολοκλήρωσης του έργου σύμφωνα με το πρόγραμμα και οι προγραμματιστές που εργάζονται τα πρακτικά αυστηρά προγράμματα κ.λπ. αναγκάζουν τις εταιρείες να κυκλοφορήσουν το προϊόν με λίγα σφάλματα που δεν θα επηρεάσουν σε μεγάλο βαθμό τους χρήστες.

Τέχνη αναφοράς σφαλμάτων

(εικόνα πηγή )

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

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

Σκεφτείτε το σαν διαφήμιση ή μάρκετινγκ του ζητήματος - αυτό περιλαμβάνει 2 βήματα:

  1. Γράψτε ή αναφέρετε σωστά τα σφάλματα
  2. Γνωρίστε τα πάντα για το σφάλμα, οπότε τυχόν περαιτέρω λεπτομέρειες μπορούν να εξηγηθούν καλύτερα

Τι θα μάθετε:

Η τέχνη της αναφοράς σφαλμάτων

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

Συνήθως, ένα σφάλμα πρέπει να περιέχει τις ακόλουθες πληροφορίες:

  • Περίληψη σφαλμάτων
  • βήματα για αναπαραγωγή
  • Συνημμένα (Στιγμιότυπο, αρχεία καταγραφής κ.λπ.)
  • Αναπαραγωγικότητα σφαλμάτων
  • Σοβαρότητα σφαλμάτων
  • Έκδοση λογισμικού, Πληροφορίες περιβάλλοντος
  • Άλλες πληροφορίες που βασίζονται σε οργανωτικές απαιτήσεις.

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

  1. Τα διαπιστευτήρια σύνδεσης δεν έχουν επικυρωθεί καθόλου
  2. Προβλήματα χρονικού ορίου δικτύου σε περίπτωση απομακρυσμένων συνδέσεων
  3. Το σύστημα μπορεί να θεωρήσει όλα τα CAPS ως μη CAPS.

Έτσι, ως Tester θα πρέπει να μπορείτε να αποκρυπτογραφήσετε τις διαφορές ακολουθώντας τις συνοπτικές δηλώσεις σφαλμάτων:

  • 'Δεν είναι δυνατή η σύνδεση με το σωστό όνομα χρήστη και κωδικό πρόσβασης'
  • 'Δεν είναι δυνατή η σύνδεση με το σωστό όνομα χρήστη και κωδικό πρόσβασης, όταν το όνομα χρήστη ή ο κωδικός πρόσβασης περιέχει ένα συνδυασμό αλφαβήτων CAPS και εκτός CAPS.'

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

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

# 1. Περίληψη σφαλμάτων

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

Παράδειγμα :

Εκτός από τη θεωρία, θα προσπαθήσω να εξηγήσω με παραδείγματα.

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

διαφορά μεταξύ αριστερού συνδέσμου και αριστερού εξωτερικού συνδέσμου

' Ο νέος χρήστης δεν μπορεί να συνδεθεί '

'Η σύνδεση χρήστη δεν λειτουργεί όπως αναμένεται'

'Ο χρήστης δεν μπορεί να συνδεθεί με σωστό κωδικό πρόσβασης'

σύνοψη σφαλμάτων λάθος και σωστά

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

Εξετάστε την ακόλουθη δήλωση:

'Ο νέος χρήστης δεν μπορεί να συνδεθεί με τον προεπιλεγμένο κωδικό πρόσβασης που παρέχεται μέσω e-mail ή SMS'

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

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

# 2. Βήματα για την αναπαραγωγή και τα συνημμένα

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

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

Παράδειγμα :

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

  1. Δημιουργήστε έναν νέο χρήστη χρησιμοποιώντας την επιλογή Εγγραφή στην αρχική σελίδα. (Δείγμα ονόματος χρήστη: HelloUser)
  2. Θα λάβετε ένα e-mail και ένα SMS με έναν προεπιλεγμένο κωδικό πρόσβασης. Το αναγνωριστικό e-mail και ο αριθμός κινητού για SMS παρέχονται κατά τη δημιουργία του χρήστη στο Βήμα # 1. (Δείγμα ηλεκτρονικού ταχυδρομείου: HelloUser@hello.com , Αριθμός κινητού δείγματος: 444-222-1123)
  3. Επιλέξτε την επιλογή Σύνδεση στην αρχική σελίδα.
  4. Στο πεδίο κειμένου ονόματος χρήστη, καταχωρίστε το δείγμα ονόματος χρήστη που παρέχεται στο Βήμα # 1.
  5. Στο πεδίο κωδικού πρόσβασης, καταχωρίστε τον προεπιλεγμένο κωδικό πρόσβασης που λαμβάνετε μέσω e-mail ή SMS.
  6. Κάντε κλικ στο κουμπί Είσοδος
  7. Αναμενόμενο Αποτέλεσμα: Ο χρήστης θα πρέπει να μπορεί να συνδεθεί με το παρεχόμενο όνομα χρήστη και τον κωδικό πρόσβασης και να μεταβεί στη σελίδα λογαριασμού χρήστη.
  8. Πραγματικό αποτέλεσμα: Εμφανίζεται το μήνυμα 'Μη έγκυρο όνομα χρήστη / κωδικός πρόσβασης'.

βήματα αναφοράς ελαττωμάτων

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

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

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

# 3. Αναπαραγωγιμότητα σφαλμάτων

Ένα ζήτημα που είναι μεγάλο ή μικρό θα έχει προτεραιότητα βάσει της αναπαραγωγιμότητας. Μπορεί να φανεί πάντα, μερικές φορές, σπάνια ή ακόμη και μία φορά. Ένα ζήτημα που αναπαράγεται ως 'πάντα' θα έχει προτεραιότητα υψηλότερο από το υπόλοιπο.

δεν μπορεί να αναπαραγάγει ένα ελάττωμα

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

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

# 4. Σοβαρότητα σφαλμάτων

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

Τα παρακάτω είναι οι διαφορετικές κατηγορίες σοβαρότητας. Λάβετε υπόψη ότι πρόκειται για γενικά δείγματα και διαφέρει από εταιρεία σε εταιρεία.

  1. Severity 1 - Show Stopper - για σφάλματα που είναι καταστροφικά, χωρίς να διορθωθούν, ο χρήστης δεν θα μπορεί να συνεχίσει να χρησιμοποιεί το λογισμικό και δεν υπάρχει πιθανή λύση
  2. Severity 2 - High - για σφάλματα παρόμοια με το Severity 1, αλλά υπάρχει μια λύση
  3. Σοβαρότητα 3 - Μεσαίο
  4. Σοβαρότητα 4 - Χαμηλή
  5. Σοβαρότητα 5 - ασήμαντο.

Για παράδειγμα, ας συγκρίνουμε δύο παρόμοια ζητήματα.

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

Υποθέτοντας ένα παρόμοιο ζήτημα στον τραπεζικό τομέα: Εάν το υπόλοιπο του λογαριασμού σας εμφανίζεται ως 100 $, αντί για 100,20 $, φανταστείτε τον αντίκτυπο του προβλήματος. Αυτό πρέπει να είναι ένα ελάττωμα σοβαρότητας -1. Όπως μπορείτε να δείτε και στις δύο περιπτώσεις, το ζήτημα είναι πολύ παρόμοιο με το περιβάλλον χρήστη δεν εμφανίζει τα ψηφία μετά το δεκαδικό σημείο. Όμως, ο αντίκτυπος ποικίλλει ανάλογα με τον σχετικό τομέα.

Αποτελεσματική συμμετοχή σε συναντήσεις ελέγχου έκδοσης λογισμικού

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

Η διαδικασία κατά τη διάρκεια τέτοιων συναντήσεων έχει ως εξής:

  1. Ερώτηση της λίστας σφαλμάτων από το σύστημα διαχείρισης σφαλμάτων ανάλογα με τη σοβαρότητα.
  2. Κοιτάξτε τη σύνοψη και συζητήστε την επίδραση του σφάλματος στην εμπειρία του χρήστη στη χρήση ενός προϊόντος λογισμικού.
  3. Με βάση την εκτίμηση κινδύνου και αντίκτυπου, ορίστε την προτεραιότητα και εκχωρήστε το σφάλμα σε έναν κατάλληλο προγραμματιστή για να το διορθώσετε.

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

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

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

Επιπτώσεις της μη σωστής εμπορίας ενός σφάλματος

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

  • Λανθασμένη προτεραιότητα ελαττώματος
  • Καθυστέρηση στην επίλυση των σημαντικών ζητημάτων
  • Απελευθέρωση προϊόντος με σοβαρά ελαττώματα
  • Αρνητικά σχόλια πελατών
  • Υποτιμώντας την αξία της επωνυμίας

Επιπτώσεις της μη σωστής εμπορίας ενός σφάλματος

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

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

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

συμπέρασμα

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

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

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

Δεν είναι πολύ αργά τώρα! Ας προχωρήσουμε και διορθώστε τα σφάλματα αμέσως!

μεγάλα δεδομένα ως εταιρείες παροχής υπηρεσιών

Συνιστώμενη ανάγνωση

^