Πέντε (Λανθασμένοι) Λόγοι για να μην έχετε Τεχνικούς Δοκιμών

From The Joel on Software Translation Project

Jump to: navigation, search

από τον Ιωήλ Σπολσκι
Μεταφραστής ο Δημήτρης Στάικος
Κυριακή 30 Απριλίου 2000

To 1992, o James Gleick είχε πολλά προβλήματα με προβληματικό λογισμικό. Μια νέα έκδοση του Microsoft Word για Windows είχε μόλις βγει, την οποία ο Gleick, συγγραφέας επιστημονικών άρθρων θεωρούσε απαίσια. Έγραψε ένα μεγάλο άρθρο στο περιοδικό των κυριακάτικων New York Times το οποίο μπορούσε να χαρακτηριστεί μόνο σαν flame, κατακεραυνώνοντας την ομάδα ανάπτυξης του Word ότι δεν ανταποκρίθηκε στις απαιτήσεις των πελατών και ότι παρέδωσε ένα υπερβολικά προβληματικό προϊόν.

Αργότερα, σαν πελάτης ενός τοπικού παροχέα Διαδικτύουπου ονομαζόταν Panix (και ο οποίος συμβαίνει να είναι και ο δικός μου παροχέας) ήθελε έναν τρόπο να ταξινομεί και να φιλτράρει αυτόματα το ηλεκτρονικό του ταχυδρομείο. Το εργαλείο του UNIX για αυτό το σκοπό ονομάζεται procmail, το οποίο είναι πραγματικά αρχαϊκό και έχει το είδος διεπαφής (interface) το οποίο ακόμα και οι πιο φανατικοί οπαδοί του UNIX θα παραδεχτούν ότι είναι ομιχλώδες.

Ο κύριος Gleick λοιπόν αναπόφευκτα έκανε κάποιο αθώο τυπογραφικό λάθος στο procmail το οποίο διέγραψε όλο του το ηλεκτρονικό ταχυδρομείο. Βράζοντας από θυμό, αποφάσισε ότι θα δημιουργούσε τη δική του εταιρία παροχής πρόσβασης στο Διαδίκτυο. Προσέλαβε έναν προγραμματιστή, ονόματι Uday Ivatury, και δημιούργησε την Pipeline, η οποία ήταν πραγματικά μπροστά από την εποχή της: ήταν ο πρώτος εμπορικός παροχέας Internet ο οποίος διέθετε γραφική διεπαφή με το χρήστη (GUI).

Βέβαια και η Pipeline είχε τα προβληματάκια της. Η πρώτη πρώτη έκδοση δεν χρησιμοποιούσε κανενός είδους πρωτόκολλο για τη διόρθωση των σφαλμάτων, και έτσι είχε μια μικρή τάση να παράγει σκουπίδια και να κρασάρει. Όπως όλα τα προγράμματα λογισμικού, είχε σφάλματα. Είχα κάνει αίτηση για δουλειά στην Pipeline το 1993. Κατά τη διάρκεια της συνέντευξης, ρώτησα τον κύριο Glick σχετικά με το άρθρο που είχε γράψει. "Τώρα που είστε στην άλλη πλευρά του φράχτη" ρώτησα, "έχετε λίγο περισσότερη εκτίμηση για το πόσο δύσκολη υπόθεση είναι η δημιουργία καλού λογισμικού;"

Ο Gleick ήταν ανένδοτος. Αρνήθηκε ότι το λογισμικό της Pipeline είχε λάθη. Αρνήθηκε ότι ήταν κάτι τόσο άσχημο όσο το Microsoft Word. Μου είπε: "μια μέρα Ιωήλ, και εσύ θα καταλήξεις να μισείς τη Microsoft". Έμεινα λίγο έκπληκτος από το γεγονός ότι ένας ολόκληρος χρόνος εμπειρίας σαν δημιουργός λογισμικού, όχι απλά σαν χρήστης, δεν του είχε δώσει ούτε ίχνος εκτίμησης για το πόσο δύσκολο είναι να φτιάξεις λογισμικό που είναι εύχρηστο και δεν περιέχει σφάλματα. Συνεπώς την "έκανα", απορρίπτοντας την προσφορά για εργασία. (H Pipeline στη συνέχεια εξαγοράστηκε από την PSI, τον πιο περίεργο παροχέα Διαδικτύου στον πλανήτη, και αργότερα εντελώς κυνικά εξαναγκάστηκε να κλείσει).

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

