Αυτό το άρθρο θα ενδιαφέρει όσους, όπως εμείς, αντιμετωπίζουν το πρόβλημα της επιλογής ενός κατάλληλου ειδικού στον τομέα των δοκιμών.
Παραδόξως, με την αύξηση του αριθμού των εταιρειών πληροφορικής στη δημοκρατία μας, αυξάνεται μόνο ο αριθμός των άξιων προγραμματιστών, αλλά όχι των δοκιμαστών. Πολλοί άνθρωποι είναι πρόθυμοι να ασχοληθούν με αυτό το επάγγελμα, αλλά πολλοί δεν καταλαβαίνουν το νόημά του.
Δεν μπορώ να μιλήσω για όλες τις εταιρείες πληροφορικής, αλλά έχουμε αναθέσει τον ρόλο του QA/QC στους ειδικούς μας στην ποιότητα. Αποτελούν μέρος της ομάδας ανάπτυξης και συμμετέχουν σε όλα τα στάδια ανάπτυξης, από την έρευνα μέχρι την κυκλοφορία μιας νέας έκδοσης.
Ένας δοκιμαστής σε μια ομάδα, ακόμη και στο στάδιο του σχεδιασμού, πρέπει να σκεφτεί όλες τις λειτουργικές και μη λειτουργικές απαιτήσεις για την αποδοχή μιας ιστορίας χρήστη. Πρέπει να κατανοήσει τα λειτουργικά χαρακτηριστικά του προϊόντος καθώς και τους προγραμματιστές, και ακόμη καλύτερα, και να βοηθήσει την ομάδα να μην πάρει λάθος αποφάσεις ακόμη και στο στάδιο του σχεδιασμού. Ο ελεγκτής πρέπει να έχει ξεκάθαρη κατανόηση του πώς θα λειτουργήσει η εφαρμοσμένη λειτουργικότητα και ποιες παγίδες μπορεί να υπάρχουν. Οι δοκιμαστές μας δημιουργούν οι ίδιοι σχέδια δοκιμών και δοκιμές, καθώς και προετοιμάζουν όλους τους απαραίτητους πάγκους δοκιμών. Η δοκιμή σύμφωνα με μια έτοιμη προδιαγραφή, όπως ένα μαϊμού κλικ δεν είναι η επιλογή μας. Δουλεύοντας μέσα στην ομάδα, πρέπει να βοηθήσει να κυκλοφορήσει ένα αξιόλογο προϊόν και να χτυπήσει έγκαιρα τον συναγερμό αν κάτι πάει στραβά.
Αυτό που συναντήσαμε όταν ψάχναμε για δοκιμαστές
Στο στάδιο της μελέτης πολλών βιογραφικών, φάνηκε ότι υπήρχαν ειδικοί με την κατάλληλη εμπειρία για εμάς και δεν θα υπήρχαν προβλήματα με την επιλογή ενός δοκιμαστή για την ομάδα μας. Όμως, κατά τη διάρκεια προσωπικών συναντήσεων, συναντούσαμε ολοένα και περισσότερο υποψηφίους που ήταν στην πραγματικότητα πολύ μακριά από τον κόσμο της τεχνολογίας πληροφοριών (για παράδειγμα, δεν μπορούσαν να πουν τις αρχές της αλληλεπίδρασης μεταξύ ενός προγράμματος περιήγησης και ενός διακομιστή ιστού, τα βασικά στοιχεία ασφάλειας, σχεσιακά και μη σχεσιακές βάσεις δεδομένων, δεν είχαν ιδέα για το virtualization και το containerization), αλλά ταυτόχρονα αξιολόγησαν τον εαυτό τους σε επίπεδο Senior QA. Μετά από δεκάδες συνεντεύξεις, καταλήξαμε στο συμπέρασμα ότι ο αριθμός των ειδικών που είναι κατάλληλοι για εμάς στην περιοχή είναι αμελητέος.
Στη συνέχεια, θα σας πω τι βήματα κάναμε και ποια λάθη πατήσαμε για να βρούμε αυτούς τους πολυαναμενόμενους μαχητές για ποιότητα.
Πώς προσπαθήσαμε να διορθώσουμε την κατάσταση
Έχοντας εξαντληθεί με την προμήθεια έτοιμων ειδικών, αρχίσαμε να στοχεύουμε σε κοντινές περιοχές:
- Προσπαθήσαμε να εφαρμόσουμε πρακτικές αξιολόγησης για να εντοπίσουμε ανάμεσα στα πολλά άτομα που «αποχωρούν», τα ίδια από τα οποία μπορούμε να αναπτύξουμε ισχυρούς ειδικούς.
Ζητήσαμε από μια ομάδα πιθανών υποψηφίων με περίπου το ίδιο επίπεδο γνώσεων να ολοκληρώσουν εργασίες. Παρατηρώντας τη διαδικασία σκέψης τους, προσπαθήσαμε να εντοπίσουμε τον πιο πολλά υποσχόμενο υποψήφιο.
Συγκεκριμένα, καταλήξαμε σε εργασίες για να δοκιμάσουμε την προσοχή, την κατανόηση των δυνατοτήτων της τεχνολογίας και τα χαρακτηριστικά της πολυπολιτισμικότητας:
- Πραγματοποιήσαμε συναντήσεις για δοκιμαστές για να διευρύνουμε τα όρια κατανόησης του επαγγέλματος μεταξύ του υπάρχοντος σώματος.
Θα σας πω λίγα λόγια για καθένα από αυτά.
Το Ufa Software QA and Testing Meetup #1 είναι η πρώτη μας προσπάθεια να συγκεντρώσουμε όσους ενδιαφέρονται για το επάγγελμα και ταυτόχρονα να κατανοήσουμε αν το κοινό θα ενδιαφέρεται για αυτό που θέλουμε να του μεταφέρουμε. Βασικά, οι αναφορές μας αφορούσαν από πού είναι καλύτερο να ξεκινήσετε εάν έχετε αποφασίσει να γίνετε δοκιμαστής. Βοηθήστε τους αρχάριους να ανοίξουν τα μάτια τους και να δουν τις δοκιμές σαν ενήλικες. Μιλήσαμε για τα βήματα που πρέπει να κάνουν οι αρχάριοι δοκιμαστές για να ενταχθούν στο επάγγελμα. Σχετικά με το τι είναι η ποιότητα και πώς να το επιτύχετε σε πραγματικές συνθήκες. Και επίσης, τι είναι ο αυτόματος έλεγχος και πού είναι πιο κατάλληλο να το χρησιμοποιήσετε.
Έπειτα, με μεσοδιάστημα 1-2 μηνών, κάναμε άλλα δύο meetup. Υπήρχαν ήδη διπλάσιοι συμμετέχοντες. Στο "Ufa Software QA and Testing Meetup #2" βυθίσαμε βαθύτερα στο θέμα. Μίλησαν για συστήματα παρακολούθησης σφαλμάτων, δοκιμές UI/UX, έθιξαν τα Docker, Ansible και επίσης μίλησαν για πιθανές διενέξεις μεταξύ προγραμματιστή και δοκιμαστή και τρόπους επίλυσής τους.Η τρίτη συνάντησή μας, "Ufa Software QA and Testing Meetup #3", σχετιζόταν έμμεσα με το έργο των ελεγκτών, αλλά ήταν χρήσιμη για την έγκαιρη υπενθύμιση των τεχνικών και οργανωτικών τους καθηκόντων στους προγραμματιστές: δοκιμή φόρτωσης, δοκιμή e2e, Selenium στον αυτόματο έλεγχο, ευπάθειες εφαρμογών ιστού .
Όλο αυτό το διάστημα μαθαίνουμε πώς να δημιουργούμε κανονικό φως και ήχο σε εκπομπές από τις εκδηλώσεις μας:
→
→
→ - Και στο τέλος αποφασίσαμε να προσπαθήσουμε να κάνουμε ένα hackathon για δοκιμαστές
Πώς ετοιμάσαμε και πραγματοποιήσαμε ένα hackathon για δοκιμαστές
Αρχικά, προσπαθήσαμε να καταλάβουμε τι είδους "θηρίο" είναι αυτό και πώς εκτελείται συνήθως. Όπως αποδείχθηκε, τέτοιου είδους εκδηλώσεις δεν έχουν πραγματοποιηθεί πολλές φορές στη Ρωσική Ομοσπονδία και δεν υπάρχει πουθενά να δανειστούμε ιδέες. Δεύτερον, δεν ήθελα να επενδύσω αμέσως πολλούς πόρους σε μια εκδήλωση που φαινόταν αμφίβολη με την πρώτη ματιά. Ως εκ τούτου, αποφασίσαμε ότι θα κάνουμε μικρά mini-hackathon, όχι για ολόκληρο τον κύκλο εργασίας QA, αλλά για μεμονωμένα στάδια.
Ο κύριος πονοκέφαλος μας είναι η έλλειψη πρακτικής μεταξύ των τοπικών δοκιμαστών στη δημιουργία σαφών χαρτών δοκιμών. Δεν αφιερώνουν χρόνο στην έρευνα ιστοριών χρηστών πριν από την εφαρμογή και στη δημιουργία κριτηρίων αποδοχής που είναι ξεκάθαρα στους προγραμματιστές για λειτουργικές και μη λειτουργικές απαιτήσεις, UI/UX, ασφάλεια, φόρτους εργασίας και αιχμής. Ως εκ τούτου, αποφασίσαμε, για πρώτη φορά, να περάσουμε από το πιο ενδιαφέρον και δημιουργικό μέρος της δουλειάς τους - ανάλυση και διαμόρφωση απαιτήσεων κατά την έρευνα πριν από το έργο.
Υπολογίσαμε τον πιθανό αριθμό συμμετεχόντων και αποφασίσαμε ότι χρειαζόμασταν τουλάχιστον 5 εκκρεμότητες για εκδόσεις MVP, 5 προϊόντα και 5 άτομα που θα ενεργούσαν ως ιδιοκτήτες προϊόντων, θα αποκρυπτογραφούσαν τις επιχειρηματικές ανάγκες και θα λάμβαναν αποφάσεις για περιορισμούς.
Δείτε τι έχουμε: .
Η κύρια ιδέα ήταν να καταλήξουμε σε θέματα που ήταν όσο το δυνατόν πιο μακριά από την καθημερινή δουλειά όλων των συμμετεχόντων και να τους δώσουμε περιθώρια για μια δημιουργική πτήση φαντασίας.
Τι λάθη κάναμε και τι θα μπορούσαμε να κάνουμε καλύτερα;
Η χρήση πρακτικών αξιολόγησης, τόσο δημοφιλείς στον τομέα της πρόσληψης πωλητών και διευθυντών χαμηλότερου επιπέδου, χρειάστηκε τεράστια προσπάθεια, αλλά δεν μας επέτρεψε να δώσουμε επαρκή προσοχή σε κάθε συμμετέχοντα και να αξιολογήσουμε τις ικανότητές του. Γενικά, αυτή η επιλογή επιλογής δημιουργεί μια αρνητική εικόνα της εταιρείας, καθώς πολλοί άνθρωποι λαμβάνουν ανεπαρκή ανατροφοδότηση και στη συνέχεια δημιουργούν στον εαυτό τους και στους άλλους την επίδραση της τυραννίας του εργοδότη (οι επικοινωνίες στις κοινότητες πληροφορικής είναι πολύ ανεπτυγμένες). Ως αποτέλεσμα, μας μένουν κυριολεκτικά δύο πιθανοί υποψήφιοι με πολύ μακρινό μέλλον.
Οι συναντήσεις είναι καλό πράγμα. Δημιουργείται μια εκτεταμένη βάση για επεξεργασία και το γενικό επίπεδο των συμμετεχόντων αυξάνεται. Η εταιρεία γίνεται ολοένα και πιο αναγνωρίσιμη στην αγορά. Αλλά η ένταση εργασίας τέτοιων επιχειρήσεων δεν είναι μικρή. Πρέπει να κατανοήσετε ξεκάθαρα ότι η διεξαγωγή συναντήσεων θα διαρκέσει περίπου 700-800 ανθρωποώρες ετησίως.
Όσο για το δοκιμαστικό hackathon. Αυτού του είδους οι εκδηλώσεις δεν έχουν γίνει ακόμη βαρετές, καθώς, σε αντίθεση με τα hackathons για προγραμματιστές, διεξάγονται πολύ λιγότερο συχνά. Το πλεονέκτημα αυτής της ιδέας είναι ότι με χαλαρό τρόπο μπορείτε να ανταλλάξετε μεγάλο όγκο πρακτικών γνώσεων και να προσδιορίσετε με ακρίβεια το επίπεδο κάθε συμμετέχοντα.
Αφού αναλύσαμε τα αποτελέσματα της εκδήλωσης, καταλάβαμε ότι κάναμε πολλά λάθη:
- Το πιο ασυγχώρητο λάθος ήταν να πιστέψουμε ότι θα μας έφταναν 4-5 ώρες. Ως αποτέλεσμα, μόνο η εισαγωγή και η γνωριμία με τις εκκρεμότητες χρειάστηκαν σχεδόν 2 ώρες.
Η συνεργασία με τους κατόχους προϊόντων στο αρχικό στάδιο και ο χρόνος για να βουτήξετε στην θεματική περιοχή χρειάστηκε τον ίδιο χρόνο. Οπότε ο χρόνος που απομένει δεν ήταν σαφώς αρκετός για μια ολοκληρωμένη ανάπτυξη των δοκιμαστικών χαρτών. - Δεν υπήρχε αρκετός χρόνος και ενέργεια για λεπτομερή ανατροφοδότηση σε κάθε χάρτη, αφού είχε ήδη νυχτώσει. Επομένως, ξεκάθαρα αποτύχαμε αυτό το κομμάτι, αλλά αρχικά προοριζόταν να είναι το πιο πολύτιμο στο hackathon.
- Αποφασίσαμε να αξιολογήσουμε την ποιότητα της ανάπτυξης με μια απλή ψηφοφορία όλων των συμμετεχόντων, διαθέτοντας 3 ψήφους για κάθε ομάδα, τις οποίες θα μπορούσαν να δώσουν για την υψηλότερη ποιότητα εργασίας. Ίσως θα ήταν καλύτερο να οργανωθεί μια κριτική επιτροπή.
Τι έχετε πετύχει;
Έχουμε λύσει εν μέρει το πρόβλημά μας και τώρα έχουμε 4 γενναίους, όμορφους άνδρες που εργάζονται για εμάς, καλύπτοντας το πίσω μέρος 4 ομάδων ανάπτυξης. Μια σημαντική δεξαμενή πιθανών ισχυρών υποψηφίων και απτές αλλαγές στο επίπεδο της κοινότητας QA της πόλης δεν έχουν ακόμη παρατηρηθεί. Αλλά υπάρχει κάποια πρόοδος και αυτό δεν μπορεί παρά να χαρεί.
Πηγή: www.habr.com