Μενού

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

  • Κύριος
  • Έννοιες Δοκιμών
  • Τι πρέπει να γνωρίζει ο ελεγκτής QA σχετικά με τη διαδικασία διαχείρισης κυκλοφορίας και ανάπτυξης

what qa tester should know about release

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

πώς να παίξετε αρχεία .jar

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

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

Πολλοί από εσάς μπορεί τώρα να ρωτήσετε, ποια είναι η ανάπτυξη και τι κάνουν πραγματικά σε αυτήν;

διαδικασία διαχείρισης απελευθέρωσης και ανάπτυξης για qa

Τι θα μάθετε:

Συνολική Διαδικασία Έκδοσης και Διαχείρισης Ανάπτυξης & Σημασία για την ομάδα QA

  • Γιατί διατηρούμε πραγματικά διαφορετικά περιβάλλοντα;
  • Πώς μεταφέρεται ο κώδικας από το ένα περιβάλλον στο άλλο;

Θα καλύψω τα ακόλουθα θέματα σε αυτό το άρθρο

  1. Γιατί είναι σημαντικό για τους υπεύθυνους δοκιμών να γνωρίζουν τη διαδικασία απελευθέρωσης και ανάπτυξης;
  2. Διαφορετικά περιβάλλοντα
  3. Τι εννοείς με το Build and Deployment;
  4. Προγραμματισμένη εναντίον έκτακτης ανάγκης
  5. Λίστα ελέγχου QA - Πριν και μετά την ανάπτυξη

# 1. Γιατί είναι σημαντικό για τους υπεύθυνους δοκιμών να γνωρίζουν τη διαδικασία ανάπτυξης;

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

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

# 2. Διαφορετικά περιβάλλοντα

Διαφορετικά περιβάλλοντα

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

  • DEV - Το περιβάλλον Dev είναι αυτό που δημιουργήθηκε και συντηρήθηκε από την ομάδα ανάπτυξης για τη σύνταξη του κώδικα. Η πρόσβαση σε αυτό το περιβάλλον παρέχεται μόνο στην ομάδα ανάπτυξης. Συνήθως η ομάδα QA δεν έχει πρόσβαση σε αυτό το περιβάλλον. Αυτό το περιβάλλον χρησιμοποιείται ως επί το πλείστον από την ομάδα Dev για τον έλεγχο μονάδας τους.
  • QA - Το περιβάλλον QA είναι εκείνο όπου πραγματικά πραγματοποιούνται οι δοκιμές. Αυτό το περιβάλλον ανήκει στην ομάδα QA. Η ομάδα DEV δεν έχει πρόσβαση σε αυτό το περιβάλλον. Μετά την ολοκλήρωση του σχεδιασμού και της κωδικοποίησης, ο κώδικας μετακινείται σε περιβάλλον QA για την ομάδα της QA για τη διεξαγωγή δοκιμής.
  • UAT - Δοκιμή αποδοχής χρήστη είναι ένα περιβάλλον όπου οι δοκιμές διεξάγονται από τους επιχειρηματικούς χρήστες. Αυτό γίνεται αφού ολοκληρωθεί η δοκιμή του συστήματος. Η κύρια πρόθεση είναι να δοκιμάσουμε το σύστημα από επιχειρηματική άποψη. Η πρόσβαση σε αυτό το περιβάλλον παρέχεται μόνο στους επιχειρηματικούς χρήστες. Ωστόσο, σε ορισμένες περιπτώσεις ζητούν βοήθεια από την QA, σε τέτοιες περιπτώσεις, η ομάδα QA έχει προσωρινή πρόσβαση στο περιβάλλον.
  • PROD - Το περιβάλλον PROD είναι το πραγματικό ζωντανό περιβάλλον που εκτίθεται στους πραγματικούς χρήστες και καμία από τις ομάδες DEV και QA δεν έχει πρόσβαση ανάγνωσης / εγγραφής σε αυτό το περιβάλλον. Οι ομάδες υποστήριξης παραγωγών διατηρούνται για την επίλυση ζητημάτων που σχετίζονται με το περιβάλλον παραγωγής.

Διαβάστε επίσης=> Πώς να προετοιμάσετε αποτελεσματικά το 'Test Bed' και να ελαχιστοποιήσετε τα δοκιμαστικά περιβαλλοντικά ελαττώματα

# 3. Τι εννοείς με το Build and Deployment

Ένα build περιέχει κυρίως το μεταγλωττισμένο πακέτο που θα μπορούσε να περιλαμβάνει το εκτελέσιμο bat, exe, τις βιβλιοθήκες όπως το dll, lib και αρχεία όπως αρχεία zip. Η Ομάδα Ανάπτυξης δημιουργεί την έκδοση και την παρέχει στην ομάδα ανάπτυξης για εγκατάσταση.

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

Μόλις αναπτυχθεί η έκδοση, η ομάδα QA ειδοποιείται να το κάνει δημιουργία δοκιμής επαλήθευσης (BVT) και εάν είναι επιτυχής, η ομάδα εκτελεί το υπόλοιπο λειτουργικές δοκιμές .

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

Οι κατασκευές διατηρούνται χρησιμοποιώντας αριθμούς, π.χ. 1.0.01 ή 1.0.03. Έτσι, είναι πιθανό το build 1.0.01 να εκτελεί το DLL v0.2 και το build 1.0.03 να εκτελεί το DLL v0.5. Γίνεται σημαντικό για την ομάδα QA να διασφαλίσει ότι η σωστή κατασκευή αναπτύσσεται στο περιβάλλον πριν από την έναρξη της δοκιμής. Είναι πάντα καλή ιδέα να παρακολουθείτε τις αλλαγές που παρέχονται ως μέρος κάθε κατασκευής.

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

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

Κατασκευή και ανάπτυξη

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

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

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

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

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

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

# 4. Προγραμματισμένη εναντίον έκτακτης ανάγκης

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

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

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

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

# 5. Λίστα ελέγχου QA - Πριν και μετά την ανάπτυξη

Πριν από την ανάπτυξη -

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

  • Βεβαιωθείτε ότι οι δοκιμαστικές περιπτώσεις ελέγχονται και εγκρίνονται
  • Βεβαιωθείτε ότι η ομάδα δοκιμών είναι διαθέσιμη και ότι ο προγραμματισμός πόρων έχει ολοκληρωθεί
  • Βεβαιωθείτε ότι το προσδιορίζονται οι ανάγκες δεδομένων δοκιμής

Μετά την ανάπτυξη -

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

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

συμπέρασμα

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

Συντάκτης : Αυτό το φοβερό άρθρο γράφτηκε από το μέλος της ομάδας STH Priya R.

Βρήκατε αυτή τη διαδικασία χρήσιμη; Ενημερώστε μας για τη διαδικασία ανάπτυξης που ακολουθείτε στον οργανισμό σας.

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

^