Και αυτός είναι ο λόγος που οπωσδήποτε χρειάζεται να διαθέτετε ένα τμήμα QA (Quality Assurance = Διασφάλιση Ποιότητας). Θα χρειαστείτε 1 τεχνικό δοκιμών (tester) για κάθε 2 προγραμματιστές (περισσότερους αν το λογισμικό σας πρέπει να λειτουργεί κάτω από πολλά, διαφορετικά και πολύπλοκα περιβάλλοντα και λειτουργικά συστήματα). Κάθε προγραμματιστής πρέπει να συνεργάζεται στενά με ακριβώς έναν τεχνικό δοκιμών, παρέχοντάς του δοκιμαστικές εκδόσεις της εφαρμογής όσο συχνά χρειάζεται.

Το τμήμα Διασφάλισης Ποιότητας (QA) πρέπει να είναι ανεξάρτητο και ισχυρό, να μην αναφέρεται στην ομάδα ανάπτυξης, και μάλιστα ο επικεφαλής του τμήματος να έχει δικαίωμα βέτο στην ανακοίνωση έκδοσης η οποία δεν περνάει τα κριτήρια ποιότητας.

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

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

Θα περίμενε κανείς ότι μετά από την μανία της δεκαετίας του 80 σχετικά με την Ποιότητα, με κάθε είδους χωρίς νόημα διεθνείς πιστοποιήσεις "ποιότητας" όπως το ISO-9000 και όρους κλισέ όπως το "six-sigma", σήμερα οι υπεύθυνοι ομάδων και οι διευθυντές θα είχαν κατανοήσει ότι το να παράγεις προϊόντα υψηλής ποιότητας είναι αποδοτικό για τις εταιρίες. Και πράγματι το έχουν κατανοήσει. Αλλά ακόμα λένε ότι έχουν ένα κάρο λόγους να μην έχουν τεχνικούς δοκιμών, οι οποίοι είναι όλοι λανθασμένοι.

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

Αυτή είναι η λίστα με τις πιο μωρουδίστικες δικαιολογίες που έχω ακούσει για να μην προσλαμβάνονται τεχνικοί δοκιμών:

Contents

1. Τα σφάλματα προέρχονται από τους τεμπέληδες προγραμματιστές

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

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

Όταν έγραφα κώδικα στη Juno, είχα τη συνήθεια να δοκιμάζω τον κώδικά μου με τον ίδιο τρόπο κάθε φορά... Χρησιμοποιούσα τις δικές μου συνήθειες, βασιζόμενος πάρα πολύ στο ποντίκι. Η εκπληκτική και τρομερά έμπειρη μηχανικός δοκιμών μας είχε λίγο διαφορετικές συνήθειες: έκανε περισσότερα πράγματα με το πληκτρολόγιο (και δοκίμαζε εντατικά τη διεπαφή μας χρησιμοποιώντας κάθε πιθανό συνδιασμό πλήκτρων). Αυτή η τακτική σύντομα αποκάλυψε μια αρμαθιά από σφάλματα. Μάλιστα μερικές φορές μου έλεγε ωμά ότι η διεπαφή δεν δούλευε, 100% δεν δούλευε, παρά το ότι πάντα δούλευε σε μένα. Όταν την έβλεπα να αναπαράγει το σφάλμα είχα μία από αυτές τις Α-χααα εμπειρίες. Alt! Κρατάς πατημένο το πλήκτρο Alt! Μα γιατί δεν το είχα δοκιμάσει αυτό;

