Τι είναι ο έλεγχος αποδοχής χρήστη (UAT): Ένας πλήρης οδηγός

what is user acceptance testing

Μάθετε τι είναι ο έλεγχος αποδοχής χρήστη (UAT), μαζί με τον ορισμό, τους τύπους, τα βήματα και τα παραδείγματα:

Ο πρώτος κανόνας μου όταν προσπαθώ να καταλάβω μια νέα ιδέα είναι ότι: το όνομα θα είναι πάντα σχετικό και ως επί το πλείστον μια κυριολεκτική έννοια (στο τεχνικό πλαίσιο).

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

Η προεπιλεγμένη πύλη δεν βρέθηκε Windows 10

=> Κάντε κλικ εδώ για πλήρη σειρά εκπαιδευτικών σειρών

Ας δοκιμάσουμε αυτήν την ιδέα.

=> Διαβάστε όλα τα σεμινάρια στη σειρά δοκιμών αποδοχής.

Τι θα μάθετε:

• Τι είναι ο έλεγχος αποδοχής χρήστη;
  • Πότε εκτελείται;
  • Ποιος εκτελεί UAT;
  • Ανάγκη για δοκιμή αποδοχής χρήστη
  • Διαδικασία δοκιμής αποδοχής χρήστη
  • Διακυβέρνηση UAT
  • Προγραμματισμός δοκιμών UAT
  • Σχεδιασμός δοκιμών αποδοχής χρήστη
  • Εκτέλεση δοκιμής
  • Εργαλεία & Μεθοδολογίες
  • UAT στο ευέλικτο περιβάλλον
  • Ομάδα UAT - Ρόλοι & Ευθύνες
• 7 προκλήσεις του προγράμματος UAT και μετριασμού
• Δοκιμή συστήματος έναντι δοκιμής αποδοχής χρήστη
• συμπέρασμα
  • Συνιστώμενη ανάγνωση

Τι είναι ο έλεγχος αποδοχής χρήστη;

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

Έτσι, ακολουθώντας τον κανόνα μου - ο ορισμός θα είναι:

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

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

UAT, δοκιμή alpha και beta είναι διαφορετικοί τύποι δοκιμών αποδοχής.

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

Πότε εκτελείται;

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

Ποιος εκτελεί UAT;

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

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

Ανάγκη για δοκιμή αποδοχής χρήστη

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

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

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

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

Είναι πραγματικά απαραίτητο το UAT;

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

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

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

Διαδικασία δοκιμής αποδοχής χρήστη

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

Τα ακόλουθα είναι τα προαπαιτούμενα πριν ξεκινήσει η φάση προγραμματισμού:

# 1) Συγκεντρώστε τα βασικά κριτήρια αποδοχής

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

Αυτά μπορεί να είναι 2 τύπων:

(i) Λειτουργικότητα εφαρμογής ή σχετική με την επιχείρηση

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

(ii) Συμβατική - Δεν πρόκειται να το κάνουμε και η συμμετοχή της ομάδας QA σε όλα αυτά δεν είναι σχεδόν τίποτα. Το αρχικό συμβόλαιο που καταρτίζεται πριν από την έναρξη του SDLC επανεξετάζεται και επιτυγχάνεται συμφωνία σχετικά με το εάν έχουν παραδοθεί όλες οι πτυχές του συμβολαίου ή όχι.

Θα επικεντρωθούμε μόνο στη λειτουργικότητα της εφαρμογής.

# 2) Ορίστε το εύρος της συμμετοχής QA.

Ο ρόλος της ομάδας QA είναι ένας από τους ακόλουθους:

(i) Χωρίς συμμετοχή - Αυτό είναι πολύ σπάνιο.

