Μενού

Πώς να δοκιμάσετε μια εφαρμογή χωρίς απαιτήσεις;

how test an application without requirements

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

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

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

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

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

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

Επομένως, αυτό το άρθρο είναι μια προσπάθεια σε ορισμένες πρακτικές που ακολουθήσαμε όταν βρεθήκαμε σε αυτές τις καταστάσεις.

Διαβάστε επίσης:

τι είναι ένα αρχείο swf και πώς μπορώ να το ανοίξω

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

  1. Το ράφια του έργου ανοίγει ξανά
  2. Τεκμηρίωση λιγότερη μορφή εργασίας - Διαδικασία
  3. Η τεκμηρίωση μπορεί να υπάρχει - αλλά μπορεί να μην είναι λεπτομερής ή πλήρης
  4. Οι συνεχείς κυκλοφορίες και οι πληροφορίες σχετικά με την παλαιότερη έκδοση δεν έχουν αρχειοθετηθεί με αποτέλεσμα να υπάρχει κενό στην κατανόηση του τρόπου με τον οποίο αντιδρά η υπάρχουσα λειτουργικότητα με τη νέα

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

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

Μέθοδος # 1:

Εργαστείτε με ό, τι λίγη τεκμηρίωση μπορείτε να αποκτήσετε. Θα μπορούσε να είναι ένα βασικό απλό καθυστέρηση (σε ευκίνητα έργα), ένα αρχείο βοήθειας, ένα email, μια παλαιότερη έκδοση του BRD / FRD ή παλιές δοκιμαστικές περιπτώσεις (ελέγξτε για αυτά στα εργαλεία ALM και μπορεί να τα βρείτε) κ.λπ.

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

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

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

Μέθοδος # 2:

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

Σας βοηθά να διατηρήσετε τις ακόλουθες πτυχές σε προοπτική όταν το κάνετε:

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

Μέθοδος # 3:

Μιλήστε με τα μέλη της ομάδας του έργου:

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

Τώρα, ας εφαρμόσουμε τις μεθόδους σε ένα παράδειγμα:

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

Εφαρμογή μεθόδου # 1:

Βρείτε οποιαδήποτε τεκμηρίωση μπορείτε. Ρωτήστε την ομάδα προγραμματιστών σας εάν έχουν οθόνες mock-up / εμφάνιση στο εργαλείο ALM ή οτιδήποτε άλλο. Εάν βρείτε κάτι, αυτό θα ήταν ένα καλό σημείο εκκίνησης. Αλλά εάν αυτή η μέθοδος δεν εμφανιστεί τίποτα, τότε μπορείτε να χρησιμοποιήσετε το κρίση / διαίσθηση του ελεγκτή.

Όλοι γνωρίζουμε πώς λειτουργούν τα καλάθια αγορών, οπότε κάντε τις υποθέσεις σας και φτάνουμε σε μερικά βασικά σενάρια όπως:

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

Μπορούμε να συνεχίσουμε, αλλά είμαι βέβαιος ότι έχετε την εικόνα.

Εφαρμογή μεθόδου # 2:

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

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

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

Τώρα, σε αυτό το σημείο οι υπεύθυνοι δοκιμών έχουν κάποιες ερωτήσεις όπως:

  1. Τι συμβαίνει όταν δίνω char στο κουτί ποσού;
  2. Πότε προσθέτω πάρα πολλά στοιχεία;
  3. Ποιο είναι το μέγιστο όχι. αντικειμένων που μπορεί να πάρει; Και τα λοιπά.

Εφαρμογή μεθόδου # 3 :

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

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

Συμπερασματικά, Όλα δεν χάνονται όταν δεν υπάρχει τεκμηρίωση ή είναι ανεπαρκής. Υπάρχει ακόμα ελπίδα! Μοιραστείτε τις εμπειρίες σας σε παρόμοιες καταστάσεις.

Σχετικά με τον Συγγραφέα: Αυτή η χρήσιμη δημοσίευση γράφτηκε από το μέλος της ομάδας STH Swati S.

Όπως πάντα τα σχόλια, οι ερωτήσεις και οι προτάσεις σας είναι ευπρόσδεκτα.

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

^