Μενού

Πρακτική εφαρμογή 7-βημάτων μη αυτόματης δοκιμής πριν από την κυκλοφορία της παραγωγής

7 step practical implementation manual testing before production release

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

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

Αν το χάσατε, Μπορείτε να το διαβάσετε εδώ .

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

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

Αυτό το άρθρο θα ρίξει φως σε όλες αυτές τις πτυχές.

Υλοποίηση χειροκίνητων δοκιμών

Ας αρχίσουμε.

Τι θα μάθετε:

Χειροκίνητος κύκλος δοκιμών

Να καταλαβεις Χειροκίνητος κύκλος δοκιμών ή Software Test Life Cycle (STLC), πρώτα απ 'όλα, πρέπει να κατανοήσουμε το Software Development Life Cycle (SDLC), για τον οποίο είμαι σίγουρος ότι έχετε ήδη κατανοήσει.

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

Όπως τα περισσότερα από τα ο κόσμος πηγαίνει ευκίνητος αυτές τις μέρες, θα κρατήσω τα πράγματα μου απλοποιημένα γύρω από το Agile.

7 Πρακτικά χειροκίνητα βήματα δοκιμής πριν από την κυκλοφορία της παραγωγής

Ορίστε.

Θυμηθείτε ότι μιλώ τόσο για SDLC όσο και για STLC.

# 1) Συγκέντρωση απαιτήσεων

Φάση συγκέντρωσης απαιτήσεων

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

Οι άνθρωποι χρησιμοποιούν οτιδήποτε για να τεκμηριώσουν αυτά που ταιριάζουν αλλά δεν περιορίζονται σε παραδοσιακές πλατφόρμες όπως το MS word doc, τις σύγχρονες πλατφόρμες όπως το Jira / Rally και τα εργαλεία νέας εποχής όπως το Trello.

# 2) Συζήτηση / Κοινή χρήση απαιτήσεων

Φάση συζήτησης για τις απαιτήσεις

Στη συνέχεια, το Business Analyst υποτίθεται ότι μοιράζεται τεκμηριωμένες απαιτήσεις με την ομάδα ανάπτυξης, την ομάδα δοκιμών και την ομάδα UX (εάν απαιτείται). Αυτό συμβαίνει συνήθως μέσω μιας επίσημης συνάντησης όπου SPOCs (Single Point Of Contacts ή ολόκληρη η ομάδα, εξαρτάται) και από τις τρεις λειτουργίες πληρούν και κατανοούν ολόκληρη την απαίτηση.

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

Περαιτέρω ανάγνωση=> Πώς να αναθεωρήσετε το έγγραφο SRS

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

Και πάλι αυτό που καλεί αυτό το συγκεκριμένο συνέδριο / βήμα και η τεκμηρίωσή του διαφέρει από εταιρεία σε εταιρεία.

Για παράδειγμα, η τεκμηρίωση καλείται ή αναλύεται ως SRS (Προδιαγραφή Απαιτήσεων Συστήματος), Έγγραφο Απαίτησης, Επική, Ιστορία χρήστη, Σημείο ιστορίας (πιθανώς, μονάδα μικρότερης απαίτησης) κ.λπ. Απαραίτητη συνάντηση συζήτησης, καλλωπισμός, συνάντηση τρυπών, κ.λπ., ελπίζω να καταλάβετε τη γνώμη μου;

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

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

# 3) Σχεδιασμός

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

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

  • Αποφασίζοντας την αναπτυξιακή προσέγγιση
  • Προετοιμασία εγγράφου σχεδίασης
  • Σχεδιασμός διαγραμμάτων ροής
  • Εκτίμηση των προσπαθειών
  • Υπολογίζοντας τον αντίκτυπο αυτής της νέας απαίτησης σε οποιαδήποτε υπάρχουσα λειτουργικότητα
  • Πρέπει να διορθώσετε υπάρχοντα δεδομένα κ.λπ.

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

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

# 4) Σενάριο δοκιμής / σχεδιασμός υπόθεσης

Σενάριο δοκιμής Φάση σχεδιασμού

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

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

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

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

  • Κάλυψη απαιτήσεων
  • Γραμματική ορθογραφίας
  • Πρότυπα γραφής υπόθεσης (τίποτα άλλο από ένα πρότυπο που ακολουθεί μια ομάδα / εταιρεία)
  • Συμβατότητα προς τα πίσω
  • Συμβατότητα πλατφόρμας
  • Αναφορές δεδομένων δοκιμής
  • Τύποι στοχευμένων δοκιμών κ.λπ.

Περαιτέρω ανάγνωση=> Σύνταξη δοκιμαστικών περιπτώσεων από έγγραφο SRS

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

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

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

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

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

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

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

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

Περαιτέρω ανάγνωση=> Πώς να γράψετε ένα έγγραφο δοκιμαστικού σχεδίου

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

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

# 5) Φάση ανάπτυξης

Φάση ανάπτυξης λογισμικού

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

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

# 6) Φάση δοκιμής

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

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

καλύτερες υπηρεσίες κλήσεων συνδιαλέξεων χωρίς χρέωση

