Μενού

Τι είναι το τεχνικό χρέος και γιατί οι υπεύθυνοι δοκιμών QA πρέπει να ενδιαφέρονται γι 'αυτό;

  • Κύριος
  • Ευέλικτη Δοκιμή
  • Τι είναι το τεχνικό χρέος και γιατί οι υπεύθυνοι δοκιμών QA πρέπει να ενδιαφέρονται γι 'αυτό;

what is technical debt

Δοκιμάστε Το Όργανο Μας Για Την Εξάλειψη Των Προβλημάτων

Τεχνικό χρέος είναι μια μεταφορική ιδέα που υποστηρίζει ότι όπως κάποιος μπορεί να αντιμετωπίσει προβλήματα χρέους στη χρηματοδότηση, οι οργανισμοί λογισμικού συναντούν κάτι παρόμοιο στη δημιουργία ημιτελών εργασιών κατά τη διάρκεια προηγούμενων έργων και εκδόσεων / σπριντ έκδοσης.

Τι είναι το τεχνικό χρέος;

Αντιπροσωπεύει την προσπάθεια που απαιτείται για την επίλυση των προβλημάτων / ελαττωμάτων που παραμένουν στον κώδικα κατά την κυκλοφορία μιας εφαρμογής. Με απλά λόγια - είναι η διαφορά (όσον αφορά τα σφάλματα) μεταξύ του αναμενόμενου και του παραδοτέου.

Όταν μια ομάδα ανάπτυξης είναι απασχολημένη με την εργασία σε ένα έργο και τη διόρθωση σφαλμάτων δυστυχώς, εμφανίζονται πολλά νέα σφάλματα. Εκτός αυτά, μερικά είναι σταθερά και άλλα διαφέρουν για μεταγενέστερη κυκλοφορία. Όταν αυτό το διαφορετικό ζήτημα συνεχίζει να αυξάνεται, σε ένα σημείο γίνεται πραγματικά δύσκολο να κυκλοφορήσει το προϊόν εγκαίρως χωρίς προβλήματα. Αυτή είναι η χειρότερη συνέπεια του Τεχνικό χρέος αν δεν αντιμετωπιστεί εγκαίρως.

Σε αυτό το άρθρο, θα μάθετε - τι είναι το τεχνικό χρέος, γιατί η ομάδα QA πρέπει να ανησυχεί για αυτό και το πιο σημαντικό πώς να το διαχειριστεί.

τι είναι τεχνολογικό χρέος

εικόνα πηγή

Ward Cunningham , ο ιδρυτής του λογισμικού wiki, συνέλαβε αυτήν την ιδέα πίσω στη δεκαετία του 1990, προσελκύοντας παράλληλα με τις επιπτώσεις του κακού χρέους στη χρηματοπιστωτική βιομηχανία, κυριολεκτικά υπαινίσσεται τη δυσάρεστη εμπειρία του να πρέπει να πληρώσουμε υπερβολικά χρήματα τόκων μετά την αθέτηση χρεών.

ποιο είναι το νεότερο λειτουργικό σύστημα

Η πρόκληση της αύξησης του τεχνολογικού χρέους ανά σπριντ μπορεί να απεικονιστεί στο Σχ. 1.

Πρέπει να αναφερθεί εδώ, ωστόσο, ότι υπάρχει μια μικρή διαφορά στην έννοια του τεχνικού χρέους (επίσης γνωστό ως κωδικός χρέος ή χρέος σχεδιασμού) από την αντίστοιχη αναλογία του στον κόσμο των οικονομικών - το πρώτο μοιάζει περισσότερο με αφηρημένη ιδέα , χωρίς μαθηματικές εξισώσεις για να φανταστεί κανείς πώς πραγματικά συσσωρεύεται το ενδιαφέρον.

αυξανόμενο τεχνικό χρέος

Σχήμα 1: Οπτικοποίηση της κλιμακούμενης αύξησης του τεχνολογικού χρέους μεταξύ των σπριντ

Τι θα μάθετε:

Γιατί οι ομάδες QA υποφέρουν περισσότερο λόγω τεχνικού χρέους

Κατά τη διάρκεια ενός τυπικού κύκλου σχεδιασμού και ανάπτυξης λογισμικού, υπάρχουν πολλά πράγματα που μπορούν να οδηγήσουν σε ' τεχνικό χρέος 'Σαν κατάσταση- ακατάλληλη τεκμηρίωση , ανεπαρκής δοκιμή και διόρθωση σφαλμάτων, έλλειψη συντονισμού μεταξύ ομάδων, κληρονομιά κωδικός και καθυστερημένη ανακατασκευή , απουσία συνεχής ενσωμάτωση και άλλους εκτός ελέγχου παράγοντες.

