what do clients really expect from software testers
Στο σημερινό άρθρο, θα μοιραστώ μερικές σκέψεις σχετικά με το τι πιστεύω ότι οι πελάτες περιμένουν πραγματικά από εμάς με βάση την εμπειρία μου από πρώτο χέρι που εργάζομαι σε τοποθεσίες πελατών με καθημερινές προσωπικές αλληλεπιδράσεις και συνεργασία υπεράκτιων μέσω email ή τηλεφωνικών κλήσεων.
Οι υπηρεσίες πληροφορικής αποτελούν σημαντικό και αναπόσπαστο μέρος της βιομηχανίας λογισμικού και η ικανοποίηση των πελατών είναι σημαντική για την επιτυχία. Κάθε πελάτης / οργανισμός μπορεί να είναι διαφορετικός στη διαδικασία του μπορεί να ακολουθεί διαφορετικό πρωτόκολλο και μπορεί να ασχολείται με διαφορετικό τύπο επιχειρήσεων.
Όμως, οι ακόλουθοι παράγοντες είναι κοινοί και έχουν σημασία για όλους γενικά.
(εικόνα src )
Τι θα μάθετε:
- 5 πράγματα που ο πελάτης αναμένει από τους ελεγκτές λογισμικού:
- # 1) Όφελος κόστους
- # 2) Ποιότητα εργασίας
- # 3) Κατανόηση επιχειρήσεων
- # 4) Διαθεσιμότητα
- # 5) Πεδίο βελτίωσης
- συμπέρασμα
- Συνιστώμενη ανάγνωση
5 πράγματα που ο πελάτης αναμένει από τους ελεγκτές λογισμικού:
# 1) Όφελος κόστους
Όταν σκέφτεστε να πουλήσετε ή να αγοράσετε κάτι, το κόστος διαδραματίζει σημαντικό ρόλο και είναι συχνά ένας από τους σημαντικούς καθοριστικούς παράγοντες. Δεν περιμένουμε όλοι ανυπόμονα την Black Friday, την πώληση Flipkart Billion Day ή το υπέροχο φεστιβάλ αγορών της Amazon; Γινόμαστε τρελοί αγοραστές κατά τη διάρκεια της πώλησης. Είναι μια απλή ανθρώπινη συμπεριφορά να περιμένουμε τη σωστή ή επιπλέον αξία για τα χρήματά μας.
Οι εταιρείες και οι πελάτες δεν διαφέρουν. Τα οφέλη κόστους ενισχύουν τις σχέσεις εξυπηρέτησης πελατών και δεν είναι ασυνήθιστο οι εταιρείες παροχής υπηρεσιών να χάνουν προσφορές λόγω χαμηλότερων ανταγωνιστών.
Η ΜΕΓΑΛΗ ερώτηση τώρα είναι: Πώς μπορούμε να δείξουμε οφέλη κόστους στους πελάτες μας;
Αυτά τα σημεία μπορούν να βοηθήσουν:
- Δείξτε τους την αξία των χρημάτων τους . Δικαιολογήστε και παρέχετε αποδεικτικά στοιχεία για το δικό σας υπολογίζει .
- Σκεφτείτε δημιουργικούς τρόπους εξοικονόμησης δαπανών.
- Προσαρμόστε την προσφορά σας. Αντί να ακολουθείτε την τυπική διαδικασία που κοστίζει Χ χρηματικό ποσό, παρέχετε φθηνότερες εναλλακτικές λύσεις. Για παράδειγμα : Προτείνετε κρίσιμες δοκιμές διαδρομής αντί για πλήρη δοκιμή συστήματος.
- Γνωρίστε τον ανταγωνισμό σας . Ένας γρήγορος έλεγχος πραγματικότητας για το τι άλλες εταιρείες παροχής υπηρεσιών προσφέρουν στους πελάτες τους με ποιο κόστος είναι σημαντικό για να διατηρηθεί η αγορά μοντέλου τιμολόγησης σχετική.
# 2) Ποιότητα εργασίας
Η ποιότητα και η ποσότητα εργασίας είναι δύο πολύ διαφορετικά πράγματα.
Πηγαίνουν οι μέρες που ο αριθμός των δοκιμαστικών περιπτώσεων που δημιουργήθηκαν ή τα ελαττώματα που αναφέρθηκαν χρησιμοποιούνται για δείκτες παραγωγικότητας ή ποιότητας. Οχι πια.
Η κατάσταση μοιάζει περισσότερο με την παρακάτω εικόνα:
Α) Μάθετε πότε να πείτε 'ΟΧΙ'
Όλοι βρισκόμασταν σε μέρη όπου εργαζόμασταν υπερωρίες, τηλεφωνήσαμε τα σαββατοκύριακα, παρακολουθήσαμε κλήσεις αργά το βράδυ ή νωρίς το πρωί κ.λπ. Ωστόσο, αυτό που δεν συνειδητοποιούμε είναι ότι μπορούμε να πούμε ΟΧΙ αν τα πράγματα συνεχίσουν να χειροτερεύουν. Λέγοντας ΟΧΙ είναι ο μόνος τρόπος για να διατηρήσουμε ανέπαφη την ποιότητα της εργασίας και τη λογική μας.
Όταν το κάνετε αυτό, εκφράστε την ανησυχία σας εκ των προτέρων και υποστηρίξτε την ποιότητα.
Εδώ είναι μια κατάσταση στην οποία ήμουν και αυτό μπορεί να σας δώσει μια καλύτερη ιδέα για το τι μιλάω:
Η εταιρεία μου κέρδισε ένα νέο λογότυπο και ως μέρος της μετάβασης από μια παλιά εταιρεία στην εταιρεία μου, προγραμματίστηκαν συνεδρίες μεταφοράς γνώσης. Εμείς, μια ομάδα 6 μελών ταξιδέψαμε στον ιστότοπο πελατών. Την πρώτη μέρα μετά την εισαγωγή, μοιραστήκαμε το σχέδιο KT. Βρήκα ότι το όνομά μου έχει επισημανθεί με πολλές ενότητες. Μία από αυτές τις ενότητες θα έπρεπε να ήταν εντελώς εκτός εμβέλειας, επειδή δεν γνώριζα καν αυτήν την τεχνολογία. δεν ταιριάζει με τις ικανότητές μου.
Πήγα στο προβάδισμα μετάβασης της Γνώσης και του είπα την κατάσταση -
- Έχω ανατεθεί πάρα πολλά στοιχεία εργασίας, τα οποία με τη σειρά τους θα εμποδίσουν την ποιότητα και την ικανότητά μου να συλλάβω 100% στις συνεδρίες.
- Τα προγραμματισμένα αντικείμενα είχαν τομείς όπου οι δεξιότητές μου δεν θα ταιριάζουν και επειδή δεν ήμουν η σωστή εφαρμογή, ίσως να μην καταλαβαίνω το 100% κατά τη διάρκεια της μετάβασης.
Το προβάδισμα κατάλαβε το πρόβλημα και αναθεώρησε το σχέδιο KT.
εφαρμογές της java στον πραγματικό κόσμο
Ελπίζω να σας βοηθήσει να επιβεβαιώσετε ότι: Εάν υπάρχει κάτι στο πιάτο μας, αυτό δεν σημαίνει ότι πρέπει να τα φάμε όλα. Ειδικά όχι εάν σημαίνει συμβιβασμό στην ποιότητα.
Β) Ολοκλήρωση δοκιμαστικής θήκης
Πόσοι από εσάς συμφωνείτε μαζί μου ότι αν προσπαθήσουμε βελτιώστε τον τρόπο σύνταξης δοκιμαστικών περιπτώσεων , οδηγεί σε καλύτερη ποιότητα;
Ακολουθούν ορισμένα κοινά λάθη που είναι κοινά στις περισσότερες περιπτώσεις δοκιμής:
Εξαρτήματα θήκης δοκιμής | Τρέχον πρόβλημα | Λύση |
---|---|---|
Σκοπός | Ο στόχος είναι το πιο σημαντικό μέρος κάθε δοκιμαστικής περίπτωσης, αυτό είναι που κάνει όλες τις περιπτώσεις δοκιμών διαφορετικές. Λείπουν σαφήνεια σε κοινά λάθη με το Objective. Όπως όλες οι δοκιμαστικές περιπτώσεις που έχουν δημιουργηθεί για μία λειτουργικότητα, έχουν έναν στόχο χωρίς να δείχνουν πώς διαφέρει κάθε υπόθεση δοκιμής. | Ο στόχος / σκοπός κάθε δοκιμαστικής θήκης πρέπει να είναι σαφής για να εξηγήσει ποια λειτουργικότητα και ποια κατάσταση δοκιμής πρόκειται να δοκιμαστεί ως μέρος αυτής της υπόθεσης δοκιμής. Η ίδια λειτουργικότητα μπορεί να έχει θετικές και αρνητικές περιπτώσεις δοκιμής, οπότε ο στόχος πρέπει να είναι αρκετά σαφής για να δείξει τη διαφορά. Μια καλή ιδέα είναι να παραπέμψετε το σενάριο δοκιμής για τον καθορισμό του αντικειμενικού σκοπού. |
Προϋποθέσεις | Πολλοί δοκιμαστές χάνουν εντελώς την προϋπόθεση ή πολλοί απλώς θα αντιγράψουν και θα επικολλήσουν. Η αντιγραφή επικόλλησης οδηγεί σε σφάλματα, καθώς κάθε δοκιμαστική θήκη ενδέχεται να διαφέρει εντελώς από την άλλη. | Αποφύγετε σφάλματα Copy-Paste και δώστε προσοχή στη λεπτομέρεια. |
Δεδομένα δοκιμής | Αυτό είναι πιθανώς το πιο αγνοημένο πεδίο και οι περισσότερες δοκιμαστικές περιπτώσεις θα το έχουν κενό ή δεν έχουν ακριβή ορισμό | Αναφέρετε τα κατάλληλα δεδομένα που θα εισαχθούν. Μερικές φορές, δεν χρειάζεται να είναι ακριβές. Για παράδειγμα: Η εγγραφή χρήστη μπορεί να εγγράψει έναν χρήστη Anna ή John και αυτό δεν θα είχε σημασία. Αλλά ο ορισμός ότι ένα έγκυρο όνομα που έχει όλους τους χαρακτήρες και πρέπει να έχει μήκος 4-10 μπορεί να σας βοηθήσει να διευκρινίσετε πολλά πράγματα. |
Αναγνωριστικό περίπτωσης δοκιμής | Πάνω από απλοποιημένη σύμβαση ονομασίας ή αρίθμησης. Ας πούμε, δοκιμάζετε ένα κουμπί σύνδεσης. Συχνά, τα αναγνωριστικά είναι: TC_1_Σύνδεση TC_2_Σύνδεση | Κάντε τα πιο περιγραφικά: TC_1_Login_Invalid_User TC_2_Login_Valid_User |
Έγγραφα αναφοράς | Ασυνεπής αντιγραφή-επικόλληση από έγγραφα αναφοράς ή χειρότερα, χρησιμοποιώντας εσφαλμένη | Συνιστάται πάντοτε να αναφέρετε το σωστό έγγραφο αναφοράς με τον σωστό αριθμό έκδοσης, ας πούμε για ορισμένες δοκιμαστικές περιπτώσεις FRS και Tech Specs και τα δύο θα έχουν παραπεμφθεί, έτσι η δοκιμαστική περίπτωση στην ενότητα αναφοράς θα πρέπει να αναφέρει και τα δύο. |
Βήματα υπόθεσης | Λείπουν βήματα, κυρίως από υπεύθυνους δοκιμών που γνωρίζουν πολύ καλά την εφαρμογή. Θα μπορούσαν να υποθέσουν τα πράγματα και να παραλείψουν να αναφέρουν τα βήματα. Αυτό προκαλεί προβλήματα στην επιχείρηση, τους αναθεωρητές και τους νέους υπεύθυνους δοκιμών. | Πρέπει να χρησιμοποιούνται σωστά βήματα και ακολουθίες. |
Συνοψίζοντας, αν ληφθούν υπόψη μικρές λεπτομέρειες στη φάση σχεδιασμού, η ποιότητα της δοκιμαστικής εξόδου θα είναι πολύ ανώτερη.
# 3) Κατανόηση επιχειρήσεων
Αυτός είναι ένας από τους πιο σημαντικούς παράγοντες που αναζητούν οι πελάτες στους υπεύθυνους δοκιμών. Ωστόσο, είναι λυπηρό το γεγονός ότι ορισμένοι δοκιμαστές πιστεύουν ότι η δουλειά τους είναι να γράφουν δοκιμαστικές υποθέσεις με βάση το FRS και να μην καταβάλλουν προσπάθειες για να κατανοήσουν την επιχείρηση.
Προσπαθήστε να γνωρίζετε πρώτα την επιχείρηση και, στη συνέχεια, να εξετάσετε τη λειτουργικότητα. μπορείς οραματιστείτε τις ανάγκες του πελάτη σας περισσότερα και δοκιμάστε ανάλογα.
Εδώ είναι ένα παράδειγμα- Το FRS δηλώνει ότι «η αναφορά XYZ θα πρέπει να δημιουργηθεί με 3 στήλες ως Ημερομηνία, Όνομα και Κατάσταση». Ακολουθούν οι δοκιμαστικές περιπτώσεις στις οποίες θα καταλήξετε όταν λαμβάνετε αυτήν την απαίτηση στην ονομαστική της τιμή:
- Δημιουργείται επικύρωση αναφοράς XYZ
- Η αναφορά επικύρωσης έχει 3 στήλες ως ημερομηνία, όνομα, κατάσταση
- Επικυρώστε τα δεδομένα σε 3 στήλες.
Ωστόσο, όταν έχετε υπόψη σας την επιχειρηματική δυνατότητα εφαρμογής αυτής της αναφοράς, ίσως χρειαστεί να δοκιμάσετε:
- Ποιος είναι ο επιχειρησιακός σκοπός αυτής της αναφοράς;
- Δημιουργείται αυτή η αναφορά κάθε μέρα;
- Ποιοι είναι οι χρήστες των επιχειρήσεων που βλέπουν αυτήν την αναφορά;
- Ποια είναι η πηγή δεδομένων για αυτήν την αναφορά;
- Πρέπει να δημιουργηθεί η αναφορά εάν δεν υπάρχουν διαθέσιμα δεδομένα;
Αυτό είναι ένα μόνο παράδειγμα, αλλά υποθέτω ότι όλοι συμφωνούμε ότι μπορούν να επιτευχθούν καλύτερες δοκιμές με την απόκτηση επιχειρηματικής συνείδησης και εμπειρογνωμοσύνης.
# 4) Διαθεσιμότητα
Είτε είστε ένα άτομο που υποστηρίζει τον πελάτη είτε μια ομάδα, η διαθεσιμότητά σας θα πρέπει πάντα να ελέγχεται ( ).
Από διαθεσιμότητα, δεν σημαίνει υποστήριξη 24/7. Σημαίνει απλώς μια σαφή και εκ των προτέρων επικοινωνία σχετικά με τη διακοπή χρόνου, τα εναλλακτικά σχέδια και το ότι είναι προσβάσιμο και δεν πηγαίνει MIA.
Παρακάτω είναι μερικά από τα μοντέλα που ακολουθεί ο κλάδος των υπηρεσιών:
- Μοντέλο αύξησης προσωπικού - Εάν εργάζεστε σε μοντέλο αύξησης προσωπικού και είστε ο μοναδικός εκπρόσωπος της εταιρείας σας, συνιστάται ο πελάτης να ενημερωθεί για τους χρόνους εργασίας και τις προγραμματισμένες απουσίες σας, ώστε να γίνουν οι απαραίτητες ρυθμίσεις.
- Μοντέλο διαχειριζόμενων έργων - Σε ένα μοντέλο διαχειριζόμενου έργου στο οποίο σχηματίζονται μεγάλες ομάδες έργου και διευθύνονται από διαχειριστές παράδοσης / έργου, η ύπαρξη εφεδρικού σχεδίου πόρων δεν παραμένει πλέον ευθύνη των πελατών. Η ανάγκη του PM για διαχείριση τόσο προγραμματισμένη όσο και μη προγραμματισμένη άδεια. Σε αυτό το μοντέλο, συνιστάται ο πρωθυπουργός να προσπαθήσει να συλλέξει τα προγραμματισμένα δεδομένα απουσίας από την ομάδα του εκ των προτέρων και να τα διαχειριστεί αναλόγως. Υπάρχουν περιπτώσεις όπου οι πελάτες ζητούν υποστήριξη για σαββατοκύριακο ή παρατεταμένες ώρες εργασίας. Τέτοιες περιπτώσεις πρέπει επίσης να προγραμματίζονται με εναλλασσόμενους πόρους. Μια ομάδα πρέπει να αποτελείται από μέλη που μπορούν να δημιουργούν αντίγραφα ασφαλείας, εάν απαιτείται. Οι προγραμματισμένες λεπτομέρειες πρέπει να κοινοποιούνται στον πελάτη.
# 5) Πεδίο βελτίωσης
Αυτό δεν είναι μόνο επιθυμητό στη βιομηχανία λογισμικού αλλά παντού. Η βελτίωση δεν είναι δουλειά μιας ημέρας. Το πεδίο βελτίωσης πρέπει να εξετάζεται συνεχώς και μπορεί να χωριστεί σε 3 βήματα -
Διαβάστε επίσης=> Πώς να βελτιώσετε τις δοκιμαστικές σας ικανότητες και να κερδίσετε τον ανταγωνισμό
Βήμα 1: Αναγνώριση
Κάντε μια διεξοδική μελέτη και προσδιορίστε τους τομείς / περιθώρια βελτίωσης. Ας πούμε, όταν σας ζητείται να δοκιμάσετε την ίδια λειτουργικότητα πολλές φορές χρησιμοποιώντας την ίδια διαδικασία, θα έρθει μια στιγμή που θα αισθανθείτε ότι είτε θέλετε να απομακρυνθείτε από το έργο είτε να αλλάξετε τον τρόπο δοκιμής του. Έτσι επιτυγχάνονται βελτιώσεις όταν βαρεθήκαμε τις υπάρχουσες μεθόδους μας, σκεφτόμαστε αλλαγή και βελτίωση .
Βήμα 2: Φέρτε βελτιώσεις
Εάν τα πράγματα γίνονταν με το χέρι θα μπορούσατε προσπαθήστε να αυτοματοποιήσετε λίγα πράγματα . Όταν λέω αυτοματοποίηση, δεν σημαίνει πάντα να αγοράζετε ένα αυτοματοποιημένο εργαλείο.
Θα παραθέσω μια κατάσταση:
Ήμουν μέλος μιας ομάδας δοκιμών βάσεων δεδομένων. Η καθημερινή μας εργασία περιελάμβανε την εκτέλεση των ίδιων σεναρίων SQL πολλές φορές την ημέρα με ένα διαφορετικό σύνολο παραμέτρων. Όταν ξεκινήσαμε το έργο ήμασταν καλά με αυτά τα βήματα, αλλά τελικά καταλάβαμε το σύστημα καλύτερα και πιστεύαμε ότι τα ίδια σενάρια SQL μπορούν να εκτελεστούν ως μέρος των αποθηκευμένων διαδικασιών αντί για κάποιον που ενημερώνει χειροκίνητα τις παραμέτρους και εκτελεί.
ποιο είναι το κλειδί ασφαλείας δικτύου σε έναν δρομολογητή
Βήμα # 3: Αξιολογήστε τη βελτίωση
Κάθε φορά που εφαρμόζεται μια νέα διαδικασία θα πρέπει να βεβαιωθείτε ότι λειτουργεί όπως αναμένεται και δεν έχει παρενέργειες. Επεκτείνοντας το προηγούμενο παράδειγμα, μια εισαγωγή αποθηκευμένων διαδικασιών, ελέγξτε αν η έξοδος από τον αυτοματοποιημένο τρόπο που δημιουργήθηκε πρόσφατα και η έξοδος από χειροκίνητο τρόπο είναι ίδια.
Το άλλο μέρος είναι να παρακολουθείτε τα οφέλη για μια χρονική περίοδο για να είστε απολύτως σίγουροι και να παρουσιάζετε τα αποτελέσματα στους πελάτες σας. Στο έργο μας, δείξαμε στους πελάτες μείωση του χρόνου εκτέλεσης δοκιμής κατά 30%, γεγονός που με τη σειρά του μείωσε το κόστος.
συμπέρασμα
Συμπερασματικά, ήθελα απλώς να αναφέρω ότι ο καθένας από εμάς έχει έμφυτα ταλέντα και όλοι έχουμε το δικό μας μοναδικό στυλ εργασίας και αυτές ήταν μερικές συμβουλές που πιστεύω ότι μπορούν να προσφέρουν στους πελάτες μας μια καλύτερη εμπειρία εξυπηρέτησης.
Σχετικά με τον Συγγραφέα: Αυτό το καταπληκτικό άρθρο γράφτηκε από το μέλος της ομάδας STH Priya R. Αν θέλετε να γράψετε για εμάς και να μοιραστείτε την εμπειρία σας παρακαλώ ενημερώστε μας εδώ .
Ελπίζω να σας άρεσε να διαβάζετε αυτό το άρθρο και το βρήκατε ενημερωτικό! Ενημερώστε μας εάν έχετε διαφορετική εμπειρία για κοινή χρήση.
Συνιστώμενη ανάγνωση
- Τα καλύτερα εργαλεία δοκιμής λογισμικού 2021 (QA Test Automation Tools)
- Η παγκόσμια επιχείρηση δοκιμών λογισμικού θα προσεγγίσει σύντομα 28,8 δισεκατομμύρια δολάρια
- Συμβουλές δοκιμής λογισμικού για αρχάριους δοκιμαστές
- Δοκιμή λογισμικού QA Assistant Job
- Πώς να διατηρήσετε το Motivation Alive σε δοκιμαστές λογισμικού;
- Ο Ζεν και η τέχνη της δοκιμής λογισμικού
- Μάθημα δοκιμών λογισμικού: Σε ποιο Ινστιτούτο Δοκιμών Λογισμικού πρέπει να εγγραφώ;
- Επιλέγοντας Δοκιμή λογισμικού ως καριέρα σας