Επιτρέψτε μου να αναλυθώ περαιτέρω σε αυτήν τη φάση και να μιλήσω για τα σημαντικά καθήκοντα:

  • Η ομάδα δοκιμών / δοκιμών ξεκινά με τον γύρο δοκιμών (διερευνητικές δοκιμές και εκτέλεση γραπτών περιπτώσεων δοκιμών) και ελαττώματα καταγραφής
  • Η ομάδα ανάπτυξης τα επιλύει κατά προτεραιότητα.
  • Η νέα έκδοση (κωδικός) λαμβάνεται σε περιβάλλον στο οποίο πραγματοποιούνται δοκιμές
  • Στη συνέχεια, τα επιλυθέντα ελαττώματα επαληθεύονται από την ομάδα δοκιμών / δοκιμών και επισημαίνονται ως διορθωμένα
  • Αυτός ο κύκλος συνεχίζεται έως ότου επιτευχθούν τα κριτήρια εξόδου.
  • Λάβετε υπόψη ότι, όπως απαιτείται, τα ελαττώματα επισημαίνονται επίσης ως Μη έγκυρα, Διπλότυπα και μπορούν επίσης να χαρακτηριστούν ως Βελτιώσεις.

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

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

Διαβάστε λεπτομερή βήματα=> Φάση εκτέλεσης δοκιμής

# 7) Ανασκόπηση επιχειρηματικών αναλυτών (BA)

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

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

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

# 8) Αποστολή / Απελευθέρωση

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

Συνιστώμενη ανάγνωση=> Διαδικασία απελευθέρωσης δοκιμής

Τύποι μη αυτόματων δοκιμών (διαβάστε τον άνθρωπο)

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

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

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

Εάν μου επιτρέπεται, επιτρέψτε μου να μιλήσω σε λίγες γραμμές του Human Testing (το οποίο ενθαρρύνω κάθε υπεύθυνο δοκιμών να κάνει μόνο χειροκίνητες λειτουργικές δοκιμές). Τώρα μην μπερδεύεστε, κατά την άποψή μου, η χειροκίνητη λειτουργική δοκιμή είναι ένα υποσύνολο του Human Testing. Επειδή υπάρχουν τόσα πολλά πράγματα που μόνο το ανθρώπινο μυαλό μπορεί να κάνει.

Ακολουθεί η λίστα με μερικούς από τους δημοφιλείς και σημαντικούς τύπους δοκιμών που μπορούν να ταξινομηθούν σε Ανθρώπινη δοκιμή:

  • Χειροκίνητη λειτουργική δοκιμή : Δοκιμή της λειτουργικότητας της εφαρμογής έναντι της δεδομένης απαίτησης με ανθρώπινες προσπάθειες και ευφυΐα. Περαιτέρω χωρίζεται σε αρκετά είδη με βάση το πεδίο εφαρμογής και την ατζέντα των δοκιμών, όπως δοκιμές συστήματος, δοκιμές μονάδων, δοκιμές καπνού, δοκιμές λογικής, δοκιμές ολοκλήρωσης, δοκιμή παλινδρόμησης, Δοκιμή UI κ.λπ.
  • Δοκιμή απόδοσης : Αυτό κατηγοριοποιείται σε μη λειτουργικές δοκιμές, σωστά; Αλλά και πάλι είναι ο άνθρωπος που το εφαρμόζει, αν και η εκτέλεση γίνεται είτε από άνθρωπο είτε από εργαλείο. Ο υπεύθυνος δοκιμών θα πρέπει τουλάχιστον να κάνει αυτή τη δοκιμή από την άποψη του χρόνου απόκρισης (για να δει εάν είναι αποδεκτό) εάν δεν υποτίθεται ότι θα χρησιμοποιήσει κανένα εργαλείο για τη δοκιμή φορτίου και όλα.
  • Πρόγραμμα περιήγησης / Δοκιμή συμβατότητας πλατφόρμας: Η υπό δοκιμή εφαρμογή θα πρέπει να φαίνεται και να λειτουργεί όπως αναμένεται (προφανώς μπορεί να υπάρχει μια μικρή διαφορά ανάλογα με τη μηχανή του προγράμματος περιήγησης) μεταξύ των προγραμμάτων περιήγησης και των πλατφορμών (ή των συσκευών εάν πρόκειται για εφαρμογή για κινητά).
  • Δοκιμή χρηστικότητας : Επιτρέψτε μου να συμφωνήσω καταρχάς ότι αυτό είναι ένα τεράστιο θέμα από μόνο του και συνήθως ανήκει σε ειδικούς στη δοκιμή ευχρηστίας. Εξακολουθώ να πιστεύω ότι ως δοκιμαστής θα πρέπει τουλάχιστον να αναφέρουμε ή να επισημάνουμε αν βρίσκουμε κάτι λιγότερο χρήσιμο ή πρέπει να μοιραστούμε την άποψή μας.
  • Δοκιμή ασφαλείας : Και πάλι πολύ τεράστιος τύπος δοκιμών και φυσικά απαιτεί πολλές πρακτικές γνώσεις. Ο υπεύθυνος δοκιμών θα πρέπει να προσπαθήσει να μάθει και να εκτελέσει τουλάχιστον βασικές δοκιμές όπως παραβίαση URL, δέσμες ενεργειών μεταξύ ιστότοπων, έγχυση SQL, πειρατεία συνεδρίας κ.λπ. ανάλογα με τις διαθέσιμες γνώσεις και όπου είναι δυνατόν.
  • Δοκιμή πολλαπλών μισθώσεων: Εάν η αίτησή σας είναι πολλών μισθωτών, δηλ. Μεμονωμένη παρουσία δεδομένων πολλαπλών πελατών, τότε αυτός ο έλεγχος είναι απαραίτητος. Ανεξάρτητα από τη ρητή αναφορά στις απαιτήσεις, αυτό πρέπει να γίνει. Τα δεδομένα ενός πελάτη που εμφανίζονται σε άλλο είναι ένα είδος ανάπτυξης και δοκιμής εγκλήματος.

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

Αυτό είναι όλο για αυτό το μέρος. Ευχαριστούμε που το διαβάσατε. Μοιραστείτε τις απόψεις / τα σχόλιά σας στα σχόλια.

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

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

^