Πώς να εκτελέσετε αποτελεσματικά τις δοκιμές μετά την κυκλοφορία και να ελαχιστοποιήσετε τον αντίκτυπο της κυκλοφορίας σε ζωντανούς πελάτες

how perform post release testing effectively

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

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

Αυτό ήταν καινούργιο για μένα και είχα τόσες πολλές ερωτήσεις και αμφιβολίες στο μυαλό μου:

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

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

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

Τι θα μάθετε:

• Τι είναι η επαλήθευση κυκλοφορίας μετά την παραγωγή;
• Ποιες εργασίες και δραστηριότητες περιλαμβάνονται στη φάση επαλήθευσης μετά την κυκλοφορία;
• Πρέπει να δοκιμάσω τα πάντα ξανά;
• Πώς μπορώ να διατυπώσω τη στρατηγική επαλήθευσης μετά την κυκλοφορία;
• Ποιος δημιουργεί το πρόγραμμα δοκιμής κυκλοφορίας μετά την παραγωγή;
• Ποιος εγκρίνει το σχέδιο δοκιμής κυκλοφορίας μετά την παραγωγή;
• Πότε δημιουργώ το σχέδιο επαλήθευσης μετά την κυκλοφορία;
• Ολοκλήρωσα την επαλήθευση της έκδοσης μετά την παραγωγή. Τι έπεται?
• Τι θα συμβεί αν βρω ένα πρόβλημα;
• Τι άλλο πρέπει να γνωρίζω σχετικά με τη διαδικασία επαλήθευσης της κυκλοφορίας μετά την παραγωγή;
• Συμπέρασμα:
• Συνιστώμενη ανάγνωση

Τι είναι η επαλήθευση κυκλοφορίας μετά την παραγωγή;

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

Συνιστώμενη ανάγνωση=> Πώς να προετοιμάσετε αποτελεσματικά το «περιβάλλον δοκιμών» πριν ξεκινήσετε τη δοκιμή

Ο στόχος είναι να επαληθευτεί η κυκλοφορία σε περιβάλλοντα παραγωγής / LIVE.

σύγκριση εργαλείων διαχείρισης απαιτήσεων ανοιχτού κώδικα

Αλλά τα ερωτήματα προκύπτουν:

• Γιατί πρέπει να κάνουμε δοκιμές κυκλοφορίας μετά την παραγωγή όταν δοκίμασα τα πάντα σε περιβάλλον QA;
• Γιατί αναμένουμε να προκύψουν ζητήματα στην παραγωγή αν και δοκιμάσαμε την κυκλοφορία διεξοδικά σε περιβάλλον δοκιμής;

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

Λόγοι για τους οποίους θα έχουμε προβλήματα στην παραγωγή:

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

2) Θέμα ανάπτυξης - Εάν η εταιρεία σας διαθέτει μη αυτόματη διαδικασία ανάπτυξης build, η κυκλοφορία σας ενδέχεται να είναι πιο επιρρεπής σε προβλήματα ανάπτυξης. Ορισμένα κοινά σενάρια μπορεί να είναι, λείπουν ρυθμίσεις ή τοποθεσίες, λείπουν δέσμες ενεργειών DB, δεν ακολουθείται η σειρά ανάπτυξης (κωδικός πρώτα, μετά DB κ.λπ.), εξαρτώνται εσφαλμένα εγκατεστημένες κ.λπ.

Διαβάστε επίσης=> Τι πρέπει να γνωρίζει ο TA Tester για τη διαδικασία ανάπτυξης

3) Δεν εντοπίστηκαν περιοχές επιπτώσεων - Μπορεί να υπάρχουν ορισμένα σενάρια για τα οποία οι περιοχές που επηρεάζονται ενδέχεται να μην έχουν αναγνωριστεί σωστά και πλήρως από την ομάδα.

Για παράδειγμα, σκεφτείτε ένα SaaS περιβάλλον.

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

4) Άγνωστες περιοχές επιπτώσεων - Αυτό μπορεί να συμβεί εάν δεν είναι γνωστά το εύρος και οι περιοχές που επηρεάζονται από την κυκλοφορία. Για παράδειγμα, σε μια εταιρεία με πολλά προϊόντα λογισμικού που μοιράζονται κοινό DB και αρχιτεκτονική, ακόμη και μια μικρή αλλαγή μπορεί να σπάσει τη λειτουργικότητα πολλών προϊόντων.

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

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

