Μενού

Τρόπος δημιουργίας απαιτήσεων Πίνακας ιχνηλασιμότητας (RTM): Παράδειγμα και πρότυπο δείγματος

how create requirements traceability matrix

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

Τι είναι Απαιτήσεις Traceability Matrix (RTM) στο Software Testing: Βήμα-βήμα οδηγός για τη δημιουργία Traceability Matrix με παραδείγματα και δείγμα προτύπου

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

Τις περισσότερες φορές, η δημιουργία, η αναθεώρηση ή η κοινή χρήση ενός Matrix ιχνηλασιμότητας δεν είναι ένα από τα κύρια παραδοτέα της διαδικασίας QA - επομένως δεν επικεντρώνεται σε μεγάλο βαθμό, προκαλώντας έτσι την υπογράμμιση. Αντίθετα, ορισμένοι πελάτες αναμένουν ότι ένα TM θα αποκαλύψει πτυχές που καταστρέφουν τη γη για το προϊόν τους (υπό δοκιμή) και είναι απογοητευμένοι.

Απαιτήσεις ιχνηλασιμότητας μήτρα (RTM)

'Όταν χρησιμοποιείται σωστά, ένας πίνακας ιχνηλασιμότητας μπορεί να είναι το GPS σας για το ταξίδι σας στο QA'.

Όπως είναι μια γενική πρακτική στο STH , θα δούμε τις πτυχές «Τι» και «Πώς» ενός TM σε αυτό το άρθρο.

Τι θα μάθετε:

Ποια είναι η μήτρα ιχνηλασιμότητας της απαίτησης;

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

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

Το επίκεντρο κάθε δοκιμαστικής συμμετοχής είναι και πρέπει να είναι η μέγιστη κάλυψη δοκιμών. Με κάλυψη, αυτό σημαίνει απλώς ότι πρέπει να δοκιμάσουμε ό, τι υπάρχει για να δοκιμαστεί. Ο στόχος οποιουδήποτε έργου δοκιμών πρέπει να είναι η κάλυψη δοκιμών 100%.

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

Γιατί απαιτείται απαίτηση ιχνηλασιμότητα;

Η Απαίτηση ιχνηλασιμότητας Matrix βοηθά στη σύνδεση των απαιτήσεων, Θήκες δοκιμής , και τα ελαττώματα με ακρίβεια. Το σύνολο της εφαρμογής δοκιμάζεται με την απαίτηση ιχνηλασιμότητα ( Δοκιμή End to End επιτυγχάνεται μια εφαρμογή).

πώς να επιλέξετε το κουμπί επιλογής στο πρόγραμμα οδήγησης σεληνίου

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

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

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

Διαρροές ελαττωμάτων

Τύποι μήτρα ιχνηλασιμότητας

Ιχνηλασιμότητα προς τα εμπρός

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

Ιχνηλασιμότητα προς τα εμπρός

Ιχνηλασιμότητα προς τα πίσω

Οι δοκιμαστικές περιπτώσεις χαρτογραφούνται με τις απαιτήσεις στο «Backward Traceability». Ο κύριος σκοπός του είναι να διασφαλίσει ότι το τρέχον προϊόν που αναπτύσσεται βρίσκεται στο σωστό δρόμο. Βοηθά επίσης να προσδιοριστεί ότι δεν προστίθενται επιπλέον μη καθορισμένες λειτουργίες και έτσι επηρεάζεται το πεδίο του έργου.

Ιχνηλασιμότητα προς τα πίσω

Διμελής ιχνηλασιμότητα

(Εμπρός + Πίσω): Ο πίνακας Good Traceability έχει αναφορές από δοκιμαστικές περιπτώσεις σε απαιτήσεις και αντιστρόφως (απαιτήσεις σε δοκιμαστικές περιπτώσεις). Αυτό αναφέρεται ως ιχνηλασιμότητα «αμφίδρομη». Διασφαλίζει ότι όλες οι δοκιμαστικές περιπτώσεις μπορούν να ανιχνευθούν στις απαιτήσεις και κάθε απαίτηση που καθορίζεται έχει ακριβείς και έγκυρες περιπτώσεις δοκιμής για αυτές.

