Μενού

Ζωντανή παρακολούθηση σφαλμάτων έργου, δοκιμαστικές μετρήσεις και δοκιμαστική αποσύνδεση - Δωρεάν ημέρα εκπαίδευσης QA 6

live project bug tracking

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

Αυτό είναι το τελικό μέρος του «μας Εκπαίδευση δοκιμών λογισμικού σε ζωντανό έργο Σειρά.

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

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

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

Τι συμβαίνει όταν συναντούμε αυτές τις αποκλίσεις;

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

# 1) Αυτές οι αποκλίσεις αναφέρονται ως ελαττώματα / σφάλματα / ζητήματα / περιστατικά / σφάλματα / σφάλματα.

#δύο) Όλες οι ακόλουθες περιπτώσεις μπορούν να καταγραφούν ως ελαττώματα

  • Λείπουν απαιτήσεις
  • Λανθασμένες απαιτήσεις εργασίας
  • Επιπλέον απαιτήσεις
  • Ανακολουθίες εγγράφου αναφοράς
  • Θέματα που σχετίζονται με το περιβάλλον
  • Προτάσεις βελτίωσης

# 3) Η εγγραφή ελαττωμάτων γίνεται κυρίως σε φύλλα excel ή μέσω της χρήσης λογισμικού / εργαλείου διαχείρισης ελαττωμάτων. Για πληροφορίες σχετικά με τον τρόπο χειρισμού ελαττωμάτων μέσω εργαλείων, δοκιμάστε να χρησιμοποιήσετε τους ακόλουθους συνδέσμους:

Τι θα μάθετε:

Πώς να καταγράψετε αποτελεσματικά τα ελαττώματα

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

ερωτήσεις και απαντήσεις συνέντευξης στο γραφείο βοήθειας

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

  • Αναγνωριστικό ελαττώματος: Για μοναδική αναγνώριση.
  • Περιγραφή ελαττώματος: Αυτός είναι σαν τίτλος για να περιγράψω το ζήτημα εν συντομία.
  • Ενότητα / ενότητα του AUT: Αυτό είναι προαιρετικό, απλώς για να προσθέσετε περισσότερη σαφήνεια ως προς την ένδειξη της περιοχής του AUT όπου αντιμετωπίστηκε το πρόβλημα.
  • Βήματα για αναπαραγωγή: Ποια είναι η ακριβής ακολουθία των λειτουργιών που πρέπει να εκτελεστούν στο AUT για την αναδημιουργία του σφάλματος που αναφέρονται εδώ. Επίσης, εάν οποιαδήποτε δεδομένα εισόδου είναι ειδικά για το πρόβλημα, πρέπει να εισαχθούν και πληροφορίες.
  • Αυστηρότητα: Για να δείξει την ένταση του ζητήματος και τελικά τον αντίκτυπο που μπορεί να έχει στη λειτουργία του AUT. Οι οδηγίες για τον τρόπο εκχώρησης και τις τιμές που πρέπει να εκχωρηθούν σε αυτό το πεδίο βρίσκονται στο έγγραφο του σχεδίου δοκιμών. Επομένως, ανατρέξτε στο Έγγραφο δοκιμαστικού σχεδίου από το άρθρο 3 .
  • Κατάσταση: Θα συζητηθεί περαιτέρω στο άρθρο.
  • Στιγμιότυπο οθόνης: Ένα στιγμιότυπο της εφαρμογής για να εμφανιστεί το σφάλμα όταν συνέβη.

Αυτά είναι μερικά από τα 'must-have' πεδία. Αυτό το πρότυπο μπορεί να επεκταθεί (π.χ. για να συμπεριλάβει το όνομα του υπεύθυνου δοκιμών που ανέφερε το ζήτημα) ή συμβόλαιο ( Για παράδειγμα, το όνομα της ενότητας αφαιρέθηκε) όπως απαιτείται.

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

Δείγμα αναφοράς ελαττωμάτων για το έργο OrangeHRM Live:

Αναφορά ελαττώματος OrangeHRM

=> Κάντε κλικ εδώ για να πραγματοποιήσετε λήψη ζωντανής αναφοράς ελαττωμάτων έργου