• Επαλήθευση έκδοσης μετά την παραγωγή
• Αναφορά αποτελεσμάτων επαλήθευσης
• Αναφορά τυχόν προβλημάτων που βρέθηκαν στην παραγωγή
• Εκκαθάριση δεδομένων επαλήθευσης μετά την κυκλοφορία
• Παρακολούθηση μετά την κυκλοφορία (εάν υπάρχει)

Πρέπει να δοκιμάσω τα πάντα ξανά;

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

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

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

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

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

τι είναι ένας κωδικός ασφαλείας δικτύου

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

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

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

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

Ας πάρουμε ένα παράδειγμα της ακόλουθης οργάνωσης ομάδας QA.

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

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

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

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

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

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

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

Ολοκλήρωσα την επαλήθευση της έκδοσης μετά την παραγωγή. Τι έπεται?

Αφού ολοκληρωθεί η επαλήθευση μετά την κυκλοφορία, θα ήταν τα επόμενα βήματα

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

2) Αναφορά τυχόν ζητημάτων που εντοπίστηκαν στην παραγωγή στο εργαλείο διαχείρισης ελαττωμάτων - Προς την διευκολύνει την ανάλυση των αιτίων και ιχνηλασιμότητα .

3) Εκκαθάριση δεδομένων επαλήθευσης μετά την κυκλοφορία - Η εκκαθάριση δεδομένων πρέπει να γίνει αφού ολοκληρωθεί η επαλήθευση.

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

4) Παρακολούθηση κυκλοφορίας μετά την παραγωγή (εάν υπάρχει) - Ορισμένες κυκλοφορίες απαιτούν παρακολούθηση της παραγωγής.

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

Τι θα συμβεί αν βρω ένα πρόβλημα;

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

Είναι σημαντικό όλα τα ζητήματα που εντοπίζονται να αναφέρονται στο Εργαλείο παρακολούθησης ελαττωμάτων. Συνιστάται να προβληθούν ως ξεχωριστός τύπος ζητήματος (π.χ. Post Production Bug) για να εμφανιστεί διαχωρισμός από τα κανονικά σφάλματα κύκλου QA. Αυτά τα ζητήματα μπορούν να φιλτραριστούν εύκολα εάν απαιτείται για τους σκοπούς της ανάλυσης των βασικών αιτίων.

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

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

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

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

Περιορισμοί:

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

Παράδειγμα # 1): Για μια εταιρεία eSurvey, εάν η δοκιμή περιλαμβάνει απάντηση και υποβολή της έρευνας, το QA θα πρέπει να στείλει ένα αίτημα για διαγραφή της δοκιμαστικής έρευνας μετά την επαλήθευση, ώστε να μην επηρεάσει τα δεδομένα συλλογής της έρευνας πελατών και τα στατιστικά στοιχεία τους.

ΕΙΝΑΙ δείγμα # 2): Για μια εταιρεία ηλεκτρονικού εμπορίου, ας υποθέσουμε ότι μια ενημέρωση τιμής Η εργασία SQL εκτελείται τα μεσάνυχτα κάθε μέρα και ανεβάζει την τελική τιμή στον ιστότοπο. Δεν μπορούμε να εκτελέσουμε αυτήν την SQL κατ 'απαίτηση, πολλές φορές για τον σκοπό της επαλήθευσης μετά την κυκλοφορία, καθώς αυτό μπορεί να προκαλέσει την προώθηση μη ολοκληρωμένων δεδομένων στην παραγωγή.

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

