Μενού

Πώς να αναθεωρήσετε το έγγραφο SRS και να δημιουργήσετε σενάρια δοκιμής - Εκπαίδευση δοκιμών λογισμικού σε ζωντανό έργο - Ημέρα 2

how review srs document

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

Αυτό είναι το δεύτερο σεμινάριο στο δικό μας «Δωρεάν διαδικτυακή εκπαίδευση δοκιμών λογισμικού σε ζωντανό έργο» σειρά. Εάν είστε νέοι εδώ, ελέγξτε τον πρώτο οδηγό εισαγωγής: Εκπαίδευση δοκιμών λογισμικού End to End σε ζωντανό έργο.

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

Πώς να ελέγξετε το έγγραφο SRS και να δημιουργήσετε δοκιμαστικά σενάρια_

Φάση σχεδιασμού SDLC:

Η επόμενη φάση του SDLC είναι 'Σχεδιασμός' - εδώ είναι οι λειτουργικές απαιτήσεις που μεταφράζονται στις τεχνικές λεπτομέρειες. Οι ομάδες προγραμματιστών, σχεδιασμού, περιβάλλοντος και δεδομένων συμμετέχουν σε αυτό το βήμα. Το αποτέλεσμα αυτού του βήματος είναι συνήθως ένα έγγραφο τεχνικού σχεδιασμού - TDD.

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

Τι θα μάθετε:

Τι είναι μια κριτική SRS;

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

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

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

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

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

Αναθεώρηση προδιαγραφών προ-βημάτων για απαιτήσεις λογισμικού

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

Βήμα 2) Καθορίστε οδηγίες για το τι αναμένεται στο τέλος της κριτικής από κάθε μέλος της ομάδας. Με άλλα λόγια, αποφασίστε ποια παραδοτέα αναμένονται από αυτό το βήμα - συνήθως, η έξοδος αυτού του βήματος είναι να προσδιορίσετε τα σενάρια δοκιμής. Τα σενάρια δοκιμής δεν είναι παρά ένας δείκτες γραμμής «τι να δοκιμάσετε» για συγκεκριμένη λειτουργικότητα.

Βήμα # 3) Επίσης, καθορίστε οδηγίες για τον τρόπο παρουσίασης αυτού του παραδοτέου - εννοώ, το πρότυπο.

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

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

Βήμα # 5) Το SRS review βοηθά επίσης στην καλύτερη κατανόηση εάν υπάρχουν συγκεκριμένες προϋποθέσεις που απαιτούνται για τη δοκιμή του λογισμικού.

Βήμα # 6) Ως υποπροϊόν, μια λίστα ερωτημάτων όπου κάποια λειτουργικότητα είναι δύσκολο να κατανοηθεί ή εάν πρέπει να ενσωματωθούν περισσότερες πληροφορίες σε λειτουργικές απαιτήσεις ή εάν εντοπιστούν λάθη στο SRS.

Τι χρειαζόμαστε για να ξεκινήσουμε;

  • Η σωστή έκδοση του εγγράφου SRS
  • Σαφείς οδηγίες για το ποιος θα εργαστεί για το τι και πόσο χρόνο έχουν.
  • Ένα πρότυπο για τη δημιουργία σεναρίων δοκιμής.
  • Άλλες πληροφορίες σχετικά με το ποιος πρέπει να επικοινωνήσετε σε περίπτωση ερώτησης ή σε ποιον πρέπει να υποβάλλετε αναφορά σε περίπτωση ασυνέπειας τεκμηρίωσης

Ποιος θα παρείχε αυτές τις πληροφορίες;

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

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

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

Απαιτείται πρότυπο για σενάρια δοκιμής;

Γιατί ένα πρότυπο για σενάρια δοκιμής - δεν αρκεί αν κάνουμε μια λίστα;

Είναι σίγουρα. Ωστόσο, τα προγράμματα λογισμικού δεν είναι 'one-man'. Περιλαμβάνουν ΟΜΑΔΙΚΗ ΔΟΥΛΕΙΑ .

Φανταστείτε μια ομάδα 4- εάν ο καθένας αποφασίσει να αναθεωρήσει μια ενότητα των προδιαγραφών του λογισμικού. Το μέλος της ομάδας Α έχει δημιουργήσει μια λίστα σε ένα φύλλο χαρτιού. Το μέλος της ομάδας 2 χρησιμοποίησε ένα φύλλο excel. Το μέλος της ομάδας 3 χρησιμοποίησε ένα σημειωματάριο. Το μέλος της ομάδας 4 χρησιμοποίησε μια λέξη doc. Πώς ενοποιούμε όλη τη δουλειά που έγινε για το έργο στο τέλος της ημέρας;

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

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

ερωτήσεις και απαντήσεις συνέντευξης .net framework

Πώς να δημιουργήσετε ένα πρότυπο για σενάρια δοκιμής QA;

Πρότυπα δεν πρέπει να είναι περίπλοκο ή άκαμπτο.

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

