Το πρόγραμμα δοκιμών Scrum μείον ισούται με POC σε στεροειδή.
Σήμερα, τα περισσότερα επιτυχημένα έργα ξεκινούν με ένα Proof of Concept (POC), μια σχετικά μικρού μεγέθους αξιολόγηση μιας ιδέας, όπου η επιλεγμένη τεχνολογία και το πακέτο χαρακτηριστικών θα επαληθευτεί πρώτα, θα αξιολογηθεί για πιθανές επιπτώσεις στους επιχειρηματικούς χρήστες και, στη συνέχεια, μόλις αποδειχθεί άξια επένδυσης, μια ομάδα έργου πλήρους μεγέθους ανατίθεται να σχεδιάσει και να παραδώσει το πλήρες προϊόν και να το αναπτύξει στην παραγωγή.
Αυτή είναι η τέλεια περίπτωση για μια ομάδα Scrum. Η ομάδα μπορεί να αναπτύξει γρήγορα το πρωτότυπο, προσθέτοντας σημαντικά νέα χαρακτηριστικά σε κάθε σπριντ, ενώ οι επιχειρηματίες χρήστες μπορούν να παρακολουθούν σε πραγματικό χρόνο γρήγορη πρόοδο και πώς χτίζεται η ιδέα από την αρχή μέσα σε μόλις 10 περίπου σπριντ. Αφήνει μια ισχυρή εντύπωση (που είναι ούτως ή άλλως ο κύριος στόχος του POC), αλλά έχει επίσης μια σημαντική ιδιότητα – ελάχιστες ή καθόλου δραστηριότητες δοκιμών, και ακόμη και η σκέψη για τη διαδικασία δοκιμής θα ήταν ένα απλό αστείο.
Δεν είναι διασκεδαστική δραστηριότητα μέσα σε μια ομάδα Scrum και στους ανθρώπους θα αρέσει κυρίως η ιδέα της ανάπτυξης χωρίς διαδικασίες που θα τους επιβραδύνουν. Αυτό είναι βασικά αυτό που θα κάνει σιωπηρά οποιαδήποτε δοκιμαστική δραστηριότητα. Και ποιος θέλει περιττή βραδύτητα κατά τη διάρκεια του χρόνου που χρειαζόμαστε για να εντυπωσιάσουμε περισσότερο τον τελικό χρήστη;
Η κατάσταση που συμβαίνει εάν η ομάδα του έργου συνεχίσει με τον ίδιο τρόπο μετά την ολοκλήρωση της περιόδου POC είναι κάτι που χρησιμοποιώ για να αποκαλώ POC στα στεροειδή – ένα σύστημα παραγωγής που μεγαλώνει σε μέγεθος και χαρακτηριστικά, αλλά εξακολουθεί να συμπεριφέρεται σαν POC – ένα πλήρες προϊόν wannabee με κρυφά ελαττώματα και ανεξερεύνητες γωνιακές θήκες, περιμένοντας μόνο ένα σοβαρό τρακάρισμα.
Αλλά προτού μετατραπεί εκεί, η ομάδα θα έχει δυσκολότερο χρόνο από σπριντ σε σπριντ για να συμβαδίσει με τις σταθερές εκδόσεις, καθώς η διόρθωση των κυλιόμενων προβλημάτων θα γίνει πιο περίπλοκη.
Ακολουθούν ορισμένες τεχνικές που αποδείχθηκαν ότι λειτουργούσαν όταν αντιμετώπιζα παρόμοια προβλήματα και οι οποίες πιστεύω ότι μπορούν να ονομαστούν ως βέλτιστες πρακτικές για την εφαρμογή στερεών διαδικασιών δοκιμών, χωρίς όμως να επιβαρύνεται πολύ η πρόοδος ανάπτυξης – γιατί αυτό θέλουμε όλοι να είμαστε μια ομάδα Scrum.
Πίνακας περιεχομένων
Διανείμετε τον πόνο
Πού αλλού να ξεκινήσουμε όταν ασχολούμαστε με περιττή ενόχληση παρά με το να χωρίσουμε τον πόνο :).
Και αυτό που εννοώ με αυτό είναι η δημιουργία ενός σχεδίου που θα απαιτεί μικρή πρόσθετη δραστηριότητα από τους προγραμματιστές εδώ και εκεί, αλλά που θα συμβάλει στον κοινό στόχο σε μεγάλο βαθμό με την πάροδο του χρόνου, σταδιακά αλλά με συνέπεια.
#1. Αναπτύξτε τον κωδικό δοκιμής μονάδας για κάθε δημιουργημένο κομμάτι νέου κώδικα
Εάν καταφέρετε να πείσετε τις ομάδες σας scrum να προσθέσουν στην ρήτρα Definition Of Done ανάπτυξη μοναδιαίων δοκιμών για κάθε νέο κώδικα που δημιουργείται στο sprint, τότε από μακροπρόθεσμη προοπτική, αυτό θα είναι ένα μεγάλο επίτευγμα.
Οι λόγοι είναι αρκετά προφανείς:
Θα αναγκάσει τους προγραμματιστές να σκεφτούν διάφορες μη τυπικές διαδρομές του κώδικα. –
- Τέτοιες δοκιμές μονάδων μπορούν να συνδεθούν σε αυτοματοποιημένες σωληνώσεις DevOps και να εκτελεστούν με κάθε μεμονωμένη ανάπτυξη στο περιβάλλον προγραμματισμού ή δοκιμής. Επίσης, οι μετρήσεις από τον αγωγό μπορούν εύκολα να εξαχθούν και στη συνέχεια να χρησιμοποιηθούν για επίδειξη στους επαγγελματίες χρήστες της ποσοστιαίας κάλυψης των δοκιμαστικών περιπτώσεων που συνδέονται άμεσα με τον πηγαίο κώδικα.
Το πιο σημαντικό είναι να ξεκινήσετε πολύ σύντομα. Όσο πιο αργά θα αρχίσουν να αναπτύσσονται οι δοκιμές μονάδας, τόσο πιο αποσπώντας την προσοχή οι προγραμματιστές θα τις προσθέτουν σε ένα σπριντ.
- Θα χρειαστεί σημαντική προσπάθεια για να αναπτυχθούν δοκιμές μονάδας για ήδη υπάρχοντα κώδικα. Ορισμένα τμήματα του κώδικα ενδέχεται να δημιουργηθούν από άλλον προγραμματιστή και η ακριβής γνώση του πώς θα πρέπει να λειτουργεί σε κάθε τμήμα κώδικα δεν είναι ακριβώς σαφής στον τρέχοντα προγραμματιστή. Σε ορισμένες περιπτώσεις, μπορεί να φτάσει τόσο μακριά που η προσθήκη μιας δοκιμής μονάδας στον τροποποιημένο κώδικα θα χρειαστεί περισσότερο χρόνο από την ανάπτυξη της αλλαγής χαρακτηριστικών για το σπριντ (η οποία είναι μια κατάσταση που κανείς δεν υπολόγισε σίγουρα κατά τον σχεδιασμό του σπριντ).
#2. Κάντε μια ρουτίνα εκτέλεσης όλων των τμημάτων των δοκιμών μονάδων στο περιβάλλον ανάπτυξης
Ακόμη και πριν από τη δημιουργία ενός αιτήματος έλξης για τη συγχώνευση του νέου κώδικα στον κλάδο Master, θα πρέπει να είναι μια τυπική δραστηριότητα ο έλεγχος τόσο του κώδικα χαρακτηριστικών όσο και του κωδικού δοκιμής μονάδας στο περιβάλλον dev. Με αυτόν τον τρόπο θα διασφαλιστεί ότι:
- Ο κωδικός δοκιμής μονάδας λειτουργεί στην πραγματικότητα για κάθε τμήμα (στο τέλος είναι απλώς ένας άλλος κωδικός που πρέπει να επαληθευτεί). Αυτό το βήμα πολύ συχνά παραλείπεται εντελώς. Υποτίθεται κατά κάποιο τρόπο ότι εάν η δοκιμή μονάδας είναι ούτως ή άλλως συνδεδεμένη στη διοχέτευση DevOps, τελικά θα εκτελεστεί και θα δοκιμαστεί κάπου από προεπιλογή. Ωστόσο, αυτό δεν είναι παρά να ωθήσει τα προβλήματα στα ανώτερα επίπεδα δραστηριοτήτων σπριντ, όπου η ομάδα έχει συνήθως λιγότερο χρόνο και περισσότερο άγχος για να ολοκληρώσει κάθε αφοσιωμένη ιστορία.
- Ο νέος κωδικός δυνατότητας ελέγχεται από τον προγραμματιστή για βασική λειτουργικότητα. Προφανώς, δεν μπορεί να αναμένεται από αυτήν τη δοκιμή ότι η επιχειρησιακή λειτουργικότητα θα επαληθευτεί πλήρως, αλλά τουλάχιστον αυτή η δοκιμή θα επιβεβαιώσει ότι ο κώδικας συμπεριφέρεται με τον τρόπο που τον προόριζε ο προγραμματιστής (αγνοώντας, προς το παρόν, το γεγονός ότι η επιχειρηματική λογική θα μπορούσε να γίνει εσφαλμένα κατανοητό κατά την ανάπτυξη).
#3. Αναμένεται εκτέλεση δοκιμής μονάδας μετά τη συγχώνευση κώδικα στον κύριο κλάδο
Είναι ένα πράγμα να υπάρχει λειτουργικός κώδικας στο τοπικό υποκατάστημα (όπου κανείς εκτός από τον ιδιοκτήτη του υποκαταστήματος δεν αναπτύσσει μια νέα δυνατότητα), αλλά είναι εντελώς διαφορετικό να λειτουργεί ο ίδιος κωδικός μετά το αίτημα έλξης και να συγχωνεύεται στον κύριο κλάδο.
Ο κύριος κλάδος περιέχει αλλαγές από άλλα μέλη της ομάδας Scrum και ακόμα κι αν οι διενέξεις επιλυθούν και όλα φαίνονται καλά, ο κώδικας μετά τη συγχώνευση και την επίλυση διενέξεων είναι βασικά ακόμα ένα μη δοκιμασμένο κομμάτι κώδικα και είναι επικίνδυνο να τον στείλετε περαιτέρω χωρίς πρώτα να επαληθεύσετε εξακολουθεί να λειτουργεί καλά.
Επομένως, αυτό που αποδείχθηκε αποτελεσματικό εδώ είναι απλώς να ζητήσετε να εκτελέσετε την ίδια δοκιμή μονάδας – που έχει ήδη γίνει στο παρελθόν στο περιβάλλον dev – επίσης στο περιβάλλον, το οποίο έχει δημιουργηθεί από την έκδοση κώδικα κύριας διακλάδωσης.
Για τους προγραμματιστές, μπορεί να είναι ένα επιπλέον βήμα που πρέπει να συμπεριλάβουν στη ζωή τους, αλλά δεν είναι τόσο μεγάλη προσπάθεια, καθώς, σε αυτήν την περίπτωση, δεν πρέπει να εφευρεθεί τίποτα καινούργιο – απλώς εκτελέστε ξανά αυτό που είχε ήδη γίνει μια φορά.
Τώρα, αυτό το βήμα θα μπορούσε να παραλειφθεί σε μια συγκεκριμένη περίπτωση:
- Οι αυτοματοποιημένες δοκιμές μονάδων στους αγωγούς DevOps είναι τόσο περιεκτικές που καλύπτουν ήδη ολόκληρη τη μη αυτόματη δοκιμή που εκτελείται επιπλέον.
Ενώ η επίτευξη αυτής της κατάστασης είναι σίγουρα εφικτή, δεν έχω βιώσει ποτέ μια τέτοια κατάσταση στην πραγματική ζωή. Θα ήταν πιθανώς υπερβολικά χρονοβόρο για τους προγραμματιστές να δημιουργήσουν τέτοιες λεπτομερείς αυτοματοποιημένες δοκιμές Unit. Θα μπορούσε να γίνει εύκολα απαράδεκτο για τον ιδιοκτήτη του προϊόντος να αφήσει την ομάδα να αφιερώσει τόσο πολύ χρόνο σε αυτήν τη δραστηριότητα, καθώς θα είχε ρητό αντίκτυπο στον αριθμό των παραδοθέντων ιστοριών σε ένα σπριντ.
Ωστόσο, η προτίμηση για περιεχόμενο σπριντ δεν θα αποτελεί ποτέ δικαιολογία για να μην κάνετε τις δοκιμές μονάδας ή ακόμη και να τις ελαχιστοποιήσετε. Κάνοντας αυτό, η ομάδα θα μετατρέψει ξανά σε μια τέτοια κατάσταση ότι ο κωδικός δεν έχει υπερβολική κάλυψη δοκιμής μονάδας και, στη συνέχεια, για μια κάλυψη, μπορεί να είναι ήδη πολύ αργά (και πάλι, η μεγαλύτερη προσπάθεια για την ολοκλήρωση της δοκιμής μονάδας από την πραγματική αλλαγή κώδικα για ένα σπριντ).
Για όλους αυτούς τους λόγους, θα συνιστούσα την επανεκτέλεση των δοκιμών μονάδας στην έκδοση του κύριου κώδικα χωρίς δισταγμούς. Είναι τόσο χαμηλή προσπάθεια σε σύγκριση με την αξία που θα φέρει.
Θα κάνει τον τελικό έλεγχο για την ετοιμότητα του κύριου κλάδου για τη φάση δοκιμής απελευθέρωσης. Επίσης, θα βοηθήσει στην εύρεση των περισσότερων τεχνικών σφαλμάτων (π.χ. σφάλματα που εμποδίζουν την επιτυχή εκτέλεση του πηγαίου κώδικα μέχρι το επιτυχές τέλος), αφήνοντας στην επόμενη φάση να επικεντρωθούμε αποκλειστικά στην επαλήθευση της επιχειρησιακής λειτουργικότητας.
Προετοιμαστείτε για Λειτουργικές Δοκιμές
Όλες οι προηγούμενες δοκιμαστικές δραστηριότητες θα οδηγήσουν σε ένα συγκεκριμένο συμπέρασμα – ο κύριος κώδικας κλάδου είναι απαλλαγμένος από τεχνικά σφάλματα και μπορεί να εκτελεστεί χωρίς προβλήματα για λειτουργικές ροές από άκρο σε άκρο.
Αυτή είναι μια φάση που μπορεί εύκολα να καλύψει μόνο ένα άτομο, και αυτό το άτομο δεν χρειάζεται καν να έχει τεχνικό υπόβαθρο.
Στην πραγματικότητα, είναι πολύ καλύτερο εάν αυτό εκτελείται από κάποιον αποσυνδεδεμένο από τους προγραμματιστές, αλλά με λειτουργική επίγνωση του πώς περιμένουν οι επιχειρησιακοί χρήστες να συμπεριφέρεται ο κώδικας. Υπάρχουν δύο κύριες δραστηριότητες που πρέπει να ολοκληρωθούν:
#1. Νέα στοχευμένη λειτουργική δοκιμή ιστορίες σπριντ
Κάθε σπριντ θα φέρει ιδανικά κάποια νέα λειτουργικότητα (αύξηση στόχου σπριντ) που προηγουμένως δεν υπήρχε, και έτσι θα επαληθευτεί. Είναι σημαντικό να διασφαλίσουμε ότι το νέο κομμάτι λογισμικού λειτουργεί σε τέτοιο βαθμό ώστε οι επιχειρησιακοί χρήστες να το έχουν στην ευχάριστη θέση να το έχουν τώρα, καθώς προφανώς το περίμεναν με ανυπομονησία τουλάχιστον για ολόκληρο το τελευταίο σπριντ :).
Είναι τόσο θλιβερή εμπειρία όταν η (μακροχρόνια) υποσχεθείσα λειτουργικότητα ανακοινώνεται τελικά ότι θα κυκλοφορήσει, μόνο για να μάθουμε ότι την άλλη μέρα δεν λειτουργεί καλά.
Επομένως, η σωστή δοκιμή νέων λειτουργιών sprint είναι ζωτικής σημασίας. Προκειμένου να επιτευχθεί αυτό, είναι καλή πρακτική να συγκεντρώνονται εκ των προτέρων σημαντικές περιπτώσεις δοκιμών και από σχετικούς ενδιαφερόμενους φορείς (είτε από τον ιδιοκτήτη του προϊόντος είτε ακόμη και από τους τελικούς χρήστες) και να δημιουργείτε μια λίστα με όλες αυτές τις περιπτώσεις δοκιμών που απαιτούνται για το περιεχόμενο εντός το σπριντ.
Αυτό μπορεί να φαίνεται συντριπτικό με την πρώτη ματιά, αλλά από την εμπειρία μου, είναι και πάλι απολύτως διαχειρίσιμο από ένα μόνο άτομο. Δεδομένου ότι τα σπριντ είναι ως επί το πλείστον αρκετά σύντομα (όπως σύντομες δύο εβδομάδες), ούτως ή άλλως δεν είναι σχεδόν ποτέ πολύ νέο περιεχόμενο, καθώς το σπριντ περιέχει επίσης πρόσθετες δραστηριότητες όπως τεχνικές ιστορίες χρεών, τεκμηρίωση, ιστορίες σχεδίασης/αιχμής κ.λπ.
Οι δοκιμαστικές περιπτώσεις εκτελούνται στη συνέχεια με στόχο την επαλήθευση της επιθυμητής λειτουργικότητας κυρίως. Εάν παρουσιαστεί οποιοδήποτε πρόβλημα με τα αποτελέσματα, προσεγγίζεται μόνο ο σχετικός προγραμματιστής (αυτός που κατέχει τις αλλαγές που σχετίζονται με αυτό το συγκεκριμένο ελάττωμα) για να επιλυθεί το πρόβλημα, ελπίζουμε, γρήγορα.
Με αυτόν τον τρόπο, οι προγραμματιστές θα αφιερώσουν ελάχιστο χρόνο σε σχέση με τις λειτουργικές δοκιμές και θα μπορούν ακόμα να επικεντρωθούν στις δραστηριότητες που τους αρέσουν περισσότερο.
#2. Εκτέλεση περιπτώσεων δοκιμής παλινδρόμησης
Το άλλο μέρος της λειτουργικής δοκιμής θα είναι να διασφαλιστεί ότι όλα όσα λειτουργούσαν μέχρι τώρα θα λειτουργήσουν και μετά την επόμενη έκδοση. Για αυτό χρησιμεύουν τα τεστ παλινδρόμησης.
Οι περιπτώσεις δοκιμών για δοκιμές παλινδρόμησης είναι καλύτερες εάν διατηρούνται τακτικά και επανεξετάζονται πριν από κάθε έκδοση. Με βάση τις συγκεκριμένες ιδιαιτερότητες του έργου, είναι καλύτερο να διατηρούνται απλές, αλλά να καλύπτουν την πλειονότητα των πολύ βασικών λειτουργιών και των σημαντικών ροών από άκρο σε άκρο που διατρέχουν ολόκληρο το σύστημα.
Συνήθως, κάθε σύστημα έχει τέτοιες διαδικασίες που αγγίζουν πολλές διαφορετικές περιοχές, αυτές είναι οι καλύτερες υποψήφιες για περιπτώσεις δοκιμών παλινδρόμησης.
Σε ορισμένες περιπτώσεις, οι δοκιμές παλινδρόμησης καλύπτουν ακόμη και έμμεσα και νέα χαρακτηριστικά στο σπριντ, για παράδειγμα, εάν η νέα ιστορία στο σπριντ αλλάζει κάποιο συγκεκριμένο μέρος της υπάρχουσας ροής.
Έτσι, στις περισσότερες περιπτώσεις, δεν είναι καθόλου πολύπλοκο να ολοκληρώσετε δοκιμές παλινδρόμησης μαζί με νέες δοκιμές λειτουργικότητας ιστοριών sprint, ειδικά εάν αυτό γίνεται τακτικά πριν από κάθε κυκλοφορία παραγωγής και η περιοδικότητα των εκδόσεων παραγωγής δεν είναι πολύ μικρή.
Επιμείνετε στην εκτέλεση δοκιμών Διασφάλισης Ποιότητας πριν από κάθε κυκλοφορία παραγωγής
Η δοκιμή Διασφάλισης Ποιότητας (QA) είναι το τελευταίο βήμα πριν από την κυκλοφορία στην παραγωγή και συχνά αυτή η δοκιμή παραλείπεται ως ασήμαντη. Ειδικά αν η ομάδα scrum ελέγχεται επιθετικά για νέο περιεχόμενο.
Ακόμη και οι επαγγελματίες χρήστες θα πουν ότι ενδιαφέρονται για νέες δυνατότητες και όχι τόσο για τη διατήρηση της λειτουργικότητας ή τη διατήρηση του αριθμού των ελαττωμάτων σε χαμηλά επίπεδα. Αλλά και πάλι – με την πάροδο του χρόνου, αυτός είναι ο κύριος λόγος για τον οποίο η ομάδα προγραμματιστών θα πρέπει να επιβραδύνει τελικά και στη συνέχεια οι επιχειρηματίες χρήστες δεν θα λάβουν ούτως ή άλλως αυτό που ζητούν.
Η δοκιμή QA θα εκτελείται αποκλειστικά από άτομα εκτός της ομάδας Scrum, ιδανικά από τους ίδιους τους επαγγελματίες χρήστες σε ένα αποκλειστικό περιβάλλον, το οποίο είναι όσο το δυνατόν πιο κοντά στη μελλοντική παραγωγή. Εναλλακτικά, ο ιδιοκτήτης του προϊόντος μπορεί να αντικαταστήσει εδώ τους τελικούς χρήστες.
Σε κάθε περίπτωση, αυτό θα πρέπει να είναι ένα καθαρό, λειτουργικό τεστ από την οπτική γωνία του τελικού χρήστη, χωρίς καμία σύνδεση με την ομάδα του dev Scrum. Θα παρουσιάσει μια τελική άποψη του προϊόντος και θα χρησιμοποιηθεί με τρόπο που πιθανώς κανείς από την ομάδα του scrum δεν περίμενε (καθόλου ιδανική περίπτωση, αλλά σίγουρα μπορεί να συμβεί). Υπάρχει ακόμη χρόνος για διορθώσεις της τελευταίας στιγμής.
Εναλλακτικά, μπορεί να γίνει σαφές ότι οι προσδοκίες δεν έγιναν καλά κατανοητές από την ομάδα του scrum, και σε αυτήν την περίπτωση, τουλάχιστον μπορούμε να συμφωνήσουμε σε ένα σχέδιο παρακολούθησης, πολύ πριν από την πραγματική κυκλοφορία της παραγωγής. Και πάλι δεν είναι ιδανική περίπτωση, αλλά και πάλι σαν να παραδεχόμαστε την αποτυχία αμέσως μετά την αναφορά μιας επιτυχημένης κυκλοφορίας παραγωγής.
Πού να πάτε μετά από εδώ;
Η εφαρμογή αυτών των πρακτικών στην καθημερινή εργασία του scrum μπορεί να σας φέρει σοβαρά σε πιο σταθερές και προβλέψιμες συνήθειες απελευθέρωσης sprint, χωρίς να καθυστερήσετε τις εκδόσεις παραγωγής ή να ξοδέψετε ολόκληρο το σπριντ μόνο στην προετοιμασία για την επόμενη κυκλοφορία ή ακόμα και χωρίς να αναγκάσετε όλους στην ομάδα του scrum να κάνουν κάτι που κάνουν Δεν μου αρέσει πολύ ή δεν ξέρω πώς να κάνω αποτελεσματικά ούτως ή άλλως για το μεγαλύτερο μέρος του σπριντ, δηλαδή.
Αλλά σίγουρα δεν χρειάζεται να σταματήσετε εδώ.
Η συμπερίληψη της δοκιμής απόδοσης είναι ένα θέμα που πρέπει να αναφέρουμε εδώ. Αυτά συχνά αγνοούνται ή θεωρούνται περιττά, γρατσουνίζοντας στον πρώτο γύρο της «βελτιστοποίησης δραστηριοτήτων scrum». Ωστόσο, ήμουν πάντα αμφίβολος για το πώς μπορεί κανείς να περιμένει ότι το σύστημα παραγωγής θα εξελιχθεί με την πάροδο του χρόνου, εάν δεν ελέγχεται τακτικά για απόδοση.
Η άνοδος κατά ένα επίπεδο σημαίνει επίσης την εισαγωγή αυτοματοποιημένων δοκιμών.
Έχω ήδη καλύψει μια ομάδα αυτοματοποιημένων δοκιμών (unit tests in pipelines). Ωστόσο, μπορείτε να αναπτύξετε πλήρεις δοκιμές παλινδρόμησης από άκρο σε άκρο πλήρως αυτοματοποιημένες και εκτελούμενες από μόνες τους μετά από κάθε ανάπτυξη στο περιβάλλον δοκιμής. Αυτό θα απελευθέρωνε ακόμη περισσότερο την ομάδα ανάπτυξης scrum, αλλά απαιτεί μια ειδική ομάδα για την ανάπτυξη και τη συντήρηση τέτοιων αυτοματοποιημένων δοκιμών. Θα γινόταν συνεχής εργασία, καθώς όποτε αλλάζει ο κώδικας παραγωγής, ορισμένες υπάρχουσες αυτοματοποιημένες δοκιμές μπορεί να καταστούν άκυρες, και επομένως πρέπει να ενημερωθούν για να συνεχίσουν να εργάζονται στους αγωγούς. Είναι μια προσπάθεια για την οποία μόνο λίγοι είναι πρόθυμοι να πληρώσουν, τα οφέλη για την ομάδα dev scrum θα ήταν, ωστόσο, μεγάλα.
Αυτά είναι θέματα που ξεπερνούν το πεδίο εφαρμογής αυτού του άρθρου και υπολογίζουν το σωστό χρονοδιάγραμμα και το σωστό χρονοδιάγραμμα για κάθε τύπο δοκιμής που αναφέρεται εδώ – έτσι ώστε να μπορείτε να το κάνετε μέσα σε ένα παράθυρο σπριντ. Θα χαρώ να βουτήξω την επόμενη φορά!