Διμελής ιχνηλασιμότητα

Παραδείγματα RTM

# 1) Απαιτήσεις επιχείρησης

BR1 : Η επιλογή σύνταξης email θα πρέπει να είναι διαθέσιμη.

Σενάριο δοκιμής (τεχνική προδιαγραφή) για BR1

TS1 : Παρέχεται η επιλογή σύνταξης αλληλογραφίας.

Περιπτώσεις δοκιμής:

Περίπτωση δοκιμής 1 (TS1.TC1) : Η επιλογή σύνταξης αλληλογραφίας είναι ενεργοποιημένη και λειτουργεί με επιτυχία.

Υπόθεση δοκιμής 2 (TS1.TC2) : Η επιλογή σύνταξης αλληλογραφίας είναι απενεργοποιημένη.

# 2) Ελαττώματα

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

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

Έτσι, όλες οι απαιτήσεις μπορούν να αναπαρασταθούν σε μορφή πίνακα.

Απαιτήσεις επιχείρησης #Σενάριο δοκιμής #Θήκη #Ελαττώματα #
BR1TS1TS1.TC1
TS1.TC2
Δ01
BR2TS2TS2.TC1
TS2, TC2
TS2.TC3
Δ02
Δ03
BR3TS3TS1.TC1
TS2.TC1
TS3.TC1
TS3.TC2
ΜΗΔΕΝ

Ιχνηλασιμότητα κάλυψης δοκιμών και απαιτήσεων

Τι είναι η δοκιμαστική κάλυψη;

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

Πώς να επιτύχετε την κάλυψη δοκιμής;

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

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

Τύποι προδιαγραφών απαιτήσεων

# 1) Επιχειρηματικές απαιτήσεις

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

Συνήθως προετοιμάζεται από τους «Επιχειρηματικούς Αναλυτές» ή το έργο «Αρχιτέκτονας» (ανάλογα με την οργάνωση ή τη δομή του έργου). Το έγγραφο «Προδιαγραφές απαιτήσεων λογισμικού» (SRS) προέρχεται από το BRS.

# 2) Έγγραφο προδιαγραφής απαιτήσεων λογισμικού (SRS)

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

# 3) Έγγραφα απαιτήσεων έργου (PRD)

Το PRD είναι ένα έγγραφο αναφοράς για όλα τα μέλη της ομάδας σε ένα έργο για να τους πει ακριβώς τι πρέπει να κάνει ένα προϊόν. Μπορεί να χωριστεί σε ενότητες όπως Σκοπός του προϊόντος, Χαρακτηριστικά προϊόντος, Κριτήρια έκδοσης και Προϋπολογισμός & Χρονοδιάγραμμα του έργου.

# 4) Χρήση εγγράφου περίπτωσης

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

Για παράδειγμα,

Ηθοποιός: Πελάτης

Ρόλος: Κατέβασμα παιχνιδιού

Η λήψη του παιχνιδιού είναι επιτυχής.

Το Use Cases μπορεί επίσης να είναι ένα μέρος που περιλαμβάνεται στο έγγραφο SRS σύμφωνα με τη διαδικασία εργασίας του οργανισμού.

# 5) Έγγραφο επαλήθευσης ελαττωμάτων

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

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

# 6) Ιστορίες χρηστών

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

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

Προκλήσεις για συλλογή απαιτήσεων

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

#δύο) Η ερμηνεία του 'Business Analyst' ή 'Product Owner' όποιος παρέχει τις απαιτήσεις απαιτήσεων είναι κρίσιμη. Ομοίως, η ομάδα που λαμβάνει τις πληροφορίες πρέπει να διατυπώσει τις κατάλληλες διευκρινίσεις προκειμένου να κατανοήσει τις προσδοκίες των ενδιαφερομένων.

