Μενού

6 Βασικές δεξιότητες που πρέπει να έχει κάθε δοκιμαστής (κυρίως πιο φρέσκος)

6 basic skills that every tester should have

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

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

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

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

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

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

βασικές δεξιότητες δοκιμών

Ας ξεκινήσουμε.

Τι θα μάθετε:

# 1. Τεκμηρίωση

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

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

πώς μπορώ να ανοίξω ένα αρχείο apk

Συνιστώμενη ανάγνωση=> Γιατί η τεκμηρίωση είναι σημαντική στη δοκιμή λογισμικού

# 2. Προετοιμασία δοκιμής

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

α) Σχέδιο δοκιμών: Χαρτογραφεί τη ροή των δοκιμών από την αρχή έως το τέλος .

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

Ορισμένες ομάδες έχουν πολλαπλά επίπεδα σχεδίων δοκιμών: Master Plan και Phase bijak σχέδια.

Ένα σχέδιο δοκιμής πρέπει να έχει:

  • Όνομα και έκδοση έργου
  • Αναγνωριστικά σχεδίου δοκιμής - Δημιουργός, αριθμός προχείρου, ημερομηνία δημιουργίας κ.λπ.
  • Εισαγωγή - Επισκόπηση του έργου, στόχος και περιορισμοί
  • Αναφορές - Λίστα αναφορών που χρησιμοποιούνται ως είσοδος. (Βεβαιωθείτε ότι χρησιμοποιείτε τις ακριβείς και πιο πρόσφατες εκδόσεις)
  • Στοιχεία δοκιμής - Ενότητες, έκδοση, εύρος, εκτός πεδίου, κ.λπ.
  • Συνολική προσέγγιση δοκιμής / στρατηγική δοκιμής - Εργαλεία για χρήση, διαδικασία παρακολούθησης ελαττωμάτων, επίπεδα δοκιμών προς εκτέλεση κ.λπ.
  • Κριτήρια στοιχείων επιτυχίας / αποτυχίας - Οδηγίες εκτέλεσης δοκιμής
  • Κριτήρια αναστολής και επανέναρξης
  • Παραδοτέα δοκιμής - Περίπτωση δοκιμής, αναφορές δοκιμών, αναφορά σφαλμάτων, μετρήσεις δοκιμής κ.λπ.
  • Ελέγξτε τις λεπτομέρειες του περιβάλλοντος
  • Ομάδα ρόστερ με πληροφορίες σημείου επαφής. για κάθε ενότητα ή τύπο δοκιμής
  • Εκτιμήσεις δοκιμής - Χρόνος και προσπάθεια. Τα στοιχεία του προϋπολογισμού είναι εμπιστευτικά και δεν θα τα βρείτε εδώ
  • Σχέδια κινδύνων και μετριασμού
  • Εγκρίσεις
  • Άλλες οδηγίες

Διαβάστε επίσης=>

πώς να προβάλετε ένα αρχείο bin

β) Σενάρια δοκιμής:

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

Τα περισσότερα από αυτά περιέχουν:

  • Όνομα ενότητας / στοιχείου / λειτουργίας (είσοδος, διαχειριστής, εγγραφή κ.λπ.)
  • Το ID σεναρίου είναι για αναφορά (π.χ. TS_Login_001)
  • Περιγραφή σεναρίου - «Τι να δοκιμάσετε» Π.χ .: Επικυρώστε εάν η σύνδεση επιτρέπει σε χρήστες με έγκυρα διαπιστευτήρια να συνδεθούν με επιτυχία
  • Σημασία σεναρίου - Προτεραιότητα σε περίπτωση ανεπαρκούς χρόνου - Υψηλή / Μεσαία / Χαμηλή
  • Αναγνωριστικό απαίτησης - Για ιχνηλασιμότητα

Περαιτέρω ανάγνωση=>

γ) Περίπτωση δοκιμής:

Οι ακριβείς περιπτώσεις δοκιμής δίνουν ακριβή αποτελέσματα δοκιμών. Τα υπολογιστικά φύλλα εξακολουθούν να είναι το δημοφιλές μέσο για τη σύνταξη δοκιμαστικών περιπτώσεων, ειδικά για αρχάριους, παρόλο που ορισμένες εταιρείες προσαρμόζουν εργαλεία διαχείρισης δοκιμών. Η βάση για τη σύνταξη δοκιμαστικών περιπτώσεων είναι το έγγραφο SRS / FRD / Req. Όμως, δεν αρκεί συχνά, οπότε θα πρέπει να χρησιμοποιήσετε πολλές υποθέσεις και συζητήσεις με τις ομάδες BA / Dev.

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

Για περισσότερες πληροφορίες σχετικά με αυτά, ελέγξτε:

Μερικά από τα κοινά χαρακτηριστικά που έχουν όλες οι περιπτώσεις δοκιμής είναι:

  • Αναγνωριστικό σεναρίου - Λήφθηκε από το έγγραφο δοκιμαστικού σεναρίου
  • Αναγνωριστικό δοκιμαστικής υπόθεσης - Για μοναδική αναγνώριση και παρακολούθηση. Π.χ .: TC_login_001
  • Περιγραφή δοκιμής - Σύντομη επεξήγηση της δοκιμαστικής κατάστασης που δοκιμάστηκε
  • Βήματα προς εκτέλεση - Αναλυτικές οδηγίες βήμα προς βήμα σχετικά με τον τρόπο δοκιμής
  • Δεδομένα δοκιμής - Δεδομένα που παρέχονται στα βήματα δοκιμής
  • Αναμενόμενο αποτέλεσμα - Αποτέλεσμα όπως αναμενόταν
  • Πραγματικό αποτέλεσμα - Απόκριση του AUT κατά την εκτέλεση της δοκιμής
  • Κατάσταση - Pass / Fail / No Run / Incomplete / Blocked - Περιγράφει το αποτέλεσμα του τεστ
  • Σχόλια - Σε πρόσθετες λεπτομέρειες
  • Εκτελέστηκε από - Όνομα Tester
  • Ημερομηνία εκτέλεσης - Ημερομηνία εκτέλεσης του τεστ
  • Defect ID - Ελάττωμα που καταγράφηκε στη δοκιμαστική θήκη, σε περίπτωση αποτυχίας του τεστ
  • Λεπτομέρειες διαμόρφωσης - Λειτουργικό σύστημα, Πρόγραμμα περιήγησης, Πλατφόρμα, πληροφορίες συσκευής (προαιρετικά)

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

# 3. Διαδικασία δοκιμής - Τι δοκιμές πρέπει να εκτελέσετε;

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

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

# 4. Δοκιμές στο στάδιο μερικής ανάπτυξης

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

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

τι είναι ένα αρχείο .7z;

# 5. Έγγραφο αναφοράς σφαλμάτων

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

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

  • Defect ID - Συνήθως ένας σειριακός αριθμός
  • Περιγραφή ελαττώματος - Μια γραμμή εξήγησης του προβλήματος
  • Τοποθεσία - Ενότητα / περιοχή του AUT όπου εντοπίζεται το πρόβλημα
  • Αριθμός έκδοσης - Έκδοση και κωδικός έκδοσης αριθ.
  • Βήματα για αναπαραγωγή - Λίστα βημάτων που σας οδηγούν στο πρόβλημα
  • Σοβαρότητα - Ορίστε ένα επίπεδο για να περιγράψετε τη σοβαρότητα του προβλήματος - Χαμηλό, μεσαίο, υψηλό, αποκλεισμό κ.λπ.
  • Προτεραιότητα - Ρύθμιση από προγραμματιστές για τον καθορισμό της σειράς με την οποία θα διορθωθεί το ελάττωμα (P1, P2, P3, κ.λπ. P1 - υψηλότερο)
  • Ανατέθηκε σε - Κάτοχος του ελαττώματος εκείνη τη στιγμή
  • Αναφέρθηκε από - Όνομα Tester
  • Κατάσταση - Διαφορετική κατάσταση που αντιπροσωπεύει το στάδιο του κύκλου ζωής του σφάλματος
    • Νέο - Το σφάλμα εντοπίστηκε και μόλις αναφέρθηκε
    • Άνοιγμα - Επικυρώθηκε από τον προβάδισμα QA
    • Ανατέθηκε - Στάλθηκε στον δυνητικό πελάτη για ανάθεση στον αντίστοιχο προγραμματιστή
    • In Progress / Work in Progress - Ο Dev άρχισε να εργάζεται σε αυτό
    • Διορθώθηκε / επιλύθηκε - Ο προγραμματιστής έχει ολοκληρώσει την επεξεργασία του
    • Επαληθεύτηκε / Κλειστό - Η ομάδα QA επανεξέτασε και βρήκε το σφάλμα διορθωμένο
    • Επανεξέταση - Η ομάδα QA δεν συμφωνεί με την επίλυση του Dev και προωθεί περαιτέρω το σφάλμα για επανεπεξεργασία
    • Διπλότυπο - Υπάρχει ήδη παρόμοιο σφάλμα
    • Αναβαλλόμενη - Έγκυρο σφάλμα αλλά θα διορθωθεί σε μεταγενέστερες εκδόσεις
    • Μη έγκυρο - Δεν είναι σφάλμα ή δεν μπορεί να αναπαραχθεί ή δεν υπάρχουν αρκετές πληροφορίες

Περαιτέρω ανάγνωση=>

# 6. Διαδικασία αποσύνδεσης

Αποσύνδεση και η αποστολή τελικής τεκμηρίωσης είναι καθήκον του υπεύθυνου / διευθυντή QA. Ωστόσο, η ομάδα πρέπει να υποβάλει τα παραπάνω έγγραφα (σενάριο δοκιμής, υπόθεση δοκιμής και έγγραφο καταγραφής ελαττωμάτων) για τελικούς ελέγχους και έλεγχο.

Βεβαιωθείτε ότι έχετε διορθώσει όλα αυτά και στέλνετε τις τελικές εκδόσεις.

Διαβάστε επίσης=>

συμπέρασμα

Αυτή είναι η διαδικασία που έχω δει και βίω από πρώτο χέρι όταν ήμουν δοκιμαστής και ελπίζω ότι αυτό σας έδωσε κάποιους χρήσιμους δείκτες.

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

Όλα τα καλύτερα για την καριέρα σας!

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

^