(ii) Βοηθήστε σε αυτήν τη δοκιμή - Το συνηθέστερο. Σε αυτήν την περίπτωση, η συμμετοχή μας θα μπορούσε να εκπαιδεύσει τους χρήστες του UAT σχετικά με τον τρόπο χρήσης της εφαρμογής και να είναι σε κατάσταση αναμονής κατά τη διάρκεια αυτής της δοκιμής για να βεβαιωθούμε ότι μπορούμε να βοηθήσουμε τους χρήστες σε περίπτωση δυσκολίας. Ή σε ορισμένες περιπτώσεις, εκτός από το ότι είμαστε σε κατάσταση αναμονής και βοήθειας, ενδέχεται να μοιραστούμε τις απαντήσεις τους και να καταγράψουμε τα αποτελέσματα ή σφάλματα καταγραφής κ.λπ., ενώ οι χρήστες εκτελούν την πραγματική δοκιμή.

(iii) Εκτέλεση UAT και παρουσίαση αποτελεσμάτων - Εάν συμβαίνει αυτό, οι χρήστες θα επισημάνουν τους τομείς του AUT που θέλουν να αξιολογήσουν και η ίδια η αξιολόγηση πραγματοποιείται από την ομάδα QA. Μόλις ολοκληρωθούν, τα αποτελέσματα παρουσιάζονται στους πελάτες / χρήστες και θα λάβουν μια απόφαση σχετικά με το εάν τα αποτελέσματα που έχουν στο χέρι είναι επαρκή ή όχι και σύμφωνα με τις προσδοκίες τους για να αποδεχτούν το AUT. Η απόφαση δεν είναι ποτέ η ομάδα της QA.

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

Οι πρωταρχικοί στόχοι και προσδοκίες:

Συνήθως, το UAT αναλαμβάνεται από έναν Ειδικό Θέματος (ΜΜΕ) ή / και έναν επιχειρηματικό χρήστη, ο οποίος μπορεί να είναι ο ιδιοκτήτης ή ο πελάτης ενός υπό δοκιμή συστήματος. Παρόμοια με τη φάση δοκιμής του συστήματος, η φάση UAT περιλαμβάνει επίσης θρησκευτικές φάσεις προτού τερματιστεί.

Οι βασικές δραστηριότητες κάθε φάσης UAT ορίζονται παρακάτω:

Διακυβέρνηση UAT

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

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

Προγραμματισμός δοκιμών UAT

Η διαδικασία είναι σχεδόν ίδια με εκείνη του κανονικό σχέδιο δοκιμών στη φάση του συστήματος.

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

Πρόγραμμα δοκιμής αποδοχής χρήστη

δωρεάν λήψη λογισμικού λήψης βίντεο youtube

(Αυτό είναι το ίδιο που θα βρείτε στον ιστότοπό μας και για τη σειρά εκπαίδευσης QA).

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

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

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

=> Ακολουθεί ένα δείγμα εγγράφου σχεδίου δοκιμής αποδοχής χρήστη

Σχεδιασμός δοκιμών αποδοχής χρήστη

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

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

Πρότυπο δοκιμής αποδοχής χρήστη:

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

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

Εκτέλεση δοκιμής

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

Ή σε περίπτωση που η ομάδα QA εκτελέσει τις δοκιμές, εκτελούμε τις δοκιμαστικές θήκες στο AUT.

Μόλις εκτελεστούν όλες οι δοκιμές και τα αποτελέσματα είναι διαθέσιμα, το Απόφαση αποδοχής είναι φτιαγμένο. Αυτό ονομάζεται επίσης το Απόφαση Go / No-Go . Εάν οι χρήστες είναι ικανοποιημένοι, είναι Go, ή αλλιώς είναι No-go.

Η επίτευξη της απόφασης αποδοχής είναι συνήθως το τέλος αυτής της φάσης.

Εργαλεία & Μεθοδολογίες

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

Εργαλεία:

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

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

Μεθοδολογίες:

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

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

Δοκιμή πλήθους είναι μια μεθοδολογία όπου άτομα από όλο τον κόσμο μπορούν να συμμετάσχουν και να επικυρώσουν τη χρήση του προϊόντος και να δώσουν προτάσεις και προτάσεις.

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