Η κατανόηση πρέπει να είναι συγχρονισμένη τόσο με τις επιχειρηματικές ανάγκες όσο και με τις πραγματικές προσπάθειες που απαιτούνται για την εφαρμογή της εφαρμογής.

# 3) Οι πληροφορίες πρέπει επίσης να προέρχονται από την άποψη του τελικού χρήστη.

# 4) Η κατάσταση των ενδιαφερομένων μερών συγκρούεται ή αντιφάσκει σε διαφορετικές χρονικές στιγμές.

# 5) Η άποψη του τελικού χρήστη δεν λαμβάνεται υπόψη για πολλούς λόγους και οι άλλοι ενδιαφερόμενοι πιστεύουν ότι «κατανοούν πλήρως» τι απαιτείται για ένα προϊόν, κάτι που γενικά δεν ισχύει.

# 6) Πόροι έλλειψη δεξιοτήτων για την ανάπτυξη εφαρμογών.

# 7) Συχνές αλλαγές στο πεδίο εφαρμογής ή αλλαγή προτεραιότητας για ενότητες.

# 8) Χαμένες, σιωπηρές ή μη τεκμηριωμένες απαιτήσεις.

# 9) Ασυνεπείς ή ασαφείς απαιτήσεις που καθορίζονται από τους πελάτες.

# 10) Το συμπέρασμα όλων των παραγόντων που αναφέρονται παραπάνω είναι ότι η «Επιτυχία» ή «Αποτυχία» ενός έργου εξαρτάται σε μεγάλο βαθμό από μια απαίτηση.

Πώς μπορεί να βοηθήσει η ιχνηλασιμότητα των απαιτήσεων

# 1) Πού εφαρμόζεται μια απαίτηση;

Για παράδειγμα,

Απαίτηση: Εφαρμόστε τη λειτουργία «Σύνταξη αλληλογραφίας» σε μια εφαρμογή αλληλογραφίας.

Εκτέλεση: Όπου στην κύρια σελίδα πρέπει να τοποθετηθεί και να προσπελαστεί το κουμπί «Σύνταξη αλληλογραφίας».

Απαιτούμενη ιχνηλασιμότητα

# 2) Απαιτείται απαίτηση;

Για παράδειγμα,

Απαίτηση: Εφαρμόστε τη λειτουργία «Σύνταξη αλληλογραφίας» σε μια εφαρμογή αλληλογραφίας μόνο σε συγκεκριμένους χρήστες.

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

# 3) Πώς ερμηνεύω μια απαίτηση;

Για παράδειγμα,

Απαίτηση: Λειτουργικότητα «Σύνταξη αλληλογραφίας» σε μια εφαρμογή αλληλογραφίας με γραμματοσειρές και συνημμένα.

Εκτέλεση: Όταν κάνετε κλικ στο «Σύνταξη αλληλογραφίας», ποιες θα πρέπει να παρέχονται όλες οι λειτουργίες;

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

Έτσι, οι απαιτήσεις κατανέμονται σε δευτερεύουσες απαιτήσεις.

# 4) Ποιες αποφάσεις σχεδιασμού επηρεάζουν την εφαρμογή μιας απαίτησης;

Για παράδειγμα,

Απαίτηση: Όλα τα στοιχεία 'Εισερχόμενα', 'Απεσταλμένα', 'Πρόχειρα', 'Ανεπιθύμητα μηνύματα', 'Κάδος απορριμμάτων' κ.λπ. πρέπει να είναι ευδιάκριτα.

Εκτέλεση: Τα στοιχεία που θα είναι ορατά θα πρέπει να εμφανίζονται με τη μορφή 'Δέντρο' ή 'Καρτέλα'.

# 5) Διατίθενται όλες οι απαιτήσεις;

Για παράδειγμα,

