Μενού

Πώς αποφασίζετε ποια ελαττώματα είναι αποδεκτά ώστε το λογισμικό να μεταδοθεί ζωντανά;

how do you decide which defects are acceptable

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

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

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

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

Ενώ, αυτές είναι εξαιρετικές ακουστικές οδηγίες, είναι ασαφείς.

λογισμικό-go-live-κριτήρια

Για να γινω πιο συγκεκριμενη:

  • Ποιο ποσοστό ελαττωμάτων είναι αποδεκτό για να μεταδοθεί το λογισμικό;
  • Πώς αποφασίζετε για τα ανοιχτά ελαττώματα με τα οποία μπορεί να γίνει ζωντανό το λογισμικό;
  • Τι είδη ελαττωμάτων είναι πιο σοβαρά από τα άλλα;

Συνιστώμενη ανάγνωση => Πότε πρέπει να σταματήσετε τις δοκιμές;

Είχατε ποτέ αυτές τις ερωτήσεις; Στη συνέχεια, αυτό το άρθρο θα σας βοηθήσει να τους απαντήσετε. Συνέχισε να διαβάζεις…

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

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

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

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

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

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

  1. Λειτουργικός
  2. Απόδοση και φορτίο
  3. Ευχρηστία
  4. Ασφάλεια
  5. Ενσωμάτωση με εξωτερικά συστήματα
  6. Αναφορές
  7. Μετεγκατάσταση δεδομένων

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

δωρεάν λογισμικό αντιγραφής DVD για Windows 10

# 1. Λειτουργικά ελαττώματα:

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

Λειτουργικά ελαττώματα στη συνέχεια ταξινομούνται σύμφωνα με σοβαρότητα και προτεραιότητα .

Τα ακόλουθα είναι σημαντικά ζητήματα:

  • Τα ελαττώματα υψηλής σοβαρότητας και προτεραιότητας είναι συνήθως αυτά που επηρεάζουν την καθημερινή χρήση του λογισμικού. Αυτοί οι τύποι ελαττωμάτων είναι αυτοί που πρέπει να επιδιορθωθούν πριν ξεκινήσουμε. Χωρίς εξαιρέσεις.
  • Μερικές φορές τα Λειτουργικά ελαττώματα ταξινομούνται ως Αίτηση Αλλαγής, καθώς δεν ήταν μέρος των αρχικά δοθέντων απαιτήσεων. Τέτοια CR, που είναι απαραίτητη για την εργασία της επιχείρησης μετά το Go-live, είναι επίσης απαραίτητη.
  • Η ταξινόμηση των ελαττωμάτων και η ιεράρχηση των λειτουργικών ελαττωμάτων γίνεται από τους συντονιστές του UAT σε συνεργασία με επιχειρηματικούς χρήστες και επιχειρηματικούς αναλυτές. Συνήθως, ο πελάτης έχει κριτήρια εξόδου για το πόσο% των ελαττωμάτων μπορεί να είναι ανοιχτό για ζωντανή μετάδοση.

# 2. Ελαττώματα απόδοσης και φόρτωσης:

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

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

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

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

  • Η απόδοση μετριέται συνήθως από την άποψη του χρόνου απόκρισης των οθονών για απόδοση και διάθεση στους χρήστες, ενώ υπάρχει ορισμένος αριθμός ταυτόχρονων χρηστών στο σύστημα.
  • Οι δοκιμές απόδοσης γίνονται χρησιμοποιώντας εργαλεία όπως LoadRunner , Φόρτωση Web , Neoload κ.λπ.
  • Η απόδοση του λογισμικού σε ένα δεδομένο φορτίο και σε ένα μελλοντικό προβλεπόμενο φορτίο τεκμηριώνεται συνήθως στη σύμβαση και πρέπει να αποδειχθεί πριν από τη ζωντανή μετάδοση.
  • Οι οθόνες ή τα τμήματα της εφαρμογής που χρησιμοποιούνται λιγότερο από τους χρήστες μεταφέρονται σε αξιολογήσεις μετά το live.
  • Η απόδοση εξαρτάται επίσης από τον τύπο του υλικού και τις συνθήκες δικτύου στο οποίο αναπτύσσεται το λογισμικό.
  • Οι δοκιμές απόδοσης γίνονται κατά τη διάρκεια του UAT στο καθορισμένο υλικό χρησιμοποιώντας εργαλεία απόδοσης και τα ελαττώματα τους παρακολουθούνται με τρόπο παρόμοιο με αυτό των λειτουργικών ελαττωμάτων. Έχουν επίσης προτεραιότητα και επιτυγχάνεται συναίνεση για την εκπλήρωση των κριτηρίων εξόδου για το live-live.
  • Συνήθως, οι δοκιμές απόδοσης και φόρτωσης στο UAT πραγματοποιούνται μετά την ολοκλήρωση του λειτουργικού UAT από τους επιχειρηματικούς χρήστες και επιτυγχάνεται ένα αποδεκτό κριτήριο εξόδου για λειτουργικά ελαττώματα.