Η μεθοδολογία Crowd Testing αποδεικνύεται πιο αποτελεσματική καθώς ο παλμός του πελάτη σε όλο τον κόσμο μπορεί εύκολα να γίνει κατανοητός.

UAT στο ευέλικτο περιβάλλον

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

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

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

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

Ομάδα UAT - Ρόλοι & Ευθύνες

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

7 προκλήσεις του προγράμματος UAT και μετριασμού

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

# 1) Διαδικασία ρύθμισης και ανάπτυξης περιβάλλοντος:

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

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

μετατροπέας youtube σε mp3 που λειτουργεί

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

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

# 2) Προγραμματισμός δοκιμών:

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

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

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

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

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

# 3) Διαχείριση νέων επιχειρηματικών απαιτήσεων ως περιστατικά / ελαττώματα:

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

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

# 4) Μη ειδικευμένοι υπεύθυνοι δοκιμών ή δοκιμαστές χωρίς επιχειρηματική γνώση:

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

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

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

# 5) Ακατάλληλο κανάλι επικοινωνίας:

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

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

# 6) Ζητώντας από τη λειτουργική ομάδα δοκιμών να πραγματοποιήσει αυτόν τον έλεγχο:

Δεν υπάρχει χειρότερη κατάσταση από το να ζητήσετε από τη λειτουργική ομάδα δοκιμών να εκτελέσει UAT.

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

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

# 7) Το παιχνίδι Blame

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

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

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

Δοκιμή συστήματος έναντι δοκιμής αποδοχής χρήστη

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

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

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

συμπέρασμα

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

#δύο) Αυτός ο έλεγχος αφορά την οντότητα που αποτελεί το κύριο στοιχείο της επιχείρησης.

Επιτρέψτε μου να σας δώσω ένα παράδειγμα: Εάν το AUT είναι ένα σύστημα έκδοσης εισιτηρίων, το UAT δεν πρόκειται να κάνει, αναζητώντας το μενού που ανοίγει μια σελίδα κ.λπ. Αφορά τα εισιτήρια και την κράτησή τους, τις καταστάσεις που μπορεί να λάβει, το ταξίδι του μέσω του συστήματος, και τα λοιπά.

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

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

Η απόφαση θα ήταν είτε:

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

# 4) Το UAT ταξινομείται ως δοκιμή Alpha και Beta, αλλά αυτή η ταξινόμηση δεν είναι τόσο σημαντική στο πλαίσιο τυπικών έργων ανάπτυξης λογισμικού σε μια βιομηχανία που βασίζεται σε υπηρεσίες.

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

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

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

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

Ποια ήταν η εμπειρία σας στο UAT; Ήσασταν σε κατάσταση αναμονής ή δοκιμάσατε τους χρήστες σας; Βρήκαν οι χρήστες προβλήματα; Εάν ναι, πώς τα αντιμετωπίσατε;

=> Διαβάστε επίσης ΟΛΑ τα σεμινάρια αυτής της σειράς εδώ

=> Επισκεφτείτε εδώ για την ολοκληρωμένη σειρά μαθημάτων δοκιμαστικών σχεδίων

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

• Δοκιμή άλφα και δοκιμή beta (Ένας πλήρης οδηγός)
• Τι είναι ο έλεγχος αποδοχής (ένας πλήρης οδηγός)
• Πλήρης οδηγός δοκιμής επαλήθευσης έκδοσης (BVT Testing)
• Λειτουργική δοκιμή εναντίον μη λειτουργική δοκιμή
• Τα καλύτερα εργαλεία δοκιμής λογισμικού 2021 (QA Test Automation Tools)
• Τύποι δοκιμών λογισμικού: Διαφορετικοί τύποι δοκιμών με λεπτομέρειες
• Εγχειρίδιο δοκιμών αποθήκης δεδομένων δοκιμών ETL (ένας πλήρης οδηγός)
• Οδηγός δοκιμών GUI: Ένας πλήρης οδηγός δοκιμών διεπαφής χρήστη (UI)