Estimated reading time: 9 minutes
Accelerating Change and Transformation with Test Automation Services
Πριν ξεκινήσω θέλω να ορίσω πολύ σύντομα το πλαίσιο του software testing όπως θα το συζητήσουμε σήμερα.
- Κατ’αρχάς θα πω ότι η παρουσίαση αφορά συνολικά το software testing, δηλαδή όλες τις -ας πούμε- εκδοχές του functional, του performance και του security testing.
- Επίσης παρότι ο τίτλος παραπέμπει σε αυτοματισμό, ο πραγματικός στόχος είναι το λεγόμενο shift-left testing, και ακόμα περισσότερο το “autonomation” το οποίο μπορεί να περιγραφεί ως «automation with a human touch».
- Ο λόγος που μας ενδιαφέρει το “autonomation” είναι επειδή ο σχεδιασμός, η ανάπτυξη και το testing του λογισμικού μοιάζουν πολύ περισσότερο με την εργασία που γίνεται σε εργαστήριο παρά με αυτή ενός εργοστασίου μαζικής παραγωγής. Σε αυτό το πλαίσιο ο αυτοματισμός και άλλες προσεγγίσεις, όπως η χρήση τεχνητής νοημοσύνης και του service virtualization, έχουν ως κύριο στόχο να υποβοηθήσουν τη δημιουργκότητα και την παραγωγικότητα της ομάδας μας.
Σε ότι αφορά το τι σημαίνει μετασχηματισμός θα πω απλά ότι υπάρχουν αρκετοί αξιόλογοι ορισμοί, και επιπλέον είναι θεμιτό κάθε οργανισμός να έχει τη δική του προσέγγιση στο ζήτημα. Αν όμως η προσέγγιση σας περιλαμβάνει στόχους όπως βελτίωση του λεγόμενου “time-to-market”, υιοθέτηση πιο πελατοκεντρικής παραγωγής προϊόντων και υπηρεσιών, δημιουργία ενός περισσότερο Agile οργανισμού, και άλλα συναφή, σας αφορά σίγουρα -στο υψηλότερο επίπεδο- η shift-left προοπτική.
BARRIERS, CHALLENGES & INDICATIVE SOLUTIONS
Όπως γνωρίζουμε, η ανάπτυξη μίας εφαρμογής ή άλλου λογισμικού δε μοιάζει στην πραγματικότητα με κλασική γραμμή παραγωγής, δηλαδή δεν είναι γραμμική, και δεν οργανώνεται όμορφα και νοικοκυρεμένα σε κουτάκια. Το σχήμα με τις φάσεις που φαίνεται στο slide δεν αποτυπώνει λοιπόν κάποια τυπική ή προτεινόμενη διαδικασία ανάπτυξης λογισμικού, αλλά το χρησιμοποιώ για να έχουμε ένα κοινό πεδίο αναφοράς στη σημερινή παρουσίαση.
Πάνω σε αυτό το σχήμα αναφοράς θα εντοπίσω κάποιες προκλήσεις και σημεία συμφόρησης, και θα προτείνω -σε γενικές γραμμές- προσεγγίσεις αυτοματισμού και γενικά shift-left που έχουμε υλοποιήσει και δουλεύουν σε πελάτες μας.
Ανεπαρκής κάλυψη testing για σύγχρονες συνθήκες
Η πρώτη τροχοπέδη είναι το υψηλό κόστος -σε χρόνο και πόρους- διενέργειας των test που καλούμαστε να εκτελέσουμε ώστε να ικανοποιήσουμε τα κριτήρια καλής λειτουργίας που μας θέτουν οι -εσωτερικοί ή εξωτερικοί- πελάτες μας. Όσο μάλιστα αυξανονται οι απαιτήσεις (νέες λειτουργίες, βελτιώσεις, προσαρμοστικότητα, διεπαφές με τρίτα συστήματα) και αυστηροποιούνται τα αντίστοιχα κριτήρια αποδοχής (ποιότητα, ασφάλεια, κανονιστικές συμμορφώσεις), αντιλαμβάνεται κανείς ότι το πλήθος των σχετικών δοκιμών που πρέπει να εκτελεστούν ώστε να καλύψουν κάθε πιθανό σενάριο χρήσης, σε κάθε άξονα (λειτουργικότητας, απόδοσης και ασφάλειας) αυξάνουν με διαρκώς επιταχυνόμενο ρυθμό.
Η εκθετική πολλές φορές αυτή αύξηση των αναγκών για testing μπορεί να κάνει πρακτικά αδύνατη την ανταπόκριση του οργανισμού μας σε αυτές, στον διατιθέμενο χρόνο μεταξύ των releases.
Αναφορά σε λύσεις γι αυτό το problem area
Σε αυτήν την -ας πούμε- κατηγορία προβλημάτων έχουμε, παραδείγματος χάριν, υλοποιήσει λύσεις testing automation και stress testing που καλύπτουν ασύγκριτα ευρύτερο αριθμό και τύπο ελέγχων, και επιτρέπουν σε μηχανικούς και άλλους ειδικούς να ασχοληθούν με πιο δημιουργικές και παραγωγικές εργασίες.
Mean-time-to-Debug — Συνολικός χρόνος επιδιόρθωσης ενός προβλήματος
Για να αντιληφθούμε στοιχειωδώς το δεύτερο εμπόδιο αξίζει να μπούμε στη θέση των σημερινών μηχανικών και των ομάδων ανάπτυξης software. Έχουν να αντιμετωπίσουν τη συνεχώς αυξανόμενη πολυπλοκότητα εφαρμογών και περιβάλλοντος στο οποίο λειτουργούν, δέχονται ολοένα μεγαλύτερες απαιτήσεις από πελάτες και χρήστες, και φυσικά εργάζονται κάτω από την πίεση να παραδώσουν γρήγορα αυτό που δουλεύουν, χωρίς καμία έκπτωση στην ποιότητα. Για να συμπληρώσουμε την εικόνα, προσθέτω και το γεγονός ότι σε πάρα πολλούς οργανισμούς υπάρχει διαρκής έλλειψη προγραμματιστών και άλλων μηχανικών.
Είναι λογικό να πούμε ότι κάτω από αυτές τις συνθήκες, και χωρίς κατάλληλες λύσεις, οι μηχανικοί θα διαθέτουν ολοένα λιγότερο χρόνο και ―αν είμαστε ειλικρινείς― διάθεση για να ασχοληθούν με το debugging των προβλημάτων που αναδεικνύει το testing.
Ο χρόνος που απαιτείται -στις σύγχρονες, πιο κατανεμημένες εφαρμογες- για να μάθουμε ότι υπάρχει ένα πρόβλημα, να εντοπίσουμε που βρίσκεται, να γράψουμε ένα δυνητικό fix, και να επιβεβαιώσουμε -μέσω testing- ότι λειτουργεί και δεν χαλάει κάτι άλλο δεν είναι αμελητέος. Και φυσικά γίνεται κομβικό εμπόδιο στις συνθήκες που ανέφερα προηγουμένως.
Αναφορά σε λύσεις γι αυτό το problem area
Η εμπειρία μας δείχνει ότι ένας εξαιρετικός τρόπος για να μειώσει μία ομάδα ανάπτυξης το μέσο χρόνο που χρειάζεται για να φτιάξει ένα bug ή άλλη δυσλειτουργία, είναι να χρησιμοποιεί εργαλεία tracing και monitoring νέας γενιάς, όπως το Dynatrace, που υποβοηθούν τους developers να αντιληφθούν και να εντοπίσουν ταχύτατα τα προβλήματα και να κάνουν το σχετικό root cause analysis.
Ελλιπής πρόσβαση σε τρίτα συστήματα ή σε δεδομένα
Μία ακόμα δυσκολία που συναντούν οι ομάδες σχεδιασμού και ανάπτυξης μίας εφαρμογής είναι αυτή της πρόσβασης σε άλλα συστήματα και υπηρεσίες, καθώς και σε κατάλληλα δεδομένα, που δεν υφίστανται ακόμη ή δεν είναι σε τελική μορφή, ή παρέχονται μεν αλλά με σημαντικούς περιορισμούς επειδή είναι στην παραγωγή ή επειδή δεν θέλουμε να δώσουμε πρόσβαση σε ευαίσθητα δεδομένα.
Αυτός ο τύπος προβλήματος επηρεάζει φυσικά ολόκληρο τον κύκλο design, παραγωγής και testing μίας εφαρμογής, και συμβάλλει στην καθυστέρηση ή τον πλημμελή σχεδιασμό της. Τα προβλήματα κυμαίνονται από κάτι απλό, όπως το να θέλουμε να αξιολογήσουμε επιλογές που εξετάζουμε στο στάδιο του prototyping, εώς κάτι θεμελιώδες όπως το να εισάγουμε σύγχρονες πρακτικές και αρχιτεκτονικές τύπου microservice.
Φυσικά η υιοθέτηση κατανεμημένων αρχιτεκτονικών λογισμικού έχει ήδη αρχίσει να διευρύνεται σημαντικά ―είναι μάλιστα θεμελιώδες στοιχείο μίας σύγχρονης Cloud στρατηγικής― και θα αυξάνονται επιπλέον οι ανάγκες προστασίας ευαίσθητων δεδομένων και της ιδιωτικότητας πελατών και εργαζόμενων. Όπως καταλαβαίνετε, αυτή η διπλή δυναμική θα μεγενθύνει ακόμα περισσότερο την πρόκληση ανάπτυξης λογισμικού στο ρυθμό και τα επίπεδα ποιότητας που απαιτούνται σήμερα.
Αναφορά σε λύσεις σε αυτό το problem area
Πάνω σε αυτό το ζήτημα έχουμε βοηθήσει ομάδες ανάπτυξης λογισμικού και υπηρεσιών data science σε τράπεζες, τηλεπικοινωνιακούς παρόχους, και σε άλλες αγορές, να δουλεύουν ανεξάρτητα χρησιμοποιώντας προσομοίωση τρίτων υπηρεσιών που δεν είναι διαθέσιμες και ανωνυμοποιημένα δεδομένα στα οποία δε θα είχαν υπό άλλες συνθήκες πρόσβαση.
End to end συνεργασία (Design to Dev to CAB)
Η τελευταία πρόκληση -για τους σκοπούς της σημερινής μου παρουσίασης- είναι ίσως η πιο κρίσιμη για τους μεγάλους οργανισμούς που θέλουν να γίνουν περισσότερο πελατοκεντρικοί και να αμβλύνουν τα προβλήματα της -αναπόφευκτης- γραφειοκρατίας που, αν δεν τους χαρακτηρίζει, τουλάχιστον τους δυσκολεύει. Μιλάω φυσικά για την οριζόντια συνεργασία μεταξύ των ομάδων και των τμημάτων που εμπλέκονται στην σχεδίαση, την ανάπτυξη και την επιχειρησιακή λειτουργία μίας εφαρμογής ή μιας ψηφιακής υπηρεσίας.
Ενδεικτικά αναφέρω τα γνωστά σε όλους μας προβλήματα επικοινωνίας μεταξύ του business ή του product design και του ποιοτικού ελέγχου, ανάμεσα στον ποιοτικό έλεγχο και το development, και μεταξύ της ομάδας ανάπτυξης του λογισμικού και του εκάστοτε τυπικού, ή άτυπου συμβουλίου (Change Advisory Board) που ελέγχει και εγκρίνει τις αλλαγές και τα releases. Από την σύλληψη μιας ιδέας (ή την αντίληψη μιας ανάγκης) μέχρι την υλοποίησή της στο τελικό προϊόν, μπορεί να χρειαστούν πολλοί κύκλοι διαβουλεύσεων, διευκρινίσεων, ανακατασκευών, ενδεχομένως και υπαναχωρήσεων ή συμβιβασμών που να οδηγήσουν ή σε υποδεέστερο του αρχικού σχεδιασμού προϊόν ή σε μεγάλη καθυστέρηση στην κυκλοφορία του.
Και τι μπορεί να κάνει κανείς για όλα αυτά;
Ακόμα κι αν δεν υπάρχει κάτι που να επιλύει όλα αυτά τα προβλήματα, υπάρχει κάτι που αν εφαρμοστεί σωστά, αμβλύνει σχεδόν αυτόματα όλα τα υπόλοιπα που αναφέραμε: Ο αυτοματισμός του testing.
Θέλω σε αυτό το σημείο να είμαι σαφής. Δε λέω ότι ο αυτοματισμός του testing θα λύσει δια παντός τα προβλήματα συνεργασίας και θα ευθυγραμμίσει με μαγικό τρόπο όλους όσους συμβάλλουν με τις επιθυμίες των πελατών. Μπορώ όμως να πω με βεβαιότητα, και από την εμπειρία μας, ότι συμβάλλει καταλυτικά προς αυτήν την κατεύθυνση.
Γιατί; Διότι, εφόσον σχεδιαστεί έτσι ώστε να διευκολύνει όλη την έκταση της ανάπτυξης του λογισμικού ή της υπηρεσίας (από τον σχεδιασμό μέχρι την διάθεσή τους στους τελικούς πελάτες), εφόσον εφαρμοστεί στα κατάλληλα σημεία (αρχικά εκεί που παρέχει το μέγιστο δυνατό όφελος και σταδιακά σε όλο και μεγαλύτερη έκταση), μπορεί να ελευθερώσει εξαιρετικά πολύτιμο χρόνο από τους μηχανικούς, να αυξήσει δραματικά την ποιότητα του τελικού προϊόντος και παράλληλα να ελαχιστοποιήσει τον χρόνο ανάπτυξης και διάθεσης νέας λειτουργικότητας.
Αναφορά σε λύσεις σε αυτό το problem area
Από την εμπειρία μας στην Ελλάδα μπορώ να πω ότι ένας από τους πιο αποτελεσματικούς τρόπους για να ενισχυθεί η οριζόντια συνεργασία στην ανάπτυξη των εφαρμογών είναι η χρήση μίας κοινής πλατφόρμας για το σχεδιασμός και την εκτέλεση των test. Έχουμε δει στην πράξη το business ή το design να ορίζουν με visual τρόπο τα test που θέλουν να περνάει η εφαρμογή, και να τα παίρνει στη συνέχεια ένας εξοικειωμένος χρήστης για να τα κάνει fine tune και να τα τρέξει.
Στο άλλο άκρο, έχουμε δει ενθαρρυντικά αποτελέσματα σε τράπεζες από την αυτοματοποίηση της σύνδεσης του DevOps και των διαδικασιών διαχείρισης change & release.
ALL THIS, AND LESS EXPENSIVE TOO
Όπως είπαμε, τα οφέλη του testing automation, και μίας προσέγγισης shift-left ευρύτερα, περιλαμβάνουν σημαντικούς στόχους και κομβικά συστατικά του ψηφιακού μετασχηματισμού. Οφέλη όπως μείωση του λεγόμενου time-to-market, βελτίωση της ποιότητας των παρεχόμενων υπηρεσιών, άμβλυνση της έκθεσης σε κυβερνοαπειλές, καθώς και συμβολή στην υιοθέτηση σύγχρονων πρακτικών και αρχιτεκτονικών του software engineering, και δυνατότητα επιτάχυνσης του κύκλου change and release στους οργανισμούς που το έχουν ανάγκη.
Αυτό που ίσως δημιουργεί όμως τη μεγαλύτερη εντύπωση είναι ότι η υιοθέτηση πρακτικών και εργαλείων shift-left οδηγεί και σε μικρότερο συνολικό κόστος στην ανάπτυξη και γενικά τον κύκλο ζωής μιας εφαρμογής ή μιας ψηφιακής υπηρεσίας.
Ο λόγος του κόστους επιδιόρθωσης ενός προβλήματος που ανιχνεύεται (αφότου μπήκε μια εφαρμογή στην παραγωγή) είναι, ανάλογα με την έρευνα, από 7 εώς 16 φορές μεγαλύτερο, από το αν είχε βρεθεί και διορθωθεί στο testing. Οι διαφορές είναι συντριπτικά –100 και πλέον φορές- μεγαλύτερες όταν η σύγκριση γίνεται με τη φάση του σχεδιασμού της εφαρμογής.
Οι αριθμοί αυτοί δεν πρέπει να μας φαίνονται παράξενοι, αφού σε ένα σημαντικό βαθμό οι πρακτικές του shift-left -όπως και άλλων σύγχρονων software engineering πρακτικών- εμπνεύστηκαν και επηρεάστηκαν από αντίστοιχες προσεγγίσεις εύελικτης παραγωγής που ξεκίνησαν -κυρίως- στην Toyota, προς τα τέλη της δεκαετίας του 40, και θεωρούνται ακόμα και σήμερα, κυρίαρχο παράδειγμα στη βιομηχανία.
FOCUS ON VALUE, TEST AS A SERVICE
Δε χρειάζεται να συμφωνήσουμε όλοι απόλυτα με το απόφθεγμα που λέει ότι “software is eating the world” του Andreessen. Αλλά μπορούμε με ασφάλεια να πούμε ότι οι εφαρμογές και άλλες ψηφιακές υπηρεσίες είναι κρίσιμος μοχλός δημιουργίας και παροχής αξίας στους πελάτες της συντριπτικής πλειοψηφίας των οργανισμών σήμερα. Και φυσικά είναι κομβικό πεδίο ανταγωνισμού.
Για να αναπτύξεις όμως ανταγωνιστικό software πρέπει να έχεις το κατάλληλο ανθρώπινο δυναμικό -κυρίως προγραμματιστές, designers, και όλο και συχνότερα data scientists- που θα είναι αφοσιωμένο στο να δημιουργήσει αυτό που θέλουν οι πελάτες της εταιρείας τους.
Σε αυτό το πλαίσιο προτείνουμε -ως Performance Technologies- να αξιολογήσετε την επιλογή υιοθέτησης μίας υποδομής testing automation as a service. Το προτείνουμε κυρίως για να μπορούν οι μηχανικοί και άλλα στελέχη σας να μην ξοδεύουν τον πολύτιμο χρόνο τους στην δημιουργία, συντήρηση και λειτουργία μίας πλατφόρμας shift-left (που μπορεί να γίνει outsourced), αλλά να εστιάζουν περισσότερο στη δημιουργία αξίας για τους πελάτες και τον οργανισμό σας, εκεί δηλαδή που είναι περισσότερο αναγκαίοι και πολύτιμοι.
Κλείνοντας θέλω να τονίσω ότι ο οργανισμός σας έχει τις δικές του ιδιαιτερότητες και προσδοκίες, και φυσικά, το δικό του προϋπολογισμό, οπότε θα θέλετε να σχεδιάσετε και να υλοποιήσετε τη δική σας προσέγγιση shift-left. Θα χαρούμε να συζητήσουμε λοιπόν το πως μπορείτε να ξεκινήσετε ή να βελτιώσετε τη shift-left στρατηγική και υποδομή που σας ταιριάζει.