Ακολουθεί το δείγμα Αναφοράς ελαττωμάτων που δημιουργήθηκε στο εργαλείο διαχείρισης δοκιμών qTest: (Κάντε κλικ στην εικόνα για μεγέθυνση)

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

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

Κύκλος ελαττωμάτων:

Ελαττωματικός κύκλος ζωής 1

Από την παραπάνω διαδικασία, μπορεί να σημειωθεί ότι τα σφάλματα περνούν από διαφορετικούς ανθρώπους και διαφορετικές αποφάσεις κατά τη διαδικασία εντοπισμού προς διόρθωση. Για να παρακολουθείτε και να καθιερώνετε διαφάνεια ως προς το ακριβώς σε ποιο σημείο βρίσκεται ένα συγκεκριμένο σφάλμα, ένα πεδίο 'Κατάσταση' χρησιμοποιείται στην αναφορά σφαλμάτων. Η όλη διαδικασία αναφέρεται ως «κύκλος ζωής σφαλμάτων». Για περισσότερες πληροφορίες σχετικά με όλες τις καταστάσεις και τις έννοιες τους, ανατρέξτε σε αυτό Εκμάθηση κύκλου ζωής σφαλμάτων .

Λίγοι δείκτες κατά την παρακολούθηση σφαλμάτων

  • Όταν είμαστε νέοι σε μια δημιουργική ομάδα / Project / AUT, είναι πάντα καλύτερο να το κάνουμε συζητήστε το ζήτημα που αντιμετωπίσαμε με έναν ομότιμο για να βεβαιωθούμε ότι η κατανόησή μας για το τι πραγματικά κάνει για ένα ελάττωμα είναι σωστή ή όχι.
  • Προς την παρέχει όλες τις πληροφορίες αυτό είναι απαραίτητο για την αναπαραγωγή του ζητήματος. Ένα ελάττωμα που επιστρέφει σε μια ομάδα δοκιμών με την κατάσταση που έχει οριστεί ως 'Δεν υπάρχουν αρκετές πληροφορίες' δεν μας αντανακλά πολύ θετικά. Δείτε αυτήν την ανάρτηση - Πώς να επιλύσετε όλα τα σφάλματα χωρίς ετικέτα 'Μη έγκυρο σφάλμα' .
  • Ελέγξτε εάν προέκυψε ένα παρόμοιο πρόβλημα πριν δημιουργήσετε ένα νέο. Θέματα «διπλότυπων» είναι επίσης άσχημα νέα για την ομάδα QA.
  • Εάν υπάρχει κάποιο πρόβλημα, αυτό προκύπτει τυχαία και δεν γνωρίζουμε τα ακριβή βήματα / καταστάσεις στις οποίες μπορούμε να αναδημιουργήσουμε το ζήτημα - θέστε το θέμα όλα τα ίδια. Με τον κίνδυνο να τεθεί το ζήτημα «IrReproducible / όχι αρκετές πληροφορίες» - πρέπει ακόμη να διασφαλίσουμε ότι χειριστήκαμε όλες τις πιθανές δυσλειτουργίες στον καλύτερο δυνατό βαθμό.
  • Η γενική πρακτική είναι ότι η ομάδα QA δημιουργεί τα ελαττώματα του καθενός σε ένα φύλλο excel κατά τη διάρκεια μιας ημέρας και το ενοποιεί στο τέλος της ημέρας.

Ο πλήρης κύκλος ζωής ελαττωμάτων

Για το ζωντανό μας έργο αν επρόκειτο να ακολουθήσουμε τον κύκλο ζωής του ελαττώματος για το ελάττωμα 1,