Για παράδειγμα, έχει παρατηρηθεί ότι οι προσπάθειες αναπαραγωγής κώδικα μπορούν να οδηγήσουν σε οτιδήποτε μεταξύ 25 προς την 35% επιπλέον δουλειά.

ερωτήσεις και απαντήσεις συνέντευξης μοντελοποίησης δεδομένων pdf

Ωστόσο, πουθενά δεν είναι προκλήσεις λόγω τεχνικού χρέους πιο εμφανείς από ό, τι στις δοκιμές QA όπου οι δοκιμαστικές ομάδες πρέπει να τηρούν απροσδόκητες προθεσμίες και τα πάντα μπορεί να απορριφθούν.

Πόσο συχνά αντιμετώπισαν οι υπεύθυνοι δοκιμασίας την τελευταία στιγμή όταν απροσδόκητα, ο διευθυντής παράδοσης ήρθε και τους είπε: «Ομάδα! Πρέπει να διαθέσουμε το προϊόν μας σε μια εβδομάδα, συγνώμη που δεν μπόρεσα να το κοινοποιήσουμε εγκαίρως. Ολοκληρώστε επειγόντως όλες τις δοκιμαστικές εργασίες, ώστε να είμαστε έτοιμοι με την επίδειξη. '

Βασικά, τυχόν χαμένες δοκιμές ή προσέγγιση 'επίλυση αργότερα' μπορεί να οδηγήσει σε πρόβλημα τεχνολογικού χρέους. Έλλειψη κάλυψης δοκιμών , οι υπερμεγέθης ιστορίες χρηστών, τα σύντομα σπριντ και άλλα παραδείγματα «κόρνερ» λόγω της πίεσης παράδοσης παίζουν τεράστιο ρόλο πίσω από τη συσσώρευση τεχνικού χρέους στην εξάσκηση QA.

Ένα πραγματικό παράδειγμα

Ένας διαδικτυακός έμπορος λιανικής με έδρα τις ΗΠΑ με σημαντική παρουσία σε πολλούς ιστότοπους και εφαρμογές για κινητά βρέθηκε σε μια πρόκληση «τεχνικού χρέους» σε πραγματικό κόσμο, όταν η πολυπλοκότητα του πλέγματος δοκιμών άρχισε να συνδυάζεται με κάθε νέο τρέχω .

Αυτό συνέβη λόγω της ξαφνικής αύξησης του αριθμού των κινητών συσκευών που θα δοκιμαστούν, πολλαπλών γλωσσών που θα υποστηρίζονται και περισσότερων από μισών δωδεκάδων ιστότοπων κοινωνικής δικτύωσης που θα αξιοποιηθούν.

Με κάλυψη αυτοματισμού μικρότερο από 40%, η πρόκληση τεχνολογικού χρέους θα εμφανιστεί με τους ακόλουθους τρόπους:

  • Υπερβολική κατανάλωση χρόνου στη δοκιμή απελευθέρωσης - Με τον αριθμό των προγραμμάτων περιήγησης, των συσκευών και των σεναρίων που αυξάνονται με κάθε δοκιμαστικό σπριντ, ο κύκλος κυκλοφορίας θα καθυστερούσε με αποτέλεσμα την απώλεια χρόνου προς αγορά.
  • Το αυξανόμενο κόστος πρόσληψης - Ο αριθμός των υπεύθυνων δοκιμών που χρειάστηκε για να υποστηρίξει το έργο σχεδόν διπλασιάστηκε, ο οποίος μεταφράστηκε σε επιπλέον κόστος 500.000 $
  • Πολυπλοκότητα στο έργο - Με την αυξανόμενη πολυπλοκότητα του έργου, η παρακολούθηση των δοκιμαστικών περιπτώσεων και των σφαλμάτων έγινε μια πρόκληση
  • Πολύς χρόνος σπαταλήθηκε για να κυνηγήσει ψευδώς θετικά - Και πάλι, μια πτώση των αυξανόμενων πολυπλοκότητας του έργου.
  • Αύξηση της προσπάθειας ανάπτυξης δοκιμών έως και 60% - Ταιριάζει με το έδαφος

Διαχείριση τεχνολογικού χρέους στις Πρακτικές QA