Απαίτηση: Παρέχεται η επιλογή αλληλογραφίας «Κάδος απορριμμάτων».

Εκτέλεση: Εάν έχει παρασχεθεί η επιλογή αλληλογραφίας «Κάδος απορριμμάτων», τότε η επιλογή «Διαγραφή» αλληλογραφίας (απαίτηση) πρέπει να εφαρμοστεί αρχικά και θα πρέπει να λειτουργεί με ακρίβεια. Εάν η επιλογή «Διαγραφή» αλληλογραφίας λειτουργεί σωστά, τότε θα συλλέγονται μόνο τα διαγραμμένα μηνύματα ηλεκτρονικού ταχυδρομείου στον «Κάδο απορριμμάτων» και η εφαρμογή της επιλογής αλληλογραφίας «Κάδος απορριμμάτων» (απαίτηση) θα έχει νόημα (θα είναι χρήσιμη).

ερωτήσεις και απαντήσεις στη συνέντευξη informatica powercenter

Πλεονεκτήματα της κάλυψης RTM και δοκιμής

# 1) Η κατασκευή που αναπτύχθηκε και δοκιμάστηκε έχει την απαιτούμενη λειτουργικότητα που ικανοποιεί τις ανάγκες και τις προσδοκίες των «Πελατών» / «Χρήστες». Ο πελάτης πρέπει να πάρει αυτό που θέλει. Η έκπληξη του πελάτη με μια εφαρμογή που δεν κάνει αυτό που αναμένεται να κάνει δεν είναι ικανοποιητική εμπειρία για κανέναν.

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

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

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

Έτσι διασφαλίζεται ότι οι πιθανότητες αποστολής του τελικού προϊόντος στον πελάτη είναι σύμφωνα με τις κορυφαίες απαιτήσεις και είναι σύμφωνα με το χρονοδιάγραμμα.

# 4) Οι δοκιμαστές επαληθεύουν πρώτα την πιο σημαντική λειτουργικότητα που εφαρμόζουν οι προγραμματιστές. Καθώς πραγματοποιείται πρώτα η επαλήθευση (Δοκιμή) του στοιχείου λογισμικού προτεραιότητας, βοηθά να προσδιοριστεί πότε και εάν οι πρώτες εκδόσεις του συστήματος είναι έτοιμες για κυκλοφορία.

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

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

# 7) Ένα φαινομενικά απλό αίτημα αλλαγής μπορεί να συνεπάγεται τροποποιήσεις που πρέπει να γίνουν σε πολλά μέρη της εφαρμογής. Είναι καλύτερα να εξαγάγετε ένα συμπέρασμα σχετικά με το πόση προσπάθεια θα απαιτηθεί πριν συμφωνήσετε να κάνετε την αλλαγή.

Προκλήσεις στην κάλυψη δοκιμών

# 1) Καλό κανάλι επικοινωνίας

Εάν υπάρχουν αλλαγές που προτείνονται από το Ενδιαφερόμενα μέρη , το ίδιο πρέπει να κοινοποιηθεί στις ομάδες ανάπτυξης και δοκιμών στις προηγούμενες φάσεις ανάπτυξης. ΧΩΡΙΣ αυτο στην ώρα Δεν μπορεί να διασφαλιστεί η ανάπτυξη, ο έλεγχος της εφαρμογής και η σύλληψη / διόρθωση ελαττωμάτων.

# 2) Η προτεραιότητα των σεναρίων δοκιμής είναι σημαντική

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

# 3) Εφαρμογή διαδικασίας

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

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

# 4) Διαθεσιμότητα πόρων

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

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

# 5) Αποτελεσματική εφαρμογή στρατηγικής δοκιμών

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

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

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

Για να είμαστε μαζί πρέπει να γνωρίζουμε ακριβώς τι είναι αυτό που πρέπει να παρακολουθείται ή να εντοπίζεται.

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

