Η δοκιμή εφαρμογών ήταν μια τεχνικά απαιτητική, χρονικά διαλειμματική δραστηριότητα προγραμματισμένες ημέρες ή εβδομάδες πριν από την κυκλοφορία μιας εφαρμογής. Οι ομάδες ανάπτυξης είχαν το περιθώριο να κωδικοποιήσουν μέχρι την ενδέκατη ώρα και οι δοκιμαστές, οι οποίοι έκαναν το μεγαλύτερο μέρος της δουλειάς τους με το χέρι, δεν είχαν άλλη επιλογή από το να κάνουν με το λίγο χρόνο που τους δόθηκε. Το αποτέλεσμα ήταν ότι πολλές εφαρμογές υποβλήθηκαν σε κακή δοκιμή και οι τεχνολογικές ομάδες αναγκάστηκαν να ανταποκριθούν στα ζητήματα παραγωγής και τα ελαττώματα κλιμακώθηκαν από τους τελικούς χρήστες και τα συστήματα παρακολούθησης εφαρμογών.
Διαθέτει συνεχείς πρακτικές ενοποίησης, πλαίσια δοκιμών μονάδων και πρακτικές αυτοματισμού δοκιμών που ανέβασε αυτό το παράδειγμα. Αντί να διασφαλίζεται η ποιότητα στο τέλος της διαδικασίας ανάπτυξης, πολλές πρακτικές δοκιμών ξεκινούν και εκτελούνται πλήρως κατά τη διάρκεια της κωδικοποίησης, της ενσωμάτωσης και της ανάπτυξης. Οι Devops και οι ευέλικτες ομάδες αυτοματοποιούν τα σενάρια δοκιμών και οι αγωγοί CI / CD καλούν να εκτελέσουν τις δοκιμές κατά την ολοκλήρωση του κώδικα ή τις φάσεις παράδοσης. Το καθαρό αποτέλεσμα είναι ότι οι προγραμματιστές ειδοποιούνται όταν οι αλλαγές στον κώδικά τους σπάσουν τη δόμηση και μπορούν να λάβουν άμεσα μέτρα για την αντιμετώπιση του αναφερόμενου ζητήματος.
Η αυτοματοποίηση δοκιμών και η ενσωμάτωση δοκιμαστικών σεναρίων στους αγωγούς CI / CD είναι γνωστή ως δοκιμή στροφής αριστερά. Αυτό συνεπάγεται ότι μπορούν να γίνουν περισσότερες πρακτικές διασφάλισης ποιότητας στη φάση ανάπτυξης για να αντιμετωπιστούν ζητήματα νωρίτερα στο χρονοδιάγραμμα κυκλοφορίας. Η αυτοματοποίηση των δοκιμών είναι μία από τις προτεραιότητες προ-ανάπτυξης για ομάδες ευέλικτων και devops που θέλουν να αυξήσουν τις συχνότητες ανάπτυξης.
Κατά την εισαγωγή της νέας λειτουργικότητας, τα δομημένα σενάρια δοκιμής επικυρώνουν τις νέες δυνατότητες. Αυτές οι δοκιμές μπορούν στη συνέχεια να αυτοματοποιηθούν και να περιληφθούν στα βήματα κατασκευής ή ανάπτυξης. Αντί να ζητήσετε από τους μηχανικούς της QA να εκτελέσουν δοκιμές παλινδρόμησης στο τέλος μιας διαδικασίας κυκλοφορίας, μπορείτε να εκτελέσετε και να επικυρώσετε πολλές από αυτές τις δοκιμές ως μέρος της ανάπτυξης. Αυτές οι δοκιμές μετατοπίζονται αριστερά από το τέλος της διαδικασίας απελευθέρωσης σε προηγούμενες φάσεις ανάπτυξης και κωδικοποίησης.
Η δοκιμή Shift-left επιτρέπει τη δέσμευση των ευέλικτων ομάδων στην ποιότητα
Η δοκιμή Shift-αριστερά όχι μόνο οδηγεί την αποτελεσματικότητα και βελτιώνει την ποιότητα, αλλά δημιουργεί επίσης μια σημαντική αλλαγή στην κουλτούρα στη διαδικασία ευέλικτης ανάπτυξης.
Ορισμένες ομάδες ανάπτυξης θεωρούν τη διασφάλιση ποιότητας και τις δοκιμές ως εμπόδιο για την παράδοση του κώδικα τους στην παραγωγή. Μετά από όλη τη σκληρή δουλειά στην ικανοποίηση ευέλικτων ιδιοκτητών προϊόντων και τη συμπλήρωση του κώδικα, οι συμπαίκτες του QA εντοπίζουν μια λίστα σφαλμάτων που απαιτούν αποκατάσταση. Εάν το QA εντοπίσει πολλά σφάλματα, μπορεί να επηρεάσει το χρονοδιάγραμμα κυκλοφορίας για να τα διορθώσει. Ακόμα χειρότερο είναι όταν σημαντικές ενότητες του κώδικα χρειάζονται εκ νέου μηχανική διότι τα ελαττώματα εκθέτουν θέματα λογικής, ασφάλειας ή απόδοσης. Σε αυτό το σενάριο, οι προγραμματιστές και οι μηχανικοί QA μπορεί να βρίσκονται στην ίδια ευέλικτη ομάδα αλλά δεν ενεργούν ομαδικά.
Η δοκιμή Shift-left επιτρέπει στις ευέλικτες ομάδες να μετατοπίζουν ποιοτικές ευθύνες στην πλήρη ομάδα προγραμματιστών και δοκιμαστών. Όταν η δοκιμή εκτελείται ως μέρος του αγωγού CI / CD, παρέχει μια καλύτερη ευκαιρία στους προγραμματιστές να αντιμετωπίσουν ζητήματα ποιότητας κατά τη στιγμή που εργάζονται στον σχετικό κώδικα. Ο αγωγός CI / CD προειδοποιεί τον προγραμματιστή για την αποτυχημένη έκδοση και οι περισσότερες αυτο-οργανωμένες ομάδες ανάπτυξης απαιτούν την άμεση επίλυση αυτών των ζητημάτων.
Η δοκιμή Shift-left παρέχει επίσης στους προγραμματιστές και στους μηχανικούς QA ευκαιρίες να αυτοματοποιήσουν περισσότερες από τις δοκιμές. Μια βέλτιστη πρακτική είναι οι ομάδες να αποφασίζουν ποιος θα εφαρμόσει τον αυτοματισμό ανάλογα με τους τύπους των δοκιμών που απαιτούνται για τη λειτουργικότητα που αναπτύχθηκε. Για παράδειγμα, οι προγραμματιστές είναι συχνά υπεύθυνοι για την αυτοματοποίηση των δοκιμών μονάδων και API, αλλά οι μηχανικοί αυτοματοποίησης QA αναπτύσσουν συχνά δοκιμές εμπειρίας χρήστη και δοκιμές συναλλαγών που προσομοιώνουν κλήσεις API πολλαπλών σταδίων σε πολλές υπηρεσίες.
Πότε θα εφαρμοστεί η δοκιμή στροφής αριστερά
Η δοκιμή Shift-left λειτουργεί καλύτερα για τις πιο ατομικές δοκιμές σε επίπεδο μονάδας που έχουν μικρούς χρόνους εκτέλεσης. Είναι σημαντικό οι δοκιμές να αυτοματοποιούνται στον αγωγό CI / CD και να εκτελούνται κάθε φορά που οι προγραμματιστές ενεργοποιούν μια έκδοση, να εκτελούν γρήγορα και να μην επιβραδύνουν τις διαδικασίες κατασκευής.
Πιο περίπλοκες και χρονοβόρες δοκιμές, όπως δοκιμές εμπειρίας χρήστη από άκρο σε άκρο, δοκιμές συναλλαγών, ανάλυση στατικού κώδικα και δοκιμές ασφαλείας εκτελούνται συχνά καλύτερα εκτός των αγωγών CI / CD και σε καθημερινά ή πιο συχνά δρομολόγια. Αυτές οι δοκιμές εξακολουθούν να παρέχουν έγκαιρα σχόλια στους προγραμματιστές για ζητήματα ποιότητας, αλλά αυτοματοποιούνται εκτός του CI / CD για να αποφευχθεί η επιβράδυνση ή η δημιουργία συμφόρησης.
Ο Thomas J. Sweet, ένας VP στις υπηρεσίες IT στην GM Financial, μοιράστηκε μαζί μου τις προσωπικές του γνώσεις σχετικά με τα όρια των στρατηγικών δοκιμών στροφής προς τα αριστερά. Προτείνει, «Το Shift αριστερά είναι πάντα μια στρατηγική, εκτός από την εκτέλεση δοκιμών ενοποίησης σε παραδόσεις τρίτων κατασκευαστών, καθώς συχνά δεν έχετε πρόσβαση στον πηγαίο κώδικα τους. Ακόμα και όταν έχετε εσωτερικές εφαρμογές με μονολιθικές αρχιτεκτονικές παλαιού τύπου, μπορείτε να ξεκινήσετε εφαρμόζοντας βασικές πολιτικές check-in που απαιτούν έλεγχο κώδικα και σάρωση ασφαλείας. Το check-in πρέπει να απορριφθεί εάν η σάρωση περιλαμβάνει βασικές προειδοποιήσεις και αστοχίες. "
Μία πιθανή λύση για την κατάντη δοκιμή με συνεργάτες ενσωμάτωσης είναι η εφαρμογή εικονικοποίησης υπηρεσιών. Αυτή η τεχνική επιτρέπει στις ομάδες ανάπτυξης να προσομοιώσουν την απόκριση ενός μεταγενέστερου συστήματος σε διαφορετικές εισόδους. Λειτουργεί καλά όταν τα μεταγενέστερα συστήματα είναι καλά καθορισμένα. Εργαλεία από Micro Focus, Tricentis και άλλα επιτρέπουν αυτήν την ικανότητα.
Ο Rob Pociluk, ένας πολύ έμπειρος διευθυντής διασφάλισης ποιότητας, είναι ισχυρός υποστηρικτής των δοκιμών στροφής προς τα αριστερά στην ευέλικτη ανάπτυξη. «Το να είσαι έτοιμος και ικανός να δοκιμάσεις μικρά τμήματα κώδικα διατηρεί το QA ευέλικτο και βρόχο κατά τη διάρκεια της προόδου ενός σπριντ. Οι ομάδες θα πρέπει να αποφεύγουν τη χρήση της στροφής αριστερά πάρα πολύ, καθώς μπορείτε να χάσετε τον ίδιο τον σκοπό του κώδικα. "
Έτσι, ακόμη και όταν οι ομάδες αγκαλιάζουν πλήρως τις δοκιμές με στροφή προς τα αριστερά, υπάρχουν καλοί λόγοι για να προγραμματίσετε ακόμη ένα παράθυρο δοκιμών σε μια έκδοση κώδικα που στοχεύει για κυκλοφορία. Διασφαλίζει ότι όλες οι αυτοματοποιημένες δοκιμές εκτελούνται στην τελική έκδοση, αλλά επίσης επιτρέπει τον προγραμματισμό πρόσθετων δοκιμών που απαιτεί ένα πλήρως λειτουργικό σύστημα.
Ένα από αυτά τα τεστ είναι το UAT (δοκιμή αποδοχής χρηστών), όπου επιλεγμένοι τελικοί χρήστες και ειδικοί θεμάτων επικυρώνουν και παρέχουν σχόλια. Ορισμένα UAT μπορούν να γίνουν κατά τη διάρκεια της ανάπτυξης, αλλά μπορεί να μην είναι εύκολο να κάνετε τους ανθρώπους να εκτελούν αυτήν τη δοκιμή συχνά ή όταν η λειτουργικότητα δεν είναι πλήρως έτοιμη.
Προαπαιτούμενα στις στρατηγικές δοκιμής με στροφή προς τα αριστερά
Η δοκιμή Shift-left είναι μια αυξανόμενη πρακτική devops, αλλά έχει τις προϋποθέσεις και τις αρχικές επενδύσεις. Απαιτούνται ορισμένες βασικές δυνατότητες και πρακτικές.
- Απαιτείται επαρκής ικανότητα δοκιμής και περιβάλλοντα για την υποστήριξη του αριθμού εκδόσεων και δοκιμών που εκτελούνται ταυτόχρονα.
- Οι ευέλικτες ομάδες απαιτούν μια εργαλειοθήκη δοκιμών προϊόντων που ενσωματώνονται εύκολα σε αγωγούς CI / CD και εργαλεία προγραμματισμού εργασιών και μπορούν να επικυρώσουν τη λειτουργικότητα, την ποιότητα του κώδικα, την ασφάλεια και την απόδοση.
- Οι αρχιτέκτονες, οι ειδικοί της infosec, οι υπεύθυνοι QA και άλλα ανώτερα μέλη του οργανισμού πρέπει να καθορίσουν πρότυπα δοκιμών και στόχους σε επίπεδο υπηρεσίας που αποτελούν τα προεπιλεγμένα κριτήρια αποδοχής.
- Όταν οι εφαρμογές απαιτούν εισαγωγή χρήστη, οι ομάδες δοκιμών χρειάζονται επαρκή δεδομένα δοκιμών και μοτίβα για την επικύρωση αρκετών προσωπικών στοιχείων, περιπτώσεων χρήσης και προτύπων εισαγωγής.
- Στη δέσμευση σπριντ ή νωρίτερα, οι ομάδες scrum, συμπεριλαμβανομένων των μηχανικών αυτοματισμού δοκιμών QA, θα πρέπει να καθορίσουν μια στρατηγική δοκιμών σχετικά με το ποιες δυνατότητες δοκιμάζονται, ποιοι τύποι δοκιμών εφαρμόζονται, ποιες διαδικασίες αυτοματοποίησης ενημερώνονται και ποιος αναπτύσσει τις δοκιμές.
- Οι ομάδες Devops θα πρέπει να μετρούν τη διάρκεια των διαδρομών αγωγού CI / CD και να επισημαίνουν όταν τα αυτοματοποιημένα βήματα δοκιμής επηρεάζουν την παραγωγικότητα. Οι ομάδες Devops συχνά απαιτούν πρόσθετα χρονοδιαγράμματα δοκιμών εκτός των αγωγών CI / CD για την εκτέλεση δοκιμών μεγαλύτερης διάρκειας.
- Οι ομάδες πρέπει να συζητούν τακτικά τα κενά στις αυτοματοποιημένες δοκιμές τους, ειδικά επικυρώσεις που απαιτούν ειδικούς σε θέματα, UAT ή δοκιμές με συνεργάτες. Εάν οι ευέλικτες ομάδες δεν μπορούν να αντιμετωπίσουν αυτά τα κενά με αυτοματισμό, τότε οι κύκλοι απελευθέρωσης θα πρέπει να λαμβάνουν υπόψη τα γενικά έξοδα για τη μείωση των κινδύνων και την ολοκλήρωση αυτών των δοκιμών.
Τέλος, οι ευέλικτες ομάδες και οι devops οργανισμοί πρέπει να μετρούν και να συζητούν τακτικά τη δοκιμαστική τους κάλυψη. Η χρήση στρατηγικής δοκιμών με στροφή προς τα αριστερά δεν λειτουργεί εάν οι ομάδες ανάπτυξης και οι μηχανικοί ποιοτικού αυτοματισμού δεν εφαρμόζουν, αυτοματοποιούν και ενσωματώνουν επαρκείς δοκιμές για την αντιμετώπιση προβλημάτων και την αντιμετώπιση κινδύνων.
Η επιτάχυνση των κύκλων απελευθέρωσης ή η ενεργοποίηση της συνεχούς παράδοσης χωρίς επαρκή αυτοματοποιημένο έλεγχο μπορεί να οδηγήσει σε σημαντικά ζητήματα ποιότητας που υποβαθμίζουν την εμπειρία για τους τελικούς χρήστες. Οι ευέλικτες ομάδες ανάπτυξης πιέζουν τις κυκλοφορίες πολύ συχνά και στη συνέχεια αντιμετωπίζουν προβλήματα παραγωγής και ελαττώματα αντί να επενδύουν σε όλο και καλύτερο αυτοματισμό.