Οι περισσότεροι διευθυντές QA βλέπουν παρορμητικά το τεχνολογικό χρέος ως τη λογική συνέπεια της εστίασης όλης της ενέργειάς σας στο τρέχον σπριντ μόνο, το οποίο οδηγεί στην επίτευξη της δοκιμαστικής κάλυψης κάπως με χειροκίνητα μέσα και αγνοεί εντελώς τον αυτοματισμό.

Αυτό είναι γνωστό ως γρήγορη και βρώμικη προσέγγιση το οποίο έχει καλυφθεί σε ένα blog από τον Martin Fowler, τον συγγραφέα του τεταρτημόριο τεχνικού χρέους .

Οι ευέλικτες αρχές υπαγορεύουν ότι βλέπουμε το πρόβλημα του τεχνολογικού χρέους ως αδυναμία τήρησης και κάλυψης Σημεία αναφοράς QA .

Στην πραγματικότητα, με βάση μια έρευνα από το Εθνικό Ινστιτούτο Προτύπων και Τεχνολογίας (NIST), τα ανεπαρκή εργαλεία και μέθοδοι δοκιμών στοιχίζουν ετησίως την οικονομία των ΗΠΑ 22,2 $ και 59,5 δισεκατομμύρια δολάρια , με περίπου το ήμισυ αυτών των χρημάτων να δαπανώνται για επιπλέον δοκιμές από προγραμματιστές λογισμικού και περίπου το ήμισυ από χρήστες λογισμικού για την αποφυγή αποτυχιών.

Αντί να αντιδράσουμε σε αποτυχίες καθώς και όταν συμβαίνει το συμβάν, μια προληπτική προσέγγιση θα ήταν να εντοπίσουμε ελαττώματα μετά από κάθε δραστηριότητα ή εργασία που μπορεί να μετρηθεί. Μπορείτε να τα κάνετε όλα με μη αυτόματο τρόπο, αλλά δεδομένου των χιλιάδων σεναρίων δοκιμαστικών περιπτώσεων για ένα μέσο έργο, ο αυτοματοποιημένος έλεγχος δοκιμών είναι απαραίτητη.

Σαφώς, αποτελεσματική δοκιμή μπορεί να σας βοηθήσει να αποκτήσετε σοβαρό έδαφος στον πόλεμο για το τεχνικό χρέος. Λοιπόν, τι σημαίνει βασικά; Αυτό σημαίνει πόσο καλά εξοπλισμένο είναι το σύστημά σας στον εντοπισμό ελαττωμάτων στη συνολική εφαρμογή.

δοκιμή αποτελεσματικότητας

Όπως δείχνει η παραπάνω εξίσωση, η αποτελεσματικότητα της δοκιμαστικής περίπτωσης μπορεί θεωρητικά να προσεγγίσει ακόμη και το 100% εάν ο αριθμός των ελαττωμάτων που βρέθηκαν από τον πελάτη (δηλ. Ελαττώματα μετά την παραγωγή) είχε χαρτογραφηθεί ακριβώς στον αριθμό των ελαττωμάτων που εντοπίστηκαν σε κάθε στάδιο της κάλυψης δοκιμών.

Προκειμένου να έχουμε ένα καλά σχεδιασμένο δοκιμαστικό κρεβάτι που να μπορεί να μετρήσει με ακρίβεια τα ελαττώματα μόλις εισέλθουν, ο αυτοματισμός είναι απαραίτητη προϋπόθεση.

Δοκιμές αυτοματισμού σας βοηθά να ελαχιστοποιήσετε τον αριθμό των σεναρίων που εκτελούνται αναφέροντας αποτελέσματα και συγκρίνοντάς τα με προηγούμενες δοκιμές. Η μέθοδος ή η διαδικασία που χρησιμοποιείται για την εκτέλεση αυτοματισμού ονομάζεται δοκιμή αυτοματοποίηση δομή .

Τυπικά παραδείγματα θα ήταν εμπορικά-εκτός του ράφι ή δωρεάν εργαλεία όπως το Selenium, MonkeyTalk, ρομπότ , Borland SilkCentral, HP Quality Center και IBM Rational Rose .

Στο παρελθόν, το QA / testing συχνά θεωρούνταν από οργανισμούς και τις ομάδες λογισμικού τους ως δραστηριότητα υποστήριξης σε πιο σημαντικά παραδοτέα των επιχειρήσεων, και όχι από μόνη της μια πειθαρχημένη πρακτική που θα απαιτούσε βασική, αποκλειστική εστίαση. Στην πραγματικότητα, μια μη βασική προσέγγιση στο QA / testing είναι ακριβώς αυτό που οδήγησε στην συνεχιζόμενη πρόκληση του τεχνικού χρέους.

