Μενού

Refactoring κώδικα: Τι πρέπει να γνωρίζετε για αυτό

code refactoring what you need know about it

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

Κατανόηση του Refactoring Code: Προοπτική ενός Tester

Ο όρος «Refactoring» χρησιμοποιείται κυρίως για να υποδείξει τον απαιτούμενο κώδικα καθαρισμού / επανασχεδιασμού.

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

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

Ανακατασκευή κώδικα

Τι θα μάθετε:

Εισαγωγή στο Refactoring

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

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

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

Ανάγκη για αναδιαμόρφωση κώδικα

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

  1. Ο κώδικας μυρίζει
  2. Τεχνικό χρέος
  3. Ευέλικτη προσέγγιση ανάπτυξης λογισμικού κ.λπ.

Θα συζητήσουμε αυτά τα σημεία λεπτομερώς στις ακόλουθες ενότητες.

# 1) Μυρίζει κώδικα:

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

Ακολουθούν μερικές κοινές μυρωδιές κώδικα:

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

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

# 2) Τεχνικό χρέος:

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

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

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

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

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

Διαβάστε περισσότερα=> Τι είναι το τεχνικό τμήμα

# 3) Ακολουθώντας την προσέγγιση ανάπτυξης λογισμικού Agile:

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

Αυτή η σχέση απεικονίζεται στο παρακάτω διάγραμμα

Προσέγγιση ανάπτυξης λογισμικού Agile

Συνιστώμενη ανάγνωση => Κορυφαία εργαλεία ανάλυσης κώδικα

Γιατί ένα QA πρέπει να ξέρει για το Refactoring;

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

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

# 1) Για ελεγκτές μονάδων / προγραμματιστές

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

# 2) Για δοκιμαστές

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

  • Ως δοκιμαστής, η αναδιαμόρφωση του κώδικα μεταφράζεται κατά προσέγγιση σε = σε βάθος δοκιμή + δοκιμή παλινδρόμησης. Σε βάθος δοκιμές πρέπει να περιλαμβάνονται όλες οι υπάρχουσες ροές χρηστών για να διασφαλιστεί ότι όλες οι λειτουργίες λειτουργούν όπως πριν. Δοκιμή παλινδρόμησης Απαιτείται ολόκληρη η εφαρμογή (ή περιοχές που επηρεάζονται) για να διασφαλιστεί ότι η αναβάθμιση μιας λειτουργικής μονάδας δεν έσπασε ακούσια τη λειτουργικότητα των άλλων ενοτήτων.
  • Οι δοκιμές αποδοχής χρηστών θα είναι σημαντικές και αυτές οι δοκιμές πρέπει να περάσουν προτού η έκδοση μπορεί να κηρυχθεί έτοιμη για κυκλοφορία.
  • Επιπλέον, απαιτείται οποιαδήποτε άλλη δοκιμή όπως δοκιμές φορτίου, δοκιμή ασφαλείας κ.λπ. θα πρέπει επίσης να εφαρμοστούν όπως απαιτείται.

# 3) Μηχανικοί δοκιμής αυτοματισμού

Η αναδιαμόρφωση του κώδικα ενδέχεται να προκαλέσει αποτυχία λειτουργικών και μη λειτουργικών σεναρίων αυτοματισμού.

Αυτό μπορεί να συμβεί για τους ακόλουθους λόγους:

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

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

Όντας προγραμματιστές δοκιμών αυτοματισμού, οι μηχανικοί δοκιμών αυτοματισμού πρέπει επίσης να σκέφτονται σαν προγραμματιστές και να στοχεύουν στη δημιουργία ενός καθαρού και εύχρηστου κώδικα. Τα περισσότερα από τα IDE, όπως το IntelliJ IDEA, το Eclipse κ.λπ., περιλαμβάνουν ενσωματωμένο μενού αναδιαμόρφωσης με κοινές μεθόδους αναδιάρθρωσης για εύκολη αναφορά.