# 3. Ελαττώματα χρηστικότητας:

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

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

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

# 4. Ελαττώματα ασφαλείας:

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

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

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

# 5. Ενσωμάτωση με εξωτερικά συστήματα λογισμικού:

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

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

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

# 6. Αναφορές:

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

Για παράδειγμα: όλα τα δεδομένα που σχετίζονται με τις χρεώσεις πρέπει να αντιστοιχούν στα υπόλοιπα πίστωσης και χρέωσης.

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

# 7. Μετεγκατάσταση δεδομένων:

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

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

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

Ένα παράδειγμα κριτηρίων εξόδου για το live-live:

Αυτό είναι απλώς ένα παράδειγμα. Μπορεί να διαφέρει από έργο σε έργο.

  • 100% των ελαττωμάτων προτεραιότητας 1 είναι κλειστά (σοβαρότητα σοβαρότητας και προτεραιότητα 1)
  • Το 90% των ελαττωμάτων προτεραιότητας 2 είναι κλειστά (υψηλή σοβαρότητα και προτεραιότητα 2) με μια λογική λύση να είναι διαθέσιμη για το υπόλοιπο του 10% των ελαττωμάτων. Και, υπάρχει ένα σχέδιο για το κλείσιμο του υπόλοιπου 10% των ελαττωμάτων.
  • Η λίστα παραγωγής και ανάπτυξης λογικής είναι έτοιμη.
  • Δημιουργήθηκε ομάδα υποστήριξης παραγωγής και έτοιμη για κλείσιμο εισιτηρίων.
  • Το 70% των ελαττωμάτων προτεραιότητας 3 είναι κλειστά και υπάρχει ένα σχέδιο για το κλείσιμο του υπολοίπου του 30% των χαμηλών ελαττωμάτων.

Μερικά σημεία που πρέπει να σημειώσετε:

  • Όλοι οι ορισμοί σοβαρότητας και προτεραιότητας αποφασίζονται κατά τη διάρκεια των επιχειρηματικών συναντήσεων μεταξύ του πελάτη και του πωλητή κατά την έναρξη του προγράμματος.
  • Αφού καταγραφούν όλα τα ελαττώματα UAT και κλείνουν όλα τα άλλα ελαττώματα, οι συντονιστές UAT και οι χορηγοί επιχειρήσεων συναντιούνται για να αποθέσουν τα εκκρεμή και ανοιχτά ελαττώματα. Εάν όλα τα ελαττώματα που απαιτούνται για το Day-1 go-live είναι κλειστά, οι χορηγοί επιχειρήσεων βλέπουν την ετοιμότητά τους για ζωντανή μετάδοση και κάνουν το λογισμικό σε παραγωγή.

Συμπερασματικά

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

Σχετικά με τον Συγγραφέα: Αυτό είναι ένα άρθρο επισκεπτών του Krishnan Venkatraman. Έχει σχεδόν 18 χρόνια εμπειρίας στις δοκιμές λογισμικού. Έχει εργαστεί σε πολλά μεγάλα και περίπλοκα προγράμματα δοκιμών λογισμικού.

Μη διστάσετε να δημοσιεύσετε τα ερωτήματα / τα σχόλιά σας παρακάτω.

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

^