πώς να ανοίξετε ένα αρχείο eps
  • Όταν το δημιουργώ (ο υπεύθυνος δοκιμών), η κατάστασή του είναι 'Νέος'. Όταν το αναθέτω στον επικεφαλής της ομάδας QA, η κατάσταση εξακολουθεί να είναι 'Νέα', αλλά ο κάτοχος είναι τώρα ο προπονητής της QA.
  • Ο δυνητικός πελάτης QA θα εξετάσει το ζήτημα και όταν διαπιστώσει ότι είναι έγκυρο ζήτημα, το ζήτημα ανατίθεται στον δυνητικό πελάτη. Σε αυτή τη φάση, η κατάσταση είναι 'Ανατεθεί' και ο ιδιοκτήτης είναι επικεφαλής Dev.
  • Στη συνέχεια, ο επικεφαλής προγραμματιστή θα εκχωρήσει αυτό το ζήτημα σε έναν προγραμματιστή που θα εργαστεί για την επίλυση αυτού του ζητήματος. Η κατάσταση θα είναι τώρα 'Εργασία σε εξέλιξη' (ή κάτι παρόμοιο με αυτό το αποτέλεσμα), ο κάτοχος είναι ο προγραμματιστής.
  • Για το ελάττωμα 1, ο προγραμματιστής δεν μπορεί να αναπαραγάγει το σφάλμα, οπότε το αναθέτει στην ομάδα QA και ορίζει την κατάσταση ως 'Δεν είναι δυνατή η αναπαραγωγή'.
  • Εναλλακτικά, εάν ο προγραμματιστής μπόρεσε να εργαστεί και να επιλύσει ένα πρόβλημα, η κατάσταση θα οριστεί σε 'επιλυθεί' και το ζήτημα θα ανατεθεί στην ομάδα QA.
  • Στη συνέχεια, η ομάδα QA θα το παραλάβει, θα επανεξετάσει το ζήτημα και αν επιλυθεί, θα θέσει την κατάσταση σε 'Κλειστό' . Εάν το ζήτημα εξακολουθεί να υπάρχει, η κατάσταση έχει οριστεί σε 'Ξανανοίγω' και η διαδικασία συνεχίζεται.
  • Ανάλογα με τις άλλες καταστάσεις, η κατάσταση μπορεί να οριστεί ως 'Αναβαλλόμενος' , 'Δεν υπάρχουν αρκετές πληροφορίες', 'Αντίγραφο' , 'να λειτουργεί όπως προορίζεται' κλπ από τον προγραμματιστή.
  • Αυτή η μέθοδος καταγραφής των ελαττωμάτων, αναφοράς και εκχώρησής τους, διαχείρισης τους είναι μία από τις σημαντικότερες δραστηριότητες που εκτελούνται από τα μέλη της ομάδας QA κατά τη φάση εκτέλεσης της δοκιμής. Αυτό γίνεται σε καθημερινή βάση έως ότου ολοκληρωθεί ένας συγκεκριμένος κύκλος δοκιμών.
  • Μόλις ολοκληρωθεί ο Κύκλος 1, η ομάδα προγραμματιστών θα χρειαστεί μία ή δύο μέρες για να ενοποιήσει όλες τις επιδιορθώσεις και να αναδημιουργήσει τον κώδικα στην επόμενη έκδοση που θα χρησιμοποιηθεί για τον επόμενο κύκλο.
  • Η ίδια διαδικασία συνεχίζεται και πάλι για τον κύκλο 2. Στο τέλος του κύκλου, υπάρχει πιθανότητα να εξακολουθούν να υπάρχουν ορισμένα ζητήματα 'Άνοιγμα' ή να μην διορθωθούν στην εφαρμογή.
  • Σε αυτό το στάδιο - συνεχίζουμε με τον Κύκλο 3; Εάν ναι, πότε θα σταματήσουμε τις δοκιμές;

Έξοδος κριτηρίων για το OrangeHRM Live Project Testing

Εδώ χρησιμοποιούμε αυτό που θα αποκαλούσαμε «Κριτήρια εξόδου». Αυτό είναι προκαθορισμένο στο έγγραφο δοκιμαστικού σχεδίου. Είναι απλώς με τη μορφή της λίστας ελέγχου που θα καθορίσει εάν θα ολοκληρώσουμε τη δοκιμή μετά τον κύκλο 2 ή θα πάμε για έναν ακόμη κύκλο. Φαίνεται, τα παρακάτω όταν συμπληρώνονται λαμβάνοντας υπόψη ορισμένες υποθετικές απαντήσεις στις ακόλουθες ερωτήσεις σχετικά με το έργο OrangeHRM:

Κριτήρια εξόδου δοκιμής

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

Μετρήσεις δοκιμής

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