Ακολουθεί ένα στιγμιότυπο οθόνης του μενού refactoring στο IntelliJ IDEA (Community Edition).

ερωτήσεις και απαντήσεις συνέντευξης php για 2ετή εμπειρία

μενού ανακατασκευής

# 4) Για δοκιμαστικούς οδηγούς / QA Leads

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

Οι περιπτωσιολογικές μελέτες

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

Μελέτη περίπτωσης # 1

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

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

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

Μελέτη περίπτωσης # 2

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

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

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

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

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

Προκλήσεις:

# 1) Διαχειριστής έργου / Αναλυτής προϊόντος

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

# 2) Για προγραμματιστές

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

# 3) Για δοκιμαστές

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

# 4) Ενδιαφερόμενοι

  • Έλλειψη σαφών τεκμηριωμένων απαιτήσεων ή / και ροών χρηστών + αυστηρές προθεσμίες = Υψηλότερος κίνδυνος αποτυχίας.

Η προσέγγιση που ακολούθησε η ομάδα για τον μετριασμό των κινδύνων και την αντιμετώπιση των προκλήσεων :

(i) Η ομάδα ακολούθησε μια συνεργατική προσέγγιση για τη συλλογή απαιτήσεων : Ο υπεύθυνος έργου / αναλυτής προϊόντων και οι υπεύθυνοι δοκιμών συνεργάστηκαν στενά με τους εσωτερικούς τελικούς χρήστες για να κατανοήσουν και να τεκμηριώσουν την κύρια λειτουργικότητα και τη ροή των χρηστών.

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

(ii) Το εναλλακτικό περιβάλλον δοκιμής δημιουργήθηκε για να δοκιμάσει την αλλαγή που εφαρμόζεται : Ας ονομάσουμε αυτά τα περιβάλλοντα ως Gamma και Phi. Το Gamma θα είχε τον παλιό κωδικό και το Phi θα είχε την τελευταία επανακατασκευασμένη αποθηκευμένη διαδικασία που θα εφαρμοζόταν ανά πάσα στιγμή.

Έχοντας παράλληλα 2 περιβάλλοντα δοκιμών, σχεδόν αναδημιουργία πριν - και - μετά την προσέγγιση, επέτρεψε στην ομάδα να κάνει πιο σε βάθος και διερευνητικές δοκιμές συγκρίνοντας τη συμπεριφορά σε αυτά τα 2 περιβάλλοντα δοκιμών, μπόρεσαν να εντοπίσουν τα πιθανά σφάλματα.

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

(iii) Τελικοί χρήστες και ενδιαφερόμενοι που συμμετέχουν στις δοκιμές από νωρίς : Τυχόν προφανή ζητήματα εντοπίστηκαν και αναφέρθηκαν νωρίς, επιτρέποντας περισσότερο χρόνο στην ομάδα να αναπτύξει και να δοκιμάσει την απαιτούμενη διόρθωση.

(iv) Καθορισμός κριτηρίων εξόδου και τήρηση αυτών: Τα κριτήρια εξόδου καθορίστηκαν στα αρχικά στάδια προγραμματισμού - δοκιμή ροών χρηστών 80%, χωρίς επίλυση σημαντικών σφαλμάτων, επίδειξη και υπογραφή από τους ενδιαφερόμενους πριν από την κυκλοφορία.

(v) Καθορισμός προσωρινής ημερομηνίας κυκλοφορίας: Ορισμός ημερομηνίας κυκλοφορίας ευθυγραμμισμένος και παρακινώντας την ομάδα να εργαστεί προς ένα κοινό τελικό σημείο. Με βάση το εύρος του έργου, προτάθηκε από την ομάδα να ακολουθηθεί ένα σπριντ 3 εβδομάδων αντί για ένα κανονικό σπριντ 2 εβδομάδων για να δοθεί επαρκής χρόνος για την εκτέλεση της εργασίας από την ομάδα.

συμπέρασμα

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

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

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

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

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

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

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

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

^