2. Το δικό μου λογισμικό είναι στο web. Μπορώ να διορθώνω τα σφάλματα μέσα σε δευτερόλεπτα

Ουχα χα χα χα χα! Εντάξει, είναι αλήθεια ότι η ενημέρωση μέσω του web σας επιτρέπει να διανείμετε διορθώσεις σφαλμάτων πολύ γρηγορότερα σε σχέση με τον παλιό καιρό του πακετοποιημένου λογισμικού. Αλλά μην υποτιμάτε το κόστος διόρθωσης ενός σφάλματος, ακόμα και σε ένα δικτυακό τόπο, αφού η διαδικασία ανάπτυξης έχει ολοκληρωθεί. Κατ'αρχάς μπορεί να δημιουργήσετε περισσότερα σφάλματα καθώς διορθώνετε το αρχικό πρόβλημα. Αλλά ένα χειρότερο πρόβλημα προκύπτει αν κοιτάξετε τη διαδικασία που έχετε ορίσει για την δημοσιοποίηση νέων εκδόσεων. Ίσως συνειδητοποιήσετε ότι η διαδικασία έκδοσης διορθώσεων σφαλμάτων στο web μπορεί να είναι αρκετά ακριβή. Ξεχνάμε βέβαια την κακή εικόνα που θα δώσετε, το οποίο μας οδηγεί στο:

3. Το λογισμικό μας θα δοκιμαστεί από τους πελάτες μας.

Αααχ, η τρομερή "Άμυνα Netscape". Αυτή η κακόμοιρη εταιρία έκανε μια σχεδόν υπερφυσικού μεγέθους ζημιά στην φήμη της μέσω της διαδικασίας δοκιμών της:

  1. όταν οι προγραμματιστές είναι σχεδόν κατά το ήμισυ έτοιμοι, διάνειμε το λογισμικό στο διαδίκτυο χωρίς καθόλου δοκιμές.
  2. όταν οι προγραμματιστές λένε ότι είναι έτοιμοι, διάνειμε το λογισμικό στο διαδίκτυο χωρίς καθόλου δοκιμές.
  3. επανάλαβε έξι ή εφτά φορές.
  4. ονόμασε μία από αυτές τις εκδόσεις "τελική έκδοση".
  5. ανακοίνωσε εκδόσεις .01, .02, .03 κάθε φορά που εμφανίζεται στο c|net ένα σφάλμα που σε φέρνει σε δύσκολη θέση.

Η εταιρία αυτή πρωτοστάτησε στην ιδέα των "εκδόσεων beta ευρείας διανομής". Κυριολεκτικά εκατομμύρια άνθρωποι κατεβάζαν αυτές τις ημιτελείς, προβληματικές εκδόσεις. Τα πρώτα χρόνια, σχεδόν όλοι όσοι χρησιμοποιούσαν Netscape είχαν κάποια πρώιμη έκδοση ή έκδοση beta. Κατά συνέπεια οι περισσότεροι χρήστες είχαν σχηματίσει την εντύπωση ότι το λογισμικό της Netscape είναι πραγματικά προβληματικό. Ακόμα και αν η τελική έκδοση ήταν αρκετά ικανοποιητική, η Netscape είχε ταλαιπωρήσει τόσους πολλούς χρήστες με προβληματικές εκδόσεις που η μέση εντύπωση την οποία είχαν οι περισσότεροι χρήστες για το λογισμικό ήταν ότι αυτό ήταν κακής ποιότητας.

Φυσικά, η όλη ιδέα του να ζητάτε από "τους πελάτες" να κάνουν τις δοκιμές είναι το ότι περιμένετε αυτοί να βρίσκουν τα σφάλματα και εσείς να τα διορθώνετε. Δυστυχώς, ούτε η Netscape, ούτε καμία άλλη εταιρεία στον πλανήτη, διαθέτει την απαιτούμενη ανθρωποδύναμη για να χτενίσει αναφορές σφαλμάτων από 2.000.000 πελάτες και να αποφασίσει ποια είναι πραγματικά σοβαρά. Όταν προσπαθούσα να αναφέρω ένα σφάλμα στο Netscape 2.0 χρησιμοποιώντας τον σχετικό δικτυακό τόπο, αυτός δεν λειτουργούσε σωστά και απλά δεν μου επέτρεπε να καταχωρίσω το σφάλμα (το οποίο ούτως ή άλλως θα κατέληγε σε μια μαύρη τρύπα). Αλλά η Netscape δεν μαθαίνει. Οι δοκιμαστές της τρέχουσας "προκαταρκτικής" έκδοσης 6.0 παραπονιούνται στα newsgroups ότι ο δικτυακός τόπος για τις αναφορές προβλημάτων ακόμα δεν επιτρέπει καταχωρήσεις. Χρόνια μετά! Το ίδιο πρόβλημα!

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

Το χειρότερο πράγμα σχετικά με αυτό τον τρόπο δοκιμών είναι η ιδιαίτερα κακή εντύπωση την οποία θα κάνει η εταιρία σας. Όταν η Userland έβγαλε την πρώτη έκδοση σε Windows του κορυφαίου της προϊόντος Frontier, το κατέβασα και άρχισα να το δουλεύω μέσα από το εκπαιδευτικό παράδειγμα (tutorial). Δυστυχώς, το Frontier κράσαρε αρκετές φορές. Ακολουθούσα επακριβώς τις οδηγίες, όπως αυτές ήταν τυπωμένες στο εγχειρίδιο, και δεν μπορούσα να προχωρήσω για περισσότερο από 2 λεπτά. Ένιωσα ότι κανείς στην Userland δεν είχε κάνει ούτε τον ελάχιστο έλεγχο ώστε να βεβαιωθεί ότι το εκπαιδευτικό παράδειγμα λειτουργεί ομαλά. Η χαμηλή, όπως την αισθάνθηκα εγώ, ποιότητα του προϊόντος με έκανε να απομακρυνθώ από το Frontier για ένα πολύ μεγάλο χρονικό διάστημα.

4. Όποιος διαθέτει τα προσόντα ενός καλού τεχνικού δοκιμών δεν θέλει να κάνει αυτή τη δουλειά

Αυτό είναι οδυνηρό. Είναι πολύ δύσκολο να βρεις και να προσλάβεις καλούς τεχνικούς δοκιμών.

Με τους δοκιμαστές, όπως και με τους προγραμματιστές, οι καλύτεροι είναι μια τάξη μεγέθους πιο αποτελεσματικοί από τον μέσο όρο. Στην εταιρία Juno είχαμε μία τεχνικό δοκιμών, την Jill McFarlane, η οποία εντόπιζε τρεις φορές περισσότερα σφάλματα από τους υπόλοιπους τέσσερεις δοκιμαστές μαζί. Δεν υπερβάλλω, πραγματικά το μέτρησα αυτό. Ήταν περισσότερο από δώδεκα φορές πιο παραγωγική από τον μέσο δοκιμαστή. Όταν παραιτήθηκε έστειλα ένα email στον CEO της εταιρίας λέγοντάς του "Θα προτιμούσα να έχω την Jill κάθε Δευτέρα και Τρίτη, παρά όλη την υπόλοιπη ομάδα όλη την εβδομάδα".

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

Το μόνο πράγμα που μπορείτε να κάνετε για αυτό το πρόβλημα είναι να αναγνωρίσετε την ύπαρξή του και να βρείτε τρόπους να το αντιμετωπίσετε. Μερικές προτάσεις είναι οι παρακάτω:

  • Χρησιμοποιήστε τη θέση του τεχνικού δοκιμών σαν ένα βήμα καριέρας προς τα μπροστά για όσους εργάζονται στην τεχνική υποστήριξη. Όσο δύσκολες και κουραστικές και να είναι οι δοκιμές λογισμικού, σίγουρα είναι καλύτερα από το να αντιμετωπίζεις εκνευρισμένους χρήστες στο τηλέφωνο. Ταυτόχρονα αυτό μπορεί να είναι ένας τρόπος να μειώσετε και τις αποχωρήσεις όσων εργάζονται στο τμήμα τεχνικής υποστήριξης.
  • Επιτρέψτε στους τεχνικούς δοκιμών να εξελίξουν την καριέρα τους κάνοντας μαθήματα προγραμματισμού, και ενθαρρύνετε τους πιο ικανούς να φτιάξουν αυτοματοποιημένα πακέτα δοκιμών χρησιμοποιώντας προγραμματιστικά εργαλεία και γλώσσες script. Αυτό είναι πολύ πιο ενδιαφέρον από το να ελέγχεις τον ίδιο διάλογο ξανά και ξανά.
  • Αναγνωρίστε το γεγονός ότι θα έχετε υψηλό ρυθμό αποχωρήσεων μεταξύ των καλύτερών σας τεχνικών δοκιμών. Να προσλαμβάνετε επιθετικά διατηρώντας ένα σταθερό ρυθμό προσλήψεων. Μην σταματάτε να προσλαμβάνετε επειδή προσωρινά είστε πλήρεις, γιατί η χρυσή εποχή δεν θα κρατήσει για πολύ.
  • Ψάξτε για "μη παραδοσιακούς" υπαλλήλους: έξυπνους πιτσιρικάδες, φοιτητές και συνταξιούχους που να εργάζονται με μερική απασχόληση. Μπορείτε να δημιουργήσετε ένα εντυπωσιακά καλό τμήμα δοκιμών με δύο ή τρεις κορυφαίους τεχνικούς πλήρους απασχόλησης και μια στρατιά πιτσιρικάδες από το Bronx Science (ένα από τα καλύτερα λύκεια στη Νέα Υόρκη) οι οποίοι να δουλεύουν τα καλοκαίρια μαζεύοντας χρήματα για το κολέγιο.
  • Προσλάβετε προσωρινούς υπαλλήλους. Αν προσλάβετε 10 προσωρινούς υπαλλήλους για μερικές ημέρες, θα βρείτε έναν τρομακτικό αριθμό σφαλμάτων. Δύο-τρεις από αυτούς πιθανά να έχουν καλές ικανότητες ελέγχου λογισμικού, συνεπώς μπορείτε να τους προσλάβετε για πλήρη απασχόληση. Να ξέρετε εκ των πρωτέρων ότι μερικοί από τους προσωρινούς θα είναι εντελώς άχρηστοι σαν δοκιμαστές. Στείλτε τους σπίτι τους και συνεχίστε τη δουλειά σας.

Και αυτό είναι κάτι που να μην κάνετε:

  • Ούτε καν να σκεφθείτε να πείτε σε απόφοιτους κολεγίων Επιστήμης Υπολογιστών ότι μπορούν να δουλέψουν για σας, αλλά "όλοι πρέπει να περάσουν μια περίοδο στο τμήμα Διασφάλισης Ποιότητας πριν περάσουν στην ανάπτυξη κώδικα". Το έχω δει πολλές φορές αυτό. Οι προγραμματιστές δεν γίνονται καλοί τεχνικοί δοκιμών. Θα χάσετε έναν καλό προγραμματιστή, και αυτοί είναι πολύ πιο δύσκολο να αντικατασταθούν.

Και τελευταίος, ο πιο βλακώδης λόγος που οι εταιρίες δεν προσλαμβάνουν τεχνικούς δοκιμών:

5. Δεν βγαίνω οικονομικά να προσλάβω τεχνικούς δοκιμών!

Αυτή είναι η πιο βλακώδης δικαιολογία, και η ευκολότερη να καταρρίψεις.

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

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

Το άρθρο αυτό πρώτο-εμφανίστηκε στα Αγγλικά με το όνομα Top Five (Wrong) Reasons You Don't Have Testers

Personal tools