java vs c ++ διαφορές

πρότυπο σεναρίων δοκιμής

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

Ο παρακάτω πίνακας θα μας επιτρέψει να δημιουργήσουμε δοκιμαστικά σενάρια. Οι στήλες που περιλαμβάνονται είναι:

Στήλη # 1) Αναγνωριστικό σεναρίου δοκιμής
Κάθε οντότητα στη διαδικασία δοκιμών μας πρέπει να είναι μοναδικά αναγνωρίσιμη. Έτσι, σε κάθε δοκιμαστικό σενάριο πρέπει να εκχωρηθεί ένα αναγνωριστικό. Πρέπει να καθοριστούν οι κανόνες που πρέπει να ακολουθούν κατά την εκχώρηση αυτού του αναγνωριστικού.

Για χάρη αυτού του άρθρου θα ακολουθήσουμε τη σύμβαση ονομασίας ως TS (πρόθεμα που σημαίνει δοκιμαστικό σενάριο) ακολουθούμενο από το «_», το όνομα της ενότητας ΜΟΥ (Η ενότητα 'Οι πληροφορίες μου' του έργου Orange HRM) ακολουθείται από το '_' και στη συνέχεια το υποτμήμα ( Για παράδειγμα, ΜΟΥ για τη μονάδα πληροφοριών μου, Π για φωτογραφία και ούτω καθεξής) ακολουθούμενο από σειριακό αριθμό. Ένα παράδειγμα θα ήταν: 'TS_MI_MIM_01'.

Στήλη # 2) Απαίτηση
Βοηθά ότι όταν δημιουργούμε ένα δοκιμαστικό σενάριο θα πρέπει να μπορούμε να το αντιστοιχίσουμε πίσω στην ενότητα του εγγράφου SRS από το οποίο το επιλέξαμε. Εάν οι απαιτήσεις έχουν αναγνωριστικά, θα μπορούσαμε να το χρησιμοποιήσουμε. Εάν όχι, οι αριθμοί ενότητας ή ακόμη και οι αριθμοί σελίδων του εγγράφου SRS από το σημείο που εντοπίσαμε θα ισχύουν δοκιμαστικές απαιτήσεις.

Στήλη # 3) Περιγραφή σεναρίου δοκιμής
Μία επένδυση που καθορίζει «τι να δοκιμάσει». Θα το αναφέραμε επίσης ως στόχο δοκιμής.

Στήλη # 4) Σημασία
Αυτό είναι για να δώσει μια ιδέα για το πόσο σημαντική είναι μια συγκεκριμένη λειτουργικότητα για το AUT. Τιμές όπως υψηλή, μεσαία και χαμηλή μπορούν να αντιστοιχιστούν σε αυτό το πεδίο. Θα μπορούσατε επίσης να επιλέξετε ένα σύστημα σημείων, όπως το 1-5, το 5 να είναι το πιο σημαντικό, το 1 να είναι λιγότερο σημαντικό. Όποια και αν είναι η αξία που μπορεί να πάρει αυτό το πεδίο, πρέπει να αποφασιστεί εκ των προτέρων.

Στήλη # 5) Αριθμός δοκιμαστικών περιπτώσεων
Μια πρόχειρη εκτίμηση για πόσες μεμονωμένες περιπτώσεις δοκιμών μπορεί να καταλήξουμε να γράψουμε αυτό το σενάριο δοκιμής. Για παράδειγμα, Για να ελέγξετε τη σύνδεση - συμπεριλαμβάνουμε αυτές τις καταστάσεις: Σωστό όνομα χρήστη και κωδικό πρόσβασης. Σωστό όνομα χρήστη και λάθος κωδικό πρόσβασης. Σωστός κωδικός πρόσβασης και λάθος όνομα χρήστη. Έτσι, η επικύρωση της λειτουργικότητας σύνδεσης θα έχει ως αποτέλεσμα 3 δοκιμαστικές περιπτώσεις.

Σημείωση: Μπορείτε να επεκτείνετε αυτό το πρότυπο ή να καταργήσετε τα πεδία όπως κρίνετε κατάλληλο.

Για παράδειγμα , μπορείτε να προσθέσετε 'Κριτική από' στην κεφαλίδα ή να καταργήσετε την ημερομηνία δημιουργίας κ.λπ. Επίσης, στον πίνακα, μπορείτε να συμπεριλάβετε ένα πεδίο 'Δημιουργήθηκε από' για να ορίσετε τον υπεύθυνο δοκιμών για ένα συγκεκριμένο σενάριο δοκιμής ή να καταργήσετε το 'Όχι. στηλών δοκιμών ». Η επιλογή είναι δική σου. Πηγαίνετε με αυτό που λειτουργεί καλύτερα για ολόκληρη την ομάδα.

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

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

Τμήμα 1 είναι ο σκοπός του εγγράφου. Δεν υπάρχουν δοκιμαστικές απαιτήσεις εκεί.

