Δουλεύοντας στο QA, ακούω συχνά μια φωνή στο κεφάλι μου, "Είσαι σίγουρος ότι τα έχεις ελέγξει όλα;" Μερικές φορές είναι μια χρήσιμη ώθηση, αλλά αν αφεθεί χωρίς έλεγχο, αρχίζει να γίνεται πρόβλημα. Παρακάτω, θα μιλήσω για αυτό το ενοχλητικό Inner Bug και πώς εκδηλώνεται.
Σε αυτό το άρθρο, θέλω να μοιραστώ τις σκέψεις και τις γνώσεις μου που αποκόμισα από τη μελέτη αυτού του φαινομένου. Ελπίζω να σας φανούν χρήσιμα και θα ήθελα πολύ να ακούσω την άποψή σας σχετικά με αυτό στα σχόλια. Εξάλλου, η ανατροφοδότηση είναι ένας από τους καλύτερους τρόπους για να δω τον εαυτό μου από έξω και να βελτιωθώ.
Μια φορά, μετά από εναλλαγή μεταξύ εργασιών και ήδη ολοκλήρωση δοκιμών, αποφάσισα να ελέγξω τα πάντα, για κάθε ενδεχόμενο. Τότε παρατήρησα μια μικρή αλλά καθοριστική λεπτομέρεια. Η εργασία δεν περιελάμβανε τον τύπο για τον υπολογισμό που έπρεπε να εκτελέσει η νέα συνάρτηση. Περίεργος, ξαναδιάβασα τόσο την περιγραφή της εργασίας όσο και το έπος και, προς έκπληξή μου, ο τύπος υπολογισμού δεν προσδιορίστηκε πουθενά. Λοιπόν, πώς το είχα υπολογίσει;
Είναι ντροπιαστικό να το παραδεχτώ, αλλά χρησιμοποιούσα και επαλήθευα τους υπολογισμούς με έναν τύπο από διαφορετική εργασία. Ενώ οι δύο εργασίες σχετίζονταν, οι τύποι υποτίθεται ότι λειτουργούσαν ανεξάρτητα. Συνειδητοποιώντας αυτήν την παράβλεψη, ζήτησα γρήγορα τους σωστούς κανόνες υπολογισμού, δοκίμασα ξανά την εργασία και ανακάλυψα ότι ο προγραμματιστής είχε κάνει το ίδιο λάθος. Επίσης, είχαν χρησιμοποιήσει τον τύπο από την άλλη εργασία.
Μόλις ολοκληρώσω το σχέδιο δοκιμής, αυτός ο μικρός ταραχοποιός αρχίζει να πετάει ιδέες όπως, "Τι γίνεται αν ο πελάτης χρησιμοποιεί μεγαλύτερο μέγεθος γραμματοσειράς ή ένα απαρχαιωμένο λειτουργικό σύστημα;"
Αυτό είναι απίστευτα χρήσιμο όταν γίνεται η δοκιμή, η δυνατότητα είναι ζωντανή και ξαφνικά εμφανίζεται ένα σφάλμα. Αφού εντοπιστεί και επιδιορθωθεί, ελέγχω τα αρχεία δοκιμών μου για να διαπιστώσω εάν έχασα το πρόβλημα κατά τη διάρκεια της δοκιμής ή αν εισήχθη αργότερα στην παραγωγή. Μερικές φορές, εντοπίζω το σφάλμα που κρύβεται σε κοινή θέα στα στιγμιότυπα οθόνης ή στις εγγραφές μου. Όταν συμβαίνει αυτό, σκάβω γιατί το παρέβλεψα και γιατί δεν υπήρχε μια δοκιμαστική περίπτωση για να το πιάσω.
Αυτό συμβαίνει μερικές φορές μετά από ένα τσάκισμα, αλλά υπάρχουν και στιγμές που η φωνή του Μικρού ζωύφιου ακούγεται απρόκλητα. Σε μερικές περιπτώσεις, δεν με άφηνε ήσυχο ακόμα και αφού πήγαινα για ύπνο, και κατέληγα να κρατάω σημειώσεις στον εαυτό μου για το τι άλλο πρέπει να ελέγξω.
Αυτό είναι μια άμεση συνέπεια του πρώτου σημείου: το άγχος γεννά τα πιο παράξενα και πιο εφιαλτικά σενάρια στο κεφάλι μου. Προς το παρόν, φαίνονται επικριτικοί, αλλά κοιτάζοντας πίσω, συχνά αποδεικνύεται ότι είναι κάτι σαν "Κι αν μια τσίχλα σφυρίζει σε ένα πεύκο κάτω από το φεγγάρι;"
Μερικές φορές, ακόμη και αφού μεταφέρω μια εργασία στην επόμενη κατάσταση και ξεκινήσω κάτι νέο, οι σκέψεις για αυτές τις δοκιμαστικές περιπτώσεις με στοιχειώνουν και με εμποδίζουν να συγκεντρωθώ στη νέα εργασία. Σε τέτοιες περιπτώσεις, μπορεί να είναι δύσκολο να απενεργοποιήσετε το ανήσυχο Checker-Bug.
που μου έπεσε στο μυαλό όταν έγραφα για τα μειονεκτήματα –και κάτι που επαναλαμβάνω σαν μάντρα– είναι το εξής: Οι εξαντλητικές δοκιμές είναι μύθος. Πάντα θα υπάρχουν σφάλματα.
Ανεξάρτητα από το πόσο προσεκτικοί είστε, είναι αδύνατο να προβλέψετε κάθε συνδυασμό ενεργειών και σεναρίων, πράγμα που σημαίνει ότι δεν μπορείτε να εντοπίσετε κάθε σφάλμα πριν το κάνουν οι χρήστες σας.
Ειδικά σε έναν κόσμο που αλλάζει συνεχώς.
Αυτό είναι κάτι που απλά πρέπει να αποδεχτείς και να προχωρήσεις.
Αυτό που με βοήθησε να συμφιλιωθώ με αυτό ήταν η ανάλυση των βασικών αιτιών των σφαλμάτων παραγωγής – αυτό που ορισμένοι άνθρωποι αποκαλούν μεταθανάτια . Είναι όταν μιλάτε με όλους τους εμπλεκόμενους για να καταλάβετε πώς συνέβη το σφάλμα και τι θα μπορούσαμε να κάνουμε για να το αποτρέψουμε να συμβεί ξανά.
Και έμαθα ότι τις περισσότερες φορές, σοβαρά ελαττώματα προκλήθηκαν από απλές παραλείψεις: μερικές φορές οι δοκιμαστικές περιπτώσεις με κενές τιμές δεν ελέγχονταν, με αποτέλεσμα ορισμένα προϊόντα να μην εμφανίζονται στο κατάστημα. Άλλες φορές, η τοπική προσαρμογή ήταν χαμένη, με αποτέλεσμα έναν τίτλο κενή οθόνης.
Κι όμως ο ουρανός δεν έπεσε. Η δουλειά συνεχίστηκε και όλοι δώσαμε μεγαλύτερη προσοχή στις περιοχές όπου είχαμε γλιστρήσει πριν.
Συνήθιζα να ησυχάσω τον ενοχλητικό Checker-Bug που εφάρμοζε τεχνικές σχεδιασμού δοκιμής: πίνακες αποφάσεων και διαγράμματα μετάβασης καταστάσεων.
Αυτά σας βοηθούν να οπτικοποιήσετε τη λογική της εφαρμογής και να αποκτήσετε μια σαφέστερη εικόνα των πιθανών περιπτώσεων δοκιμής, πράγμα που σημαίνει ότι μπορείτε να είστε πιο σίγουροι ότι δεν θα τις παραβλέψετε.
Εάν χρειάζεστε μια ανανέωση, ένας πίνακας αποφάσεων είναι ένας πίνακας όπου εισάγουμε συνθήκες και κανόνες σε στήλες και σειρές. Αφού καθορίσουμε τις επιλογές για όλες τις συνθήκες και τους κανόνες, συμπληρώνουμε το αναμενόμενο αποτέλεσμα.
Ένα διάγραμμα μετάβασης κατάστασης χρησιμοποιείται όταν έχουμε ένα αντικείμενο με διαφορετικές καταστάσεις και το αντικείμενο αλλάζει την κατάστασή του με βάση ορισμένες συνθήκες. Δεν είναι πάντα η σωστή εφαρμογή, αλλά ήταν εξαιρετικά χρήσιμο όταν εργάστηκα για την ανάπτυξη μιας λογιστικής υπηρεσίας. τα αντικείμενα σε αυτά τα διαγράμματα ήταν πράγματα όπως αναφορές, εφαρμογές ή ψηφιακές υπογραφές.
η θεραπεία για αυτό το ενοχλητικό Inner Bug με βρήκε πραγματικά μόνο του. Αποδείχθηκε ότι επρόκειτο για αξιολόγηση από ομοτίμους των δοκιμαστικών περιπτώσεων και επικοινωνία μετά από βλάβες.
Απλό, ίσως και προφανές, αλλά λειτουργεί σαν γούρι.
Ο τρόπος να ηρεμήσω τον εγκέφαλό μου ήταν να αξιολογήσω την αποτελεσματικότητα και τους κινδύνους. Όταν το Inner Bug άρχισε να μου ψιθυρίζει στο αυτί, «Ελέγξτε μερικές ακόμη περιπτώσεις δοκιμής», θυμόμουν τον επικεφαλής της ομάδας μου και έκανα τρεις ερωτήσεις:
Ναι, μερικές φορές είναι λογικό να κάνετε δοκιμή σε πολλές εκδόσεις λειτουργικού συστήματος, με διαφορετικές ρυθμίσεις γλώσσας, σκοτεινά και ανοιχτόχρωμα θέματα, αυξημένο μέγεθος γραμματοσειράς και ούτω καθεξής, αλλά τις περισσότερες φορές αυτοί οι έλεγχοι δεν είναι απαραίτητοι.
Φανταστείτε ότι βρίσκετε ένα σφάλμα κατά την εκτέλεση τέτοιων δοκιμών: Τι προτεραιότητα θα είχε; Λόγω των συγκεκριμένων βημάτων για την αναπαραγωγή, ακόμη και σε μια συντριβή θα μπορούσε να δοθεί δευτερεύουσα προτεραιότητα.
Πόσο καιρό θα διαρκέσουν αυτοί οι έλεγχοι; Πέντε έως δέκα λεπτά – δεν είναι κάτι σπουδαίο, αλλά ακόμη και αυτός ο χρόνος δεν είναι πάντα διαθέσιμος. Σε αυτό το διάστημα, θα μπορούσατε να διαβάσετε την περιγραφή μιας εργασίας μέσου μεγέθους.
Όπως κάθε εργαλείο, αυτό το ενοχλητικό Inner Bug σας μπορεί να είναι μια ευλογία ή μια κατάρα. Συχνά χρειάζεται εμπειρία και χρόνος για να μάθετε πώς να χρησιμοποιείτε κάτι αποτελεσματικά. Και ελπίζω αυτό το άρθρο να σας βοηθήσει να δαμάσετε τον εσωτερικό σας κριτικό πιο γρήγορα, να σώσετε τα νεύρα σας και να ενισχύσετε την αυτοπεποίθησή σας.
Θέλω απλώς να σας δώσω κάποια υποστήριξη και ίσως αντί να το παλεύετε μέχρι να εξαντληθείτε, βρείτε έναν τρόπο να δουλέψετε με αυτό το μικρό θηρίο και να το κάνετε σύμμαχό σας.