Λαμβάνοντας υπόψη τον ταχύ ρυθμό εξέλιξης των δεξιοτήτων δοκιμής QA / δοκιμών που σημειώθηκε την τελευταία δεκαετία, οι οργανισμοί δυσκολεύονται πραγματικά να αναβαθμίσουν τις δεξιότητες και τις ικανότητές τους στα ελάχιστα επιθυμητά επίπεδα σύμφωνα με τα τρέχοντα σημεία αναφοράς της βιομηχανίας.

Στην πραγματικότητα, υπάρχει μια αυξανόμενη τάση της βιομηχανίας να κάνει τίποτα λιγότερο από τους πιο έμπειρους επαγγελματίες στον αυτοματισμό δοκιμών - κάτι σαν τα κορυφαία κομάντο δοκιμών / QA. είναι γνωστοί ως μηχανικοί λογισμικού σε δοκιμή ( Από και προγραμματιστές λογισμικού σε δοκιμή ( SDiT ). Αυτοί οι επαγγελματίες έχουν μεγάλη ζήτηση λόγω της τεράστιας εμπειρίας τους σε έναν επιλεγμένο κλάδο (π.χ. ηλεκτρονικό εμπόριο) ή σε μια συγκεκριμένη επαγγελματική κατηγορία.

Οι περισσότερες εταιρείες ανάπτυξης λογισμικού και προϊόντων, όπως μιλάμε τώρα, αγωνίζονται να βρουν τους επιθυμητούς, εξειδικευμένους τεχνικούς πόρους ενόψει μικρότερων χρόνων παράδοσης. Η λύση σε αυτήν την πρόκληση είναι να συνεργαστείτε με έναν υπεράκτιο παίκτη αυτοματισμού QA που μπορεί να αντιμετωπίσει την έλλειψη δεξιοτήτων σας με τη σωστή ομάδα πόρων SDiT / SEiT.

Άλλα επιθυμητά χαρακτηριστικά ενός παίκτη εξωτερικής ανάθεσης στο QA / Testing που αποδεικνύεται χρήσιμο περιλαμβάνουν μια ευέλικτη, πειθαρχημένη προσέγγιση στην εκτέλεση έργου, επαρκή εμπειρία στον κλάδο, συμπεριλαμβανομένης της πρακτικής πρόσβασης σε επαναχρησιμοποιήσιμα πλαίσια αυτοματισμού και δοκιμαστικών περιπτώσεων, και τελευταίο αλλά όχι το λιγότερο, μια σαφής πρόθεση και ικανότητα αντιμετώπισης απομακρυσμένων προκλήσεων ομάδων και πολιτιστικών συγκρούσεων, έτσι ώστε ο πελάτης να μην επιβαρύνεται με επιπλέον εργασία στη διαχείριση εργολάβων.

συμπέρασμα

Όπως κάθε άλλο χρέος, το τεχνικό χρέος μπορεί να αποδειχθεί ότι είναι ο όγκος των επιχειρήσεων και η βασική αιτία της συσσώρευσής του είναι η αποτυχία εφαρμογής μιας προληπτικής πρακτικής QA που αφαιρεί όλα τα καθυστερούμενα αυτοματοποιημένα.

πώς μπορώ να ανοίξω αρχεία δεδομένων

Σχετικά με τον συγγραφέα: Αυτή είναι η θέση επισκεπτών της ομάδας eInfochips. Έχουν βρει μια μοναδική προσέγγιση που ονομάζεται Μηδενικό τεχνολογικό χρέος που είναι ένας από τους πιο δομημένους και αποτελεσματικούς τρόπους για τη σταδιακή εξάλειψη του τεχνικού χρέους στις δραστηριότητες QA / αυτοματισμού. Για να μάθετε περισσότερα σχετικά με το τεχνολογικό χρέος, Δες αυτο το βιντεο σχετικά με μια προσέγγιση για τη μείωση του τεχνολογικού τμήματος

Ελπίζω να έχετε τη σαφή ιδέα για το τι είναι το τεχνικό χρέος. Ενημερώστε μας αν έχετε ερωτήματα σχετικά με αυτό ή πώς να το διαχειριστούμε στην πράξη.

Συνιστώμενη ανάγνωση

^