Ο απόλυτος οδηγός για τη δοκιμή βάσει κινδύνου: Διαχείριση κινδύνων στη δοκιμή λογισμικού

ultimate guide risk based testing

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

Τι είναι ο έλεγχος βάσει κινδύνου;

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

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

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

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

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

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

Τι θα μάθετε:

• Δοκιμή βάσει κινδύνου και η συνάφειά του με το Agile & DevOps
  • Προσέγγιση δοκιμών βάσει κινδύνου
    • Πότε χρησιμοποιούμε την προσέγγιση RBT;
    • Παράδειγμα προσέγγισης RBT
  • Τρόποι διεξαγωγής ανάλυσης κινδύνου
  • Διαδικασία Ανάλυσης Κινδύνου
  • Μεθοδολογία Ανάλυσης Κινδύνου
    • Βήμα 1) Χρήση πλέγματος 3Χ3
    • Βήμα 2) Πιθανότητα και επιπτώσεις της αποτυχίας
    • Βήμα # 3) Δοκιμή πλέγματος προτεραιότητας
    • Βήμα # 4) Λεπτομέρειες δοκιμών
  • Πώς σχετίζεται το RBT με το Agile και το DevOps;
  • Οφέλη της προσέγγισης δοκιμής βάσει κινδύνου
• Διαχείριση κινδύνων κατά τον προγραμματισμό δοκιμών
  • Διαδικασία Διαχείρισης Κινδύνων
    • # 1) Αναγνώριση κινδύνου
    • # 2) Εκτίμηση Κινδύνου / Ανάλυση Επιπτώσεων Κινδύνου
    • # 3) Μείωση των κινδύνων
  • συμπέρασμα
• Διαχείριση κινδύνων στη φάση εκτέλεσης δοκιμής (με παράδειγμα)
  • Διαχείριση κινδύνων - με έμφαση στο AUT
  • Πώς πραγματοποιείται ο έλεγχος βάσεων κινδύνου;
  • συμπέρασμα
  • Συνιστώμενη ανάγνωση

Δοκιμή βάσει κινδύνου και η συνάφειά του με το Agile & DevOps

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

Αυτό, με τη σειρά του, μπορεί να καταστρέψει το σκοπό ολόκληρου του προϊόντος χωρίς άλλη επιλογή, αλλά απλώς να το αποσύρει από την αγορά. Και αυτή είναι η σημασία και η ανάγκη για «Δοκιμή ποιότητας».

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

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

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

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

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

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

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

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

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

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

# 1) Εστίαση στην περιοχή του προϊόντος όπου υπάρχει μεγάλη επίδραση στην επιχείρηση λόγω αποτυχίας ή μεγάλης πιθανότητας αποτυχίας στην παραγωγή.

#δύο) Εστίαση εντοπισμός των ελαττωμάτων νωρίς και επιτρέποντας σε μια ομάδα να το επιδιορθώσει όσο το δυνατόν νωρίτερα και επομένως επιτρέπει στο λογισμικό / το προϊόν ή τη δυνατότητα «Αποτυχία γρήγορα».

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

Προσέγγιση δοκιμών βάσει κινδύνου

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

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

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

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

Έτσι, εάν επικεντρωθούμε στην παραπάνω πτυχή, τότε το έργο ενός QA θα ανακουφιστεί πολύ. Δεν χρειάζεται να κάψουν τα σαββατοκύριακά τους στο γραφείο, να ελέγχουν συνεχώς το λογισμικό και να ανησυχούν για κάθε ελαττωματικό S4 (Severity 4) και P4 (Priority 4) που προκύπτει από τη δοκιμή.

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

Για να συνοψίσουμε τους βασικούς παράγοντες της προσέγγισης «Δοκιμή βάσει κινδύνου»:

• Για να επιτρέψετε τη δοκιμή «τι θέλουν οι πελάτες» από επιχειρηματική άποψη.
• Για να ανταποκριθείτε στο χρονοδιάγραμμα με την αναμενόμενη ποιότητα.
• Για βελτιστοποίηση της προσπάθειας QA.