• Η προσπάθεια που απαιτείται για τη δοκιμή μετά την κυκλοφορία και όλες τις σχετικές δραστηριότητες θα πρέπει να ενσωματωθεί και να συμπεριληφθεί στο Σχέδιο Έργου. Ανάλογα με τους επιχειρηματικούς κανόνες και τις ιδιαιτερότητες του έργου, αυτό μπορεί να θεωρηθεί ως γενικό έργο ή να συμπεριληφθεί στον κύκλο QA ή να συμπεριληφθεί ως μέρος του σχεδίου διαχείρισης κυκλοφορίας.
• Για τα ζητήματα που αναφέρονται κατά την επαλήθευση μετά την κυκλοφορία, θα πρέπει να διεξαχθεί ανάλυση ριζικών αιτίων για να ανακαλυφθεί ο λόγος για τον οποίο το ζήτημα δεν εντοπίστηκε νωρίς και τι μπορεί να γίνει καλύτερα την επόμενη φορά για να αποφευχθεί η αντιμετώπιση του ζητήματος. Η ανάλυση των βασικών αιτίων μπορεί να βοηθήσει την ομάδα να μάθει από αυτά τα προηγούμενα ζητήματα και να καλύψει τυχόν κενά στην εφαρμογή. Με βάση τη δομή της οργάνωσης, το Test Lead ή το QA Manager μπορεί να ολοκληρώσει την ανάλυση της αιτίας με τη συμβολή της ομάδας του έργου. Ορισμένες κοινές αιτίες μπορεί να είναι ένα ζήτημα κωδικοποίησης, ζήτημα απαιτήσεων, ζήτημα σχεδιασμού, ζήτημα δεδομένων, περιορισμοί τρίτων, ελλείπον σενάριο δοκιμής κ.λπ. Μπορούν να δημιουργηθούν και να εντοπιστούν αντίστοιχες διορθωτικές και προληπτικές ενέργειες.
• Αρχεία καταγραφής διακομιστή μπορεί επίσης να χρησιμοποιηθεί για την παρακολούθηση της έκδοσης μετά την κυκλοφορία. Μητρώο διακομιστή ενδέχεται να περιέχει συμβάντα ή ζητήματα που ενδέχεται να μην είναι ορατά στον πελάτη, αλλά θα προκαλέσουν προβλήματα στο backend. Αυτή η παρακολούθηση μπορεί να ανατεθεί ως στοιχείο δράσης στον επικεφαλής Dev και στην ομάδα DevOps.

Ενα παράδειγμα:

Επισκόπηση έργου:

πώς να δημιουργήσετε μια εφαρμογή java στο Eclipse

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

1. Η επικύρωση πεδίου επώνυμου πρέπει να καταργηθεί. Εφαρμόστηκε προηγουμένως ως «Επώνυμο θα πρέπει να έχει τουλάχιστον 4 χαρακτήρες» (Βελτίωση για το υπάρχον πεδίο)
2. Εφαρμόστε το κουμπί εναλλαγής δίπλα στη διεύθυνση email, έτσι ώστε ο χρήστης να μπορεί να ορίσει τις ρυθμίσεις απορρήτου για να εμφανίζεται η διεύθυνση email στο προφίλ του (νέο αίτημα λειτουργίας)
3. Ο χρήστης θα πρέπει να μπορεί να επιλέξει το avatar του (νέο αίτημα λειτουργίας)
4. Μειώστε τις κλήσεις API κατά τη διαδικασία εγγραφής για να βελτιώσετε την απόδοση της εφαρμογής (Βελτίωση)

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

Συμπέρασμα:

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

Για παράδειγμα, ενώ χρησιμοποιείτε Μοντέλο καταρράκτη , μια ομάδα μπορεί να έχει μια κυκλοφορία παραγωγής κάθε 1,5 μήνες, ωστόσο με τη διαδικασία Agile, η ίδια ομάδα μπορεί τώρα να έχει μια κυκλοφορία παραγωγής κάθε 2-3 εβδομάδες.

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

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

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

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

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

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

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

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

• Τα καλύτερα εργαλεία δοκιμής λογισμικού 2021 (QA Test Automation Tools)
• Testing Primer eBook Λήψη
• Πρακτική εφαρμογή 7-βημάτων μη αυτόματης δοκιμής πριν από την κυκλοφορία της παραγωγής
• Φόρτωση δοκιμής με HP LoadRunner Tutorials
• Πρακτική δοκιμή λογισμικού QA Process Flow (Απαιτήσεις για απελευθέρωση)
• Διαφορά μεταξύ Desktop, Client Server Testing και Web Testing
• Τι είναι το Gamma Testing; Το τελικό στάδιο δοκιμών
• Τι είναι το Early Test: Test Early, Test συχνά BUT Πώς; (Ένας πρακτικός οδηγός)