Φανταστείτε ότι αναφέρω ότι περάστηκαν 10 δοκιμαστικές περιπτώσεις ή εκτελέστηκαν 100 δοκιμαστικές περιπτώσεις - αυτοί οι αριθμοί είναι απλώς ανεπεξέργαστα δεδομένα και δεν δίνουν πολύ καλή προοπτική για το πώς συμβαίνουν τα πράγματα.

Οι μετρήσεις διαδραματίζουν ζωτικό ρόλο στην κάλυψη αυτού του κενού. Οι μετρήσεις είναι με απλά λόγια, έξυπνοι αριθμοί που συλλέγει και διατηρεί η ομάδα δοκιμών . Για παράδειγμα, αν είπα ότι το 90% των δοκιμαστικών περιπτώσεων πέρασε, είναι πιο λογικό από το να πω ότι πέρασαν 150 δοκιμαστικές περιπτώσεις. Δεν είναι;

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

Τα παρακάτω είναι οι πιο συχνά συλλεγόμενες μετρήσεις δοκιμής για τα περισσότερα έργα:

  • Ποσοστό επιτυχίας των δοκιμαστικών περιπτώσεων
  • Ελαττώματα πυκνότητας
  • Ποσοστό κρίσιμων ελαττωμάτων
  • Ελαττώματα, σοβαρός αριθμός

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

Έκδοση δοκιμής αποσύνδεσης / ολοκλήρωσης

Καθώς πρέπει να ενημερώσουμε όλους τους ενδιαφερόμενους ότι η δοκιμή έχει ξεκινήσει, είναι επίσης καθήκον της ομάδας QA να ενημερώνει όλους ότι η δοκιμή έχει ολοκληρωθεί και να κοινοποιήσει τα αποτελέσματα. Έτσι, συνήθως αποστέλλεται ένα μήνυμα ηλεκτρονικού ταχυδρομείου από την ομάδα QA (συνήθως ο επικεφαλής της ομάδας / Διευθυντής QA) δίνοντας μια ένδειξη ότι η ομάδα QA έχει αποσυνδεθεί από το προϊόν που επισυνάπτει τα αποτελέσματα των δοκιμών και τη λίστα ανοιχτών / γνωστών ζητημάτων.

Δείγμα δοκιμής Αποσύνδεση email:

Προς την: Πελάτης, PM, ομάδα Dev, ομάδα DB, BA, ομάδα QA, ομάδα περιβάλλοντος (και οποιοσδήποτε άλλος πρέπει να συμπεριληφθεί)
ΗΛΕΚΤΡΟΝΙΚΗ ΔΙΕΥΘΥΝΣΗ: Γεια σας ομάδα,

Η ομάδα QA αποσυνδέεται στο λογισμικό OrangeHRM έκδοση 3.0 μετά την επιτυχή ολοκλήρωση των 2 κύκλων λειτουργικών δοκιμών του ιστότοπου.

Οι δοκιμαστικές περιπτώσεις και τα αποτελέσματα εκτέλεσης επισυνάπτονται στο email. (Ή αναφέρετε την τοποθεσία στην οποία βρίσκονται. Ή εάν χρησιμοποιείτε λογισμικό διαχείρισης δοκιμών, δώστε λεπτομέρειες σχετικά με το ίδιο.)

Η λίστα των γνωστών ζητημάτων επισυνάπτεται επίσης στο email. (Και πάλι, μπορούν να προστεθούν και άλλες αναφορές που έχουν νόημα.)

Ευχαριστώ,
Επικεφαλής της ομάδας QA.

Συνημμένα: Τελική έκθεση εκτέλεσης, Τελική αναφορά ζητήματος / ελαττώματος, λίστα γνωστών ζητημάτων

Μόλις το δοκιμαστικό email αποσυνδεθεί από την ομάδα QA, τελειώσαμε επίσημα με τη διαδικασία STLC. Αυτό δεν σηματοδοτεί απαραίτητα την ολοκλήρωση της φάσης «Δοκιμή» του SDLC. Έχουμε ακόμη τη δοκιμή UAT για να ολοκληρωθεί για να συμβεί αυτό. Εύρημα περισσότερες λεπτομέρειες σχετικά με τις δοκιμές UAT εδώ .

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

Αυτό είναι!

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

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

^