Πότε χρησιμοποιούμε την προσέγγιση RBT;

Αυτό χρησιμοποιείται στα παρακάτω σενάρια:

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

Παράδειγμα προσέγγισης RBT

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

Παρακάτω δίνεται μια τέτοια προσέγγιση:

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

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

Τρόποι διεξαγωγής ανάλυσης κινδύνου

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

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

• Χαρακτηριστικά
• Λειτουργίες
• Ιστορίες χρηστών
• Απαιτήσεις
• Χρησιμοποιήστε Θήκες
• Θήκες δοκιμής

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

Διαδικασία Ανάλυσης Κινδύνου

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

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

Διάφορα «Έγγραφα Έργου», όπως Έγγραφο Απαιτήσεων, Έγγραφα Τεχνικών Προδιαγραφών, Έγγραφα Αρχιτεκτονικής και Σχεδιασμού, Έγγραφο Επιχειρηματικής Διαδικασίας, Έγγραφο Περίπτωσης Χρήσης κ.λπ., θα γίνουν η είσοδος για τη συνεδρία ανταλλαγής ιδεών.

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

Λίγες άλλες πηγές εισόδων μπορούν επίσης να περιλαμβάνουν,

• Για να συλλέξετε εισόδους για τη λειτουργικότητα που χρησιμοποιείται περισσότερο.
• Είσοδοι από διαβούλευση με έναν ειδικό τομέα.
• Δεδομένα από την προηγούμενη έκδοση του προϊόντος ή παρόμοιου προϊόντος στην αγορά.

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

Η «πιθανότητα εμφάνισης κινδύνου» μπορεί να οφείλεται σε:

• Κακή κατανόηση του χαρακτηριστικού από την ομάδα ανάπτυξης προϊόντων.
• Ακατάλληλη αρχιτεκτονική και σχεδιασμός.
• Ανεπαρκής χρόνος σχεδιασμού.
• Αδυναμία της ομάδας.
• Ανεπαρκείς πόροι - άτομα, εργαλεία και τεχνολογία.

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

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

Ο τομέας εστίασης της εκτίμησης του κινδύνου ενός χαρακτηριστικού ή προϊόντος μπορεί να είναι,

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

Μεθοδολογία Ανάλυσης Κινδύνου

Ας κατανοήσουμε λεπτομερώς τη «Μεθοδολογία δοκιμών βάσει κινδύνων» τώρα.

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

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

Ο κύριος στόχος της ανάλυσης κινδύνου είναι να γίνει διάκριση μεταξύ του 'Υψηλή αξία' στοιχεία όπως χαρακτηριστικά προϊόντος, λειτουργίες, απαιτήσεις, ιστορίες χρηστών , και δοκιμαστικές περιπτώσεις, και Χαμηλής αξίας' αυτές και ως εκ τούτου αργότερα να εστιάσετε περισσότερο στις δοκιμές «υψηλής αξίας», εστιάζοντας λιγότερο στις δοκιμές «χαμηλής αξίας». Αυτό είναι το αρχικό βήμα της ανάλυσης κινδύνου πριν ξεκινήσετε τη δοκιμή βάσει κινδύνου.

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

Βήμα 1) Χρήση πλέγματος 3Χ3

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

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

απλός αλγόριθμος ταξινόμησης c ++

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

Βήμα 2) Πιθανότητα και επιπτώσεις της αποτυχίας

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

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

Βήμα # 3) Δοκιμή πλέγματος προτεραιότητας

Με βάση την παραπάνω τοποθέτηση των δοκιμαστικών περιπτώσεων στο πλέγμα, οι δοκιμές έχουν προτεραιότητα και επισημαίνονται με προτεραιότητες 1,2,3,4 και 5 και επισημαίνονται έναντι καθεμιάς από αυτές. Οι πιο σημαντικές δοκιμές τοποθετούνται σε 1^αγπλέγμα που έχουν εκχωρηθεί με προτεραιότητα 1 και παρόμοια λιγότερο σημαντικά ταξινομούνται ως 2, 3, 4 και 5.

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