Ας υποθέσουμε, το ακόλουθο είναι το Έγγραφο Επιχειρηματικών Απαιτήσεων (BRD): ( Κατεβάστε αυτό το δείγμα BRD σε μορφή excel )

(Κάντε κλικ σε οποιαδήποτε εικόνα για μεγέθυνση)

Έγγραφο επιχειρηματικών απαιτήσεων

Ακολουθεί το Έγγραφο λειτουργικών προδιαγραφών (FSD) που βασίζεται στην ερμηνεία του εγγράφου επιχειρησιακών απαιτήσεων (BRD) και στην προσαρμογή του σε εφαρμογές υπολογιστών. Στην ιδανική περίπτωση, όλες οι πτυχές του FSD πρέπει να εξεταστούν στο BRD. Για λόγους απλότητας, έχω χρησιμοποιήσει μόνο τα σημεία 1 και 2.

Δείγμα FSD από Above BRD: ( Κατεβάστε αυτό το δείγμα FSD σε μορφή excel )

Έγγραφο λειτουργικών προδιαγραφών

Σημείωση : Τα BRD και FSD δεν τεκμηριώνονται από ομάδες QA. Είμαστε απλοί, οι καταναλωτές των εγγράφων μαζί με τις άλλες ομάδες έργων.

Με βάση τα παραπάνω δύο έγγραφα εισαγωγής, ως ομάδα QA, καταλήξαμε στην παρακάτω λίστα σεναρίων υψηλού επιπέδου για να δοκιμάσουμε.

Δείγμα σεναρίων δοκιμής από τα παραπάνω BRD και FSD: ( Πραγματοποιήστε λήψη αυτού του αρχείου σεναρίων δοκιμής δείγματος )

Δείγμα σεναρίων δοκιμής

Μόλις φτάσουμε εδώ, τώρα θα ήταν η κατάλληλη στιγμή για να ξεκινήσετε να δημιουργείτε το Matriks Traceability Matrix.

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

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

Ακολουθεί ο τρόπος με τον οποίο ένα απλό Matrix ιχνηλασιμότητας θα αναζητούσε το παράδειγμά μας:

απλό παράδειγμα Traceability Matrix

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

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

Το αποτέλεσμα είναι ως εξής:

απλό παράδειγμα ιχνηλασιμότητας Matrix 2

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

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

Ας δούμε πώς.

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

πώς να δημιουργήσετε τυχαίους αριθμούς σε c ++ μεταξύ 0 και 100

Απλή μήτρα ιχνηλασιμότητας με FSD

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

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

  • Η δοκιμαστική ομάδα κατά κάποιον τρόπο έχασε να εξετάσει τη λειτουργικότητα «Υφιστάμενος χρήστης».
  • Η λειτουργικότητα 'Υφιστάμενος χρήστης' αναβλήθηκε αργότερα ή καταργήθηκε από τις απαιτήσεις λειτουργικότητας της εφαρμογής. Σε αυτήν την περίπτωση, το TM δείχνει ασυνέπεια στο FSD ή στο BRD - πράγμα που σημαίνει ότι πρέπει να γίνει ενημέρωση σε έγγραφα FSD και / ή BRD.

Εάν είναι το σενάριο 1, θα δείξει τα μέρη όπου η ομάδα δοκιμών πρέπει να εργαστεί περισσότερο για να εξασφαλίσει 100% κάλυψη.

Στα σενάρια 2, η TM δεν δείχνει μόνο κενά, αλλά δείχνει λανθασμένη τεκμηρίωση που χρειάζεται άμεση διόρθωση.

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

Η παρακάτω έκδοση του Traceability Matrix γενικά προετοιμάζεται κατά τη διάρκεια ή μετά την εκτέλεση της δοκιμής:

Πίνακας ιχνηλασιμότητας μετά την εκτέλεση της δοκιμής

Πρότυπο λήψης Απαιτήσεων ιχνηλασιμότητας:

=> Πρότυπο ιχνηλασιμότητας Matrix σε μορφή Excel

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

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

# 1) Εμφανίζεται επίσης η κατάσταση εκτέλεσης. Κατά την εκτέλεση, δίνει ένα συγκεντρωτικό στιγμιότυπο για το πώς προχωρά η εργασία.

# 2) Ελαττώματα: Όταν αυτή η στήλη χρησιμοποιείται για τον προσδιορισμό της ιχνηλασιμότητας προς τα πίσω μπορούμε να πούμε ότι η λειτουργικότητα 'Νέος χρήστης' είναι η πιο ελαττωματική. Αντί να αναφέρει ότι έτσι και οι δοκιμαστικές περιπτώσεις απέτυχαν, η TM παρέχει διαφάνεια στην επιχειρηματική απαίτηση που έχει τα περισσότερα ελαττώματα, παρουσιάζοντας έτσι την Ποιότητα ως προς αυτό που επιθυμεί ο πελάτης.

# 3) Ως ένα περαιτέρω βήμα, μπορείτε να χρωματίσετε τον κωδικό ελαττώματος για να αντιπροσωπεύσετε τις καταστάσεις τους. Για παράδειγμα, Το αναγνωριστικό ελαττώματος με κόκκινο χρώμα μπορεί να σημαίνει ότι είναι ακόμα ανοιχτό, με πράσινο χρώμα μπορεί να σημαίνει ότι είναι κλειστό. Όταν γίνει αυτό, το TM λειτουργεί ως αναφορά υγειονομικού ελέγχου που εμφανίζει την κατάσταση των ελαττωμάτων που αντιστοιχούν σε μια συγκεκριμένη λειτουργικότητα BRD ή FSD είναι ανοιχτή ή κλειστή.

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

Συνοψίζοντας, το RTM βοηθά:

  • Εξασφάλιση 100% κάλυψης δοκιμών
  • Εμφάνιση ασυνεπειών απαιτήσεων / εγγράφου
  • Εμφάνιση της συνολικής κατάστασης ελαττωμάτων / εκτέλεσης με έμφαση στις επιχειρηματικές απαιτήσεις.
  • Εάν μια συγκεκριμένη επιχείρηση και / ή λειτουργική απαίτηση επρόκειτο να αλλάξει, ένα TM βοηθά στην εκτίμηση ή ανάλυση του αντίκτυπου στην εργασία της ομάδας QA όσον αφορά την επανεξέταση / επανεξέταση στις δοκιμαστικές περιπτώσεις.

Επιπροσθέτως,

  • Το Traceability Matrix δεν είναι ένα εργαλείο χειροκίνητης δοκιμής, μπορεί να χρησιμοποιηθεί και για έργα αυτοματισμού. Για ένα έργο αυτοματισμού, το αναγνωριστικό περίπτωσης δοκιμής μπορεί να υποδεικνύει το όνομα του σεναρίου αυτοματισμού δοκιμής.
  • Επίσης, δεν είναι ένα εργαλείο που μπορεί να χρησιμοποιηθεί μόνο από τα QA. Η ομάδα ανάπτυξης μπορεί να χρησιμοποιήσει το ίδιο για να χαρτογραφήσει τις απαιτήσεις BRD / FSD σε μπλοκ / μονάδες / συνθήκες κώδικα που δημιουργήθηκαν για να βεβαιωθεί ότι έχουν αναπτυχθεί όλες οι απαιτήσεις.
  • Εργαλεία διαχείρισης δοκιμών όπως HP ALM ελάτε με την ενσωματωμένη δυνατότητα ιχνηλασιμότητας.

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

συμπέρασμα

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

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

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

Σχετικά με τον Συγγραφέα: Το μέλος της ομάδας STH Urmila P. είναι έμπειρος επαγγελματίας QA υψηλή ποιότητα δοκιμές και εκδόσεις δεξιοτήτων παρακολούθησης.

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

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

^