Μενού

Πώς να χειριστείτε τις κακές απαιτήσεις ως δοκιμαστής

how deal with bad requirements

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

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

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

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

κακές απαιτήσεις

Αυτό ήταν απλώς ένα παράδειγμα.

Σε μια καριέρα άνω των 10 ετών Έχω παρατηρήσει πολλές περιπτώσεις όπου τα έργα υπέστησαν λόγω κακών ή κακών απαιτήσεων.

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

ΑΣΕ με να εξηγήσω -

Τι θα μάθετε:

Πόσο κακές, κακές και συγκρουόμενες απαιτήσεις δημιουργούν προβλήματα:

# 1) Χωρίς απαιτήσεις - Καμία απαίτηση δεν συνεπάγεται υποθέσεις και εικασίες και επομένως δεν υπάρχει εμπιστοσύνη. Είναι πολύ δύσκολο να δοκιμάσετε ένα προϊόν / εφαρμογή χωρίς καμία βασική γραμμή. Και αυτά έχουν ως αποτέλεσμα περισσότερη δουλειά, περισσότερα σφάλματα από τον πελάτη και περισσότερα δεινά για το έργο.

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

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

# 2) Κακές απαιτήσεις - Το απόσπασμα, Το να γνωρίζεις κάτι ατελές είναι επικίνδυνο από το να μην το γνωρίζεις καθόλου , είναι πολύ αλήθεια όταν πρόκειται για μια κακή απαίτηση.

Η ερμηνεία μιας κακής απαίτησης και η εφαρμογή της είναι μεγάλος κίνδυνος.

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

# 3) Συγκρουόμενες απαιτήσεις - Το να ζητάς από κάποιον να κάνει δύο διαφορετικά πράγματα ταυτόχρονα απλά τον μπερδεύει και το σύστημα δεν αποτελεί εξαίρεση.

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

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

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

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

Ας δούμε τις πιθανές λύσεις:

Κακές απαιτήσεις και πώς να τις χειριστείτε ως ελεγκτής:

Μέθοδος # 1)Εξερευνήστε και μάθετε:

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

Τις περισσότερες φορές, είναι ένα καλό στοίχημα να δοθεί προτεραιότητα στην εμπειρία και την ευκολία του χρήστη όταν οι απαιτήσεις δεν είναι σαφείς.

Μέθοδος # 2)Χρησιμοποιήστε την εμπειρία:

Χρησιμοποιήστε την εμπειρία

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

Μέθοδος # 3)Ανατρέξτε σε wireframes:

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

Διαβάστε περισσότερα => Πλαίσια καλωδίων - Πρέπει πραγματικά να δοκιμαστούν; Και αν ναι, πώς;

Μέθοδος # 4)Συζήτηση από ομοτίμους:

πώς να δηλώσετε μια συνδεδεμένη λίστα στο java

Συζήτηση από ομοτίμους

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

Μέθοδος # 5)Διευκρίνιση από τον πελάτη:

Ο πελάτης είναι ο κάτοχος του προϊόντος / εφαρμογής και είναι πάντα συνετό να τον προσεγγίζουμε όταν πρόκειται για σαφήνεια των απαιτήσεων. Αλλά θυμηθείτε, δεν συνιστάται να επιτεθείτε στον πελάτη με 100 ερωτήσεις. Πριν το κάνετε, απαιτείται κάποια εργασία στο σπίτι.

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

συμπέρασμα

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

Σχετικά με τον Συγγραφέα: Αυτή η εμπνευσμένη δημοσίευση γράφτηκε από το μέλος της ομάδας STH Bhumika M. Είναι επικεφαλής του έργου, με 10+ χρόνια εμπειρίας δοκιμών λογισμικού.

Καλή δοκιμή, ως συνήθως… .. περιμένοντας τις απόψεις, τα σχόλια και τις απόψεις σας.

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

^