Τμήμα 2.1 : Επισκόπηση Έργου- Κοινό- δεν υπάρχουν και δοκιμαστικές απαιτήσεις.

Τμήμα 2.2 : Hardware and Hosting- Αυτή η ενότητα μιλά για το πώς θα φιλοξενείται ο ιστότοπος Orange HRM. Τώρα, είναι σημαντικές αυτές οι πληροφορίες για εμάς τους δοκιμαστές; Η απάντηση είναι Ναι και Όχι Ναι, γιατί όταν δοκιμάζουμε πρέπει να έχουμε ένα περιβάλλον παρόμοιο με το περιβάλλον σε πραγματικό χρόνο.

Αυτό μας δίνει μια ιδέα για το πώς πρέπει να είναι. Όχι, γιατί δεν είναι μια δοκιμαστική απαίτηση - ένα είδος προαπαιτούμενου για να πραγματοποιηθεί η δοκιμή.

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

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

Τμήμα 4: Απαιτήσεις και οδηγίες αισθητικής / HTML - Αυτή η ενότητα εξηγεί καλύτερα πώς ορισμένες απαιτήσεις ενδέχεται να μην έχουν νόημα για την ομάδα δοκιμής κατά τη στιγμή της αξιολόγησης SRS, αλλά η ομάδα θα πρέπει να τις σημειώσει ως δοκιμαστικές απαιτήσεις.

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

Δείγμα σεναρίων δοκιμής για εφαρμογή OrangeHRM: (κάντε κλικ για μεγέθυνση)

πρότυπο σεναρίων δοκιμής

=> Ανατρέξτε και κάντε λήψη του εγγράφου σεναρίων δοκιμής Για περισσότερες πληροφορίες.

Μερικές σημαντικές παρατηρήσεις σχετικά με την αναθεώρηση SRS

# 1) Καμία πληροφορία δεν πρέπει να παραμείνει ακάλυπτη.
#δύο) Εκτελέστε ανάλυση σκοπιμότητας σχετικά με το εάν μια συγκεκριμένη απαίτηση είναι σωστή ή όχι και επίσης εάν μπορεί να ελεγχθεί ή όχι.
# 3) Εκτός αν υπάρχει ξεχωριστή απόδοση / ασφάλεια ή οποιαδήποτε άλλη μορφή ομάδων δοκιμών - είναι δική μας δουλειά να διασφαλίσουμε ότι όλες οι μη λειτουργικές απαιτήσεις πρέπει να λαμβάνονται υπόψη.
# 4) Δεν απευθύνονται όλες οι πληροφορίες στους υπεύθυνους δοκιμών, επομένως είναι σημαντικό να κατανοήσουμε τι πρέπει να σημειώσετε και τι όχι.
# 5) Η σημασία και όχι. των περιπτώσεων δοκιμής για ένα σενάριο δοκιμής δεν χρειάζεται να είναι ακριβείς και μπορούν να συμπληρωθούν με μια κατά προσέγγιση τιμή ή μπορεί να αφεθεί άδειο.

Συνοψίζοντας, η αξιολόγηση SRS έχει ως αποτέλεσμα:

  • Λίστα δοκιμών σεναρίων
  • Αποτελέσματα επανεξέτασης - Σφάλματα τεκμηρίωσης / απαιτήσεων εντοπίστηκαν μέσω στατικής διερεύνησης / επαλήθευσης του εγγράφου SRS
  • Μια λίστα ερωτήσεων για καλύτερη κατανόηση - σε περίπτωση οποιουδήποτε άλλου
  • Η προκαταρκτική ιδέα για το πώς υποτίθεται το περιβάλλον δοκιμής
  • Προσδιορισμός εύρους δοκιμών και μια γενική ιδέα για το πόσες δοκιμαστικές περιπτώσεις ενδέχεται να καταλήξουμε - τόσο πόσος χρόνος χρειαζόμαστε για τεκμηρίωση και τελικά εκτέλεση.

Σημαντικά σημεία που πρέπει να σημειώσετε:

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

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

#δύο) Θα μπορούσαμε να χρησιμοποιήσουμε ένα εργαλείο διαχείρισης δοκιμών όπως HP ALM ή q Δοκιμή για να δημιουργήσετε τα σενάρια δοκιμής. Ωστόσο, η δημιουργία σεναρίων δοκιμής σε πραγματικό χρόνο είναι μια μη αυτόματη δραστηριότητα. Κατά τη γνώμη μου, είναι πιο βολικό με το χέρι. Δεδομένου ότι είναι το βήμα 1, δεν χρειάζεται να βγάλουμε τα μεγάλα όπλα ακόμα. Τα απλά φύλλα excel είναι ο καλύτερος τρόπος για να το κάνετε.

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

Ημέρα εκπαίδευσης QA 3: Πώς να γράψετε ένα έγγραφο SRS από το μηδέν.

Κρατήστε τις ερωτήσεις και τα σχόλιά σας. Εκτιμούμε τον αναγνώστη σας έναν τόνο!

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

^