Βήμα # 4) Λεπτομέρειες δοκιμών

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

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

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

Πώς σχετίζεται το RBT με το Agile και το DevOps;

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

«Αυτοματοποιήστε τα πάντα», «Δοκιμή τα πάντα», «Συνεχής δοκιμή», «Δοκιμή επανειλημμένα» είναι οι βασικές έννοιες αυτών των πρακτικών.

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

Τότε ποια είναι η σχέση μεταξύ RBT και DevOps; Πού θα ταίριαζε το RBT και θα γινόταν σχετικό στο Agile και στο DevOps;

# 1) Ναι, όπως είπα νωρίτερα, δεν είναι ότι κάθε Βιομηχανία και κάθε προϊόν έχει κάλυψη αυτοματισμού 100% για τις δοκιμαστικές εκτελέσεις τους. Επομένως, εάν καθόλου η ομάδα πρέπει να επιλέξει την προτεραιότητα για την εκτέλεση δοκιμών από την επιλογή χειροκίνητων δοκιμαστικών περιπτώσεων και θα ήθελε να εξοικονομήσει ενέργεια και προσπάθεια των πόρων δοκιμής σε άλλες δραστηριότητες, τότε το RBT είναι η καλύτερη επιλογή.

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

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

# 3) Η προσέγγιση RBT μπορεί να χρησιμοποιηθεί αποτελεσματικά στο σχεδιασμό των δοκιμαστικών περιπτώσεων και των σεναρίων με βάση τον υψηλό κίνδυνο, έτσι ώστε να μπορεί να δοθεί περισσότερη εστίαση σε χαρακτηριστικά και λειτουργίες υψηλού κινδύνου.

# 4) Ο προσδιορισμός των περιοχών «Υψηλού Κινδύνου» δίνει τη δυνατότητα στην ομάδα QA να επικεντρώσει τις δοκιμές της σε αυτές τις περιοχές για να δοκιμάσει «Πιο λεπτομερώς» χρησιμοποιώντας τους «Υψηλούς Ικανότητες».

# 5) Το 'Fail Fast', όπως όλοι γνωρίζουμε είναι η έννοια του 'Agile' και του 'DevOps', για τις οποίες η προσέγγιση RBT βοηθά στον εντοπισμό των περιοχών 'υψηλού κινδύνου' στο λογισμικό, στον εντοπισμό των ελαττωμάτων νωρίς και επιτρέποντάς τους να αποτύχουν γρήγορα και να αποτύχουν πρώτα και αφήστε την ομάδα να το διορθώσει.

# 6) Ο απώτερος στόχος του Agile / DevOps είναι η «εστίαση των πελατών» και ως εκ τούτου η προσέγγιση RBT επιτρέπει στο QA να επικεντρώνεται στην εμπειρία των πελατών παρά να εντοπίζει ελαττώματα.

Οφέλη της προσέγγισης δοκιμής βάσει κινδύνου

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

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

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

• Βοηθά στην πιο αποτελεσματική και βελτιστοποιημένη χρήση των πόρων δοκιμής.
• Βοηθά στη διευκόλυνση των εργασιών QA, των δοκιμών, του σχεδιασμού και της ανάπτυξης δοκιμών και των δραστηριοτήτων προετοιμασίας δοκιμών με προτεραιότητα.
• Βοηθά στην καλύτερη διαχείριση των πόρων QA κατανέμοντας τους βασικούς πόρους σε περιοχές υψηλής εστίασης.
• Βοηθά στην αποτελεσματική αξιοποίηση των πόρων και εκτρέπει το χρόνο και την ενέργειά τους σε καλύτερα πράγματα στο έργο.
• Βοηθά την ομάδα QA στο σχεδιασμό των προσπαθειών δοκιμών με βάση την εκτίμηση κινδύνου και τον προσδιορισμό των πτητικών και υψηλού κινδύνου περιοχών.
• Βοηθά την ομάδα να βελτιστοποιήσει τις δοκιμές που θα διεξαχθούν ανάλογα με τη σημασία και, επομένως, να αποσυμπιέσει τις δοκιμές χαμηλής αξίας σε συμφωνία με τα ενδιαφερόμενα μέρη.
• Συνολικά, βοηθά στη μείωση κόστους μέσω βελτιστοποιημένων και μειωμένων δραστηριοτήτων δοκιμών.
• Η προσέγγιση RBT επιτρέπει στην ομάδα QA να δοκιμάσει πρώτα τις περιοχές υψηλού κινδύνου και επιτρέπει στο προϊόν να 'Αποτυγχάνει γρήγορα' και να διορθώνει γρήγορα.
• Η προσέγγιση RBT βοηθά στην επίτευξη σαφήνειας στο « Κάλυψη δοκιμής » και το «πεδίο εφαρμογής δοκιμής» σε ολόκληρη την ομάδα ενδιαφερομένων.
• Η ομάδα μπορεί να αυξήσει την εστίασή της σε περιοχές υψηλού κινδύνου και να διατηρήσει λιγότερη εστίαση στην περιοχή χαμηλού κινδύνου.
• Το RBT επιτρέπει στην Ομάδα να αποφασίσει εκ των προτέρων σχετικά με την εφαρμογή του πιο αποτελεσματικού τρόπου μετριασμού των κινδύνων του προϊόντος.
• Το RBT συμβάλλει στην αποφυγή του αποτελέσματος της ακατάλληλης εφαρμογής των μετριασμών.
• Ο έλεγχος βάσει κινδύνων επιτρέπει στην ομάδα να προβεί στις κατάλληλες ενέργειες είτε για να μετριάσει είτε για να προγραμματίσει ενδεχόμενες ενέργειες ή να τοποθετήσει οποιαδήποτε λύση για να ξεπεράσει την αποτυχία ή να μειώσει τον αντίκτυπό της, εάν ο κίνδυνος εμφανίζεται στο Live
• Το RBT βοηθά στην ελαχιστοποίηση του υπολειπόμενου κινδύνου στην κυκλοφορία.
• Βοηθά στην επίτευξη της «Βελτιωμένης Ποιότητας» μέσω λιγότερο δαπανηρών ελαττωμάτων στην παραγωγή.
• Τελικά βοηθά στην «Βελτιωμένη εμπειρία πελατών» και στον «Ικανοποιημένο πελάτη».

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

Διαχείριση κινδύνων κατά τον προγραμματισμό δοκιμών

Πώς να διαχειριστείτε τους κινδύνους κατά τη φάση προγραμματισμού δοκιμών:

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

Ένας κίνδυνος είναι απλώς ένα πρόβλημα που είναι πιθανό να συμβεί και όταν συμβαίνει, θα προκαλέσει απώλεια.

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

Δοκιμή βάσει κινδύνου : Επειδή είμαστε μια κοινότητα QA, ας παραμείνουμε συγκεκριμένοι στους κινδύνους και τη διαδικασία που σχετίζεται με αυτήν στον κόσμο QA αποκλειστικά. Οι κίνδυνοι αξιολογούνται και διαχειρίζονται περίπου σε 2 φάσεις της δικής μας Κύκλος ζωής δοκιμής λογισμικού . Το STLC μπορεί να κατηγοριοποιηθεί σε 3 φάσεις - Σχεδιασμός δοκιμών, σχεδιασμός δοκιμών και εκτέλεση δοκιμών.

Η διαδικασία διαχείρισης κινδύνων πραγματοποιείται δύο φορές, κατά τη διάρκεια:

1. Σχεδιασμός δοκιμών
2. Σχεδίαση υπόθεσης δοκιμής (τέλος) ή μερικές φορές στη φάση εκτέλεσης δοκιμής

Είναι υποχρεωτικό στην περίπτωση 1, αλλά στην περίπτωση 2 είναι κάτι περισσότερο «ανάγκη».

Σειρά άρθρων δύο μερών:

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

Αυτή η ενότητα θα αφορά «Διαχείριση κινδύνων κατά τον προγραμματισμό δοκιμών'.

Διαδικασία Διαχείρισης Κινδύνων

Η γενική διαδικασία για τη διαχείριση κινδύνων περιλαμβάνει 3 σημαντικά στάδια:

1. Αναγνώριση κινδύνου
2. Ανάλυση επιπτώσεων κινδύνου
3. Μείωση κινδύνου

Παραδείγματα κινδύνων και μετριασμού:

# 1) Αναγνώριση κινδύνου

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

Το κύριο αποτέλεσμα αυτού του βήματος είναι μια λίστα κινδύνων.

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

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

Κίνδυνοι κατά τον προγραμματισμό δοκιμών: Παραδείγματα δοκιμών βάσει κινδύνου

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

1. Το πρόγραμμα δοκιμών είναι αυστηρό. Εάν η έναρξη της δοκιμής καθυστερήσει λόγω σχεδιαστικών εργασιών, η δοκιμή δεν μπορεί να παραταθεί πέρα ​​από την προγραμματισμένη ημερομηνία έναρξης της UAT.
2. Δεν υπάρχουν αρκετοί πόροι, οι πόροι επιβίβασης είναι πολύ αργά (η διαδικασία διαρκεί περίπου 15 ημέρες.)
3. Τα ελαττώματα εντοπίζονται σε ένα τέλος του κύκλου ή σε ένα τέλος του κύκλου. Τα ελαττώματα που ανακαλύφθηκαν αργά πιθανότατα οφείλονται σε ασαφείς προδιαγραφές και είναι χρονοβόρα για την επίλυση.
4. Το πεδίο εφαρμογής δεν έχει οριστεί πλήρως
5. Φυσικές καταστροφές
6. Μη διαθεσιμότητα του Independent Περιβάλλον δοκιμής και προσβασιμότητα
7. Καθυστέρηση δοκιμών λόγω νέων ζητημάτων

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

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

# 2) Εκτίμηση Κινδύνου / Ανάλυση Επιπτώσεων Κινδύνου

Είναι η ανάλυση κινδύνου σας κάτι τέτοιο; :)

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

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

Πίνακας ανάλυσης επιπτώσεων κινδύνου:

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

# 3) Μείωση των κινδύνων

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

Τεχνικές μετριασμού κινδύνου:

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

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

1. Όσο πιο γρήγορα ξεκινά η διαχείριση κινδύνου σε μια φάση προγραμματισμού έργου QA, τόσο το καλύτερο.
2. Και από τα 3 βήματα, Η αναγνώριση κινδύνου είναι η πιο σημαντική . Εάν κάτι δεν αναφέρεται και ληφθεί υπόψη για περαιτέρω βήματα, ο κίνδυνος δεν αντιμετωπίζεται.
3. Προσπαθήστε να βρείτε ένα ιδανικό χρονικό πλαίσιο για αυτήν τη δραστηριότητα. Θυμηθείτε, ο υπερβολικός προγραμματισμός αφήνει πολύ λίγο χρόνο για να το κάνετε.
4. Επίσης, μετά τη διαδικασία διαχείρισης κινδύνων, εάν προκύψει μια νέα κατάσταση, το σχέδιο διαχείρισης κινδύνου μπορεί να τροποποιηθεί ή να ενημερωθεί ώστε να αντικατοπτρίζει την πιο πρόσφατη κατάσταση.
5. Ιστορικά δεδομένα μπορεί να είναι πολύ χρήσιμο για την επιτυχία αυτής της διαδικασίας.

συμπέρασμα

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

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

Διαχείριση κινδύνων στη φάση εκτέλεσης δοκιμής (με παράδειγμα)

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

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

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

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

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

Διαχείριση κινδύνων - με έμφαση στο AUT

Ας το κατανοήσουμε καλύτερα με ένα παράδειγμα:

Εάν η δοκιμή ξεκινούσε την εν λόγω ημερομηνία, 1 Ιανουαρίου^αγκαι έπρεπε να συνεχίσει μέχρι τις 14 Ιανουαρίου^ου- όταν ολοκληρωθεί ο έλεγχος, η ημερομηνία Go-live του προϊόντος συνήθως καθορίζεται αμέσως. Ας πούμε - 15 Ιανουαρίου^ουγια λόγους απλότητας. Τώρα, στον τέλειο κόσμο τα πράγματα θα πάνε ακριβώς όπως είχε προγραμματιστεί. Αλλά όλοι γνωρίζουμε την πραγματικότητα.

Σε αυτήν την περίπτωση, ας υποθέσουμε ότι για κάποιο λόγο, οι δοκιμές δεν ξεκίνησαν μέχρι τις 7 Ιανουαρίου^ου, που σημαίνει ότι χάσαμε τον μισό χρόνο δοκιμής. Αλλά χρειαζόμαστε 14 ημέρες για να δοκιμάσουμε το προϊόν διεξοδικά. Θα μπορούσαμε να μετακινήσουμε την ημερομηνία μετάδοσης 7 ημέρες ακόμη - ωστόσο. Αυτό συνήθως δεν είναι επιλογή. Επειδή το προϊόν υπόσχεται να βγει στην αγορά σε μια συγκεκριμένη ημερομηνία και τυχόν καθυστερήσεις δεν είναι καλές για την επιχείρηση.

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

Εδώ χρησιμοποιείται και πάλι η διαδικασία διαχείρισης κινδύνων.

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

Ποια είναι η διαδικασία;

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

Διαβάστε επίσης=> Λειτουργία αποτυχίας και ανάλυση εφέ (FMEA) είναι μια τεχνική διαχείρισης κινδύνου

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

Δεδομένου ότι αφορά το AUT, η γνώση γι 'αυτό δεν είναι μόνο με το QA αλλά και με όλες τις άλλες ομάδες - Dev, BA, Client, ομάδες διαχείρισης έργου κ.λπ. Επομένως, είναι μια συλλογική προσπάθεια, καθοδηγούμενη από την ομάδα δοκιμών.

Πώς πραγματοποιείται ο έλεγχος βάσεων κινδύνου;

Βήμα 1) Αναγνώριση κινδύνου

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

Βήμα 2) Εκτίμηση κινδύνου

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

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

Η τυπική μέθοδος είναι να εκχωρήσετε τις βαθμολογίες. Για παράδειγμα, Η πιθανότητα μπορεί να πάρει τιμές 1 έως 5. 1 είναι η πιθανότητα εμφάνισης να είναι χαμηλή (δεν είναι πιθανό να συμβεί καθόλου) και 5 να είναι υψηλή (σίγουρα θα συμβεί).

Ομοίως, στο Impact μπορεί επίσης να αποδοθεί βαθμολογία 1-5. 1 είναι χαμηλού αντίκτυπου (ακόμα και αν αυτός ο κίνδυνος υλοποιηθεί, η απώλεια είναι ελάχιστη) και 5 είναι υψηλός αντίκτυπος (τεράστιες απώλειες όταν συμβαίνει).

Βήμα # 3)

Δημιουργήστε μια μορφή πίνακα και κυκλοφορήστε σε όλους τους εκπροσώπους της ομάδας- Dev, BA, Client, PM, QA και σε οποιονδήποτε άλλο σχετικό.

Βήμα # 4)

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

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

Συντελεστής κινδύνου = Πιθανότητα X Επιπτώσεις. Όσο υψηλότερος είναι ο παράγοντας κινδύνου, τόσο σοβαρό είναι το πρόβλημα.

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

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

Βήμα # 5)

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

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

Έτσι, οι Ενότητες 5 και 2 είναι πιο σημαντικές για την επιτυχία της επιχείρησης. Μοιραστείτε τα αποτελέσματα με όλες τις ομάδες.

Βήμα # 6)

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

Παραδείγματατου σχεδίου θα μπορούσε να είναι:

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

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

Αυτό είναι!

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

• Δεδομένου ότι αυτή είναι μια συλλογική δραστηριότητα που χρειάζεται τη γνώμη όλων μας ; οι πιθανότητες να είναι ακριβείς και αποτελεσματικές είναι υψηλότερες.
• Αυτό είναι όχι μια τυπική μέθοδος και δεν πρέπει να είναι μέρος κάθε έργου QA.
• Μερικές φορές, ακόμη και αν η ομάδα επιλέξει να μην τραβήξει τραπέζια και να εκχωρήσει τιμές- α απλή συνεδρία καταιγισμού ιδεών με όλους τους παρόντες μπορούν να δώσουν στην ομάδα QA καλή κατεύθυνση για το πώς να προχωρήσει.
• ο η συμβολή της ομάδας ανάπτυξης είναι πολύ σημαντικό επειδή είναι αυτοί που δημιουργούν το προϊόν, οπότε θα ξέρουν τι θα μπορούσε να λειτουργήσει και τι μπορεί να χρειαστεί πρόσθετος έλεγχος. Φροντίστε να είστε επιφυλακτικοί για αυτό.
• Παρόλο που υπάρχουν πολλά βήματα στη διαδικασία, Δεν χρειάζεται πολύς χρόνος για την εκτέλεση τους . Ειδικά, αν όλες οι ομάδες μπορούν να καθίσουν μαζί και να εργαστούν ταυτόχρονα.
• Θυμηθείτε αυτήν τη διαδικασία και το αποτέλεσμα είναι μόνο η εναλλακτική . Να πάρει όσο χρόνο προγραμματίζεται για τη δοκιμή είναι ο καλύτερος τρόπος για να εκτελέσετε τη δραστηριότητα QA.

συμπέρασμα

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

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

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

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

ΥΣΤΕΡΟΓΡΑΦΟ. Οι λέξεις QA και Testing χρησιμοποιήθηκαν εναλλακτικά σε όλο το έγγραφο.

Σχετικά με τον Συγγραφέα: Αυτό το άρθρο γράφτηκε από πολλά μέλη της ομάδας STH - Gayathri Subrahmanyam και Swati S.

Η Gayathri είναι μια ΜΜΕ Τεστ Λογισμικού με 2+ δεκαετίες εμπειρίας στον Έλεγχο Λογισμικού και έχει υιοθετήσει εκτενώς την προσέγγιση «Δοκιμές βάσει Κινδύνου» ως μέρος της Βιομηχανικής δοκιμής σε αρκετές δεσμεύσεις και έχει συνειδητοποιήσει το πλεονέκτημα της βελτιστοποίησης πόρων δοκιμής και της ποιότητας.

Η δοκιμή βάσει κινδύνου ήταν μια πρόκληση για εσάς; Έχετε ενδιαφέροντα γεγονότα για να προσθέσετε στο σεμινάριό μας; Μη διστάσετε να εκφράσετε τις σκέψεις σας στην παρακάτω ενότητα σχολίων !!

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

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

• Διαδικασία συνεχούς ενοποίησης: Πώς να βελτιώσετε την ποιότητα του λογισμικού και να μειώσετε τον κίνδυνο
• Λειτουργία αποτυχίας και ανάλυση εφέ (FMEA) - Πώς να αναλύσετε τους κινδύνους για καλύτερη ποιότητα λογισμικού και ικανοποιημένους πελάτες!
• Ο απόλυτος οδηγός για τη δοκιμή βάσει κινδύνου: Διαχείριση κινδύνων στη δοκιμή λογισμικού
• Κορυφαία 10 εργαλεία και τεχνικές εκτίμησης και διαχείρισης κινδύνου
• Τύποι κινδύνων σε έργα λογισμικού
• Μερικές ενδιαφέρουσες ερωτήσεις συνέντευξης δοκιμών λογισμικού
• Επιλέγοντας Δοκιμή λογισμικού ως καριέρα σας
• Σχόλια και σχόλια μαθήματος δοκιμών λογισμικού