Μενού

Πρακτική δοκιμή λογισμικού QA Process Flow (Απαιτήσεις για απελευθέρωση)

practical software testing qa process flow

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

Μια πλήρης επισκόπηση της ροής διαδικασίας δοκιμής λογισμικού End-to-End QA:

Σημείωση - Δημοσιεύουμε ξανά αυτήν τη χρήσιμη ανάρτηση με ενημερωμένο περιεχόμενο.

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

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

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

Απαιτήσεις για απελευθέρωση

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

Τι θα μάθετε:

Απαίτηση για απελευθέρωση - Πλήρης επισκόπηση

Κύκλος ζωής δοκιμής λογισμικού

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

# 1) Απαίτηση

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

τι είναι καλός μετατροπέας youtube σε mp3

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

Προκλήσεις

Δεν μπορούμε να φανταστούμε όλες τις προϋποθέσεις για να συγκεντρωθείς σε μία μόνο συνεδρίαση. Να είστε αρκετά υπομονετικοί.

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

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

Απαιτήσεις Κύκλος ζωής

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

Βέλτιστες πρακτικές

  • Κρατήστε το μυαλό σας ανοιχτό και δώστε προσοχή σε κάθε λέξη του κατόχου του προϊόντος.
  • Μην ακούτε απλώς, καθαρίστε την αμφιβολία σας όσο μικρή και αν φαίνεται.
  • Χρησιμοποιείτε πάντα φορητούς υπολογιστές για γρήγορη τήρηση σημειώσεων. Πρέπει να χρησιμοποιήσετε φορητό υπολογιστή, μόνο εάν μπορείτε να πληκτρολογήσετε πραγματικά με δίκαιη ταχύτητα.
  • Επαναλάβετε τις προτάσεις και διευκρινίστε τις από το PO που πιστεύετε ότι είναι αυτό που καταλάβατε.
  • Σχεδιάστε μπλοκ διαγράμματα, κείμενο συνδέσμου κ.λπ. για να καταστήσετε τις απαιτήσεις πιο σαφείς σε μεταγενέστερη χρονική περίοδο.
  • Εάν οι ομάδες βρίσκονται σε διαφορετικές τοποθεσίες, προσπαθήστε σκληρά να το κάνετε WebEx ή παρόμοια εγγραφή. Θα βοηθά πάντα όταν έχετε αμφιβολίες μετά το τέλος των συζητήσεων.

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

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

# 2) Στρατηγική δοκιμών

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

Στρατηγική δοκιμής

Προκλήσεις

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

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

Βέλτιστες πρακτικές

  • Ακολουθούν μερικές από τις βέλτιστες πρακτικές, οι οποίες όταν ακολουθούνται μπορούν να σας προσφέρουν μεγάλη ανακούφιση και να οδηγήσουν σε ομαλές δοκιμές.
  • Εξετάστε ξανά το έγγραφο απαίτησης. Επισημάνετε τα σημεία εισαγωγής σε σχέση με το περιβάλλον του λογισμικού προορισμού.
  • Δημιουργήστε μια λίστα με περιβάλλοντα όπου το λογισμικό θα αναπτυχθεί.
  • Τα περιβάλλοντα μπορούν να θεωρηθούν ως τύποι Λειτουργικών Συστημάτων ή Κινητών Συσκευών.
  • Εάν τα Windows είναι το λειτουργικό σύστημα, καταγράψτε όλες τις εκδόσεις του παραθύρου όπου θα δοκιμάσετε το λογισμικό σας. Εάν οι εκδόσεις δηλαδή. Τα Windows 7, Windows 10 ή Windows Server (s) εξακολουθούν να μην ορίζονται στο έγγραφο απαίτησης, τότε είναι η ώρα που πρέπει να συζητηθούν.
  • Σε παρόμοια σημείωση, πάρτε τα προγράμματα περιήγησης προορισμού με τις εκδόσεις που συζητήθηκαν και τεκμηριώθηκαν εάν το AUT είναι ένα σύστημα που βασίζεται στον Ιστό.
  • Δημιουργήστε μια λίστα με όλα τα λογισμικά τρίτων που θα χρειαστεί η εφαρμογή (Εάν απαιτείται / υποστηρίζεται). Αυτά μπορεί να περιλαμβάνουν το Adobe Acrobat, το Microsoft Office, τυχόν πρόσθετα κ.λπ.

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

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

Στρατηγική δοκιμών

# 3) Σχεδιασμός δοκιμών

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

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

Σχέδιο δοκιμής

Προκλήσεις

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

Προκειμένου να ξεπεραστούν ορισμένες προκλήσεις, αυτές οι βέλτιστες πρακτικές μπορούν πραγματικά να είναι χρήσιμες.

Βέλτιστες πρακτικές

  • Να θυμάστε πάντα, για να μην αφήσετε καμία πέτρα όταν πρόκειται για τη δοκιμή της αίτησής σας.
  • Ήρθε η ώρα να διαμορφώσετε μια δοκιμαστική στρατηγική.
  • Δημιουργήστε μια μήτρα του περιβάλλοντος έτσι ώστε το λογισμικό να δοκιμάζεται σε όλες τις πλατφόρμες.
  • Όπως, Windows 10 + Internet Explorer 11+ Windows Office 2010+.
  • Όπως το πρόγραμμα περιήγησης Chrome Android 4.2.2+.
  • Εάν η εφαρμογή σας λειτουργεί με πολλές βάσεις δεδομένων (Εάν τεκμηριώνονται), διατηρήστε τις βάσεις δεδομένων (MySQL, Oracle, SQLServer) στη μήτρα δοκιμής με τέτοιο τρόπο ώστε να είναι πολύ ενσωματωμένες σε ορισμένες δοκιμές.
  • Διαμορφώστε τις δοκιμαστικές μηχανές ανάλογα και ονομάστε τις ως SetUp1, SetUp2 κ.λπ.
  • Το SetUp1 θα διαθέτει Windows 7+ IE 10+ Office 2007+.
  • Το SetUp2 ενδέχεται να έχει Windows 10+ IE Edge + Office 2013+.
  • Το SetUp3 μπορεί να έχει τηλέφωνο Android με εγκατεστημένο το αρχείο .apk.
  • Συγχαρητήρια! Η δοκιμαστική σας ρύθμιση είναι έτοιμη και έχετε συμπεριλάβει επίσης κάθε πιθανό συνδυασμό πλατφορμών στις οποίες θα λειτουργεί η εφαρμογή σας.

# 4) Δοκιμές

Εύρεση σφαλμάτων

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

Το παρακάτω διάγραμμα απεικονίζει την κατηγοριοποίηση διαφόρων τύπων δοκιμών:

Τύποι δοκιμών

Προκλήσεις

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

Βέλτιστες πρακτικές

Χαμογελάστε! Προσπαθείτε να βρείτε ελαττώματα στον κώδικα. Πρέπει να δώσετε προσοχή στη συνολική λειτουργία του λογισμικού.

  • Συνιστάται πάντοτε να κοιτάζετε την εφαρμογή με νέα εμφάνιση, ΧΩΡΙΣ ΠΕΡΙΠΤΩΣΕΙΣ ΜΕΣΩ ΠΕΡΙΠΤΩΣΕΩΝ ΔΟΚΙΜΗΣ.
  • Ακολουθήστε τη διαδρομή πλοήγησης του λογισμικού σας (AUT).
  • Εξοικειωθείτε με το AUT.
  • Τώρα διαβάστε τις δοκιμαστικές θήκες (Όλα) οποιασδήποτε συγκεκριμένης ενότητας (Ίσως της επιλογής σας).
  • Τώρα πηγαίνετε στο AUT και ταιριάξτε τα ευρήματα με αυτά που αναφέρονται στην αναμενόμενη ενότητα των δοκιμαστικών περιπτώσεων.
  • Η ιδέα πίσω από αυτό είναι να δοκιμάσετε κάθε αναφερόμενη δυνατότητα σε κάθε υποστηριζόμενη πλατφόρμα.
  • Σημειώστε κάθε απόκλιση όσο ασήμαντη φαίνεται.
  • Καταγράψτε τα βήματα για το πώς φτάνετε σε οποιαδήποτε απόκλιση, τραβήξτε στιγμιότυπα οθόνης, καταγράψτε αρχεία καταγραφής σφαλμάτων, αρχεία καταγραφής διακομιστή και οποιαδήποτε άλλη τεκμηρίωση που μπορεί να αποδείξει την ύπαρξη ελαττωμάτων.
  • Μη διστάσετε να ρωτήσετε. Αν και έχετε το έγγραφο απαίτησης, θα υπάρξουν στιγμές που θα έχετε αμφιβολίες.
  • Επικοινωνήστε με τους προγραμματιστές (εάν κάθονται δίπλα σας ή είναι προσβάσιμοι) σε αμφιβολία προτού φτάσετε στον Κάτοχο προϊόντος. Κατανοήστε την προοπτική του προγραμματιστή για τη λειτουργία του λογισμικού. Καταλάβετε τους. Εάν πιστεύετε ότι αυτή η εφαρμογή δεν είναι σύμφωνα με την απαίτηση, ενημερώστε τον υπεύθυνο δοκιμών.

# 5) Πριν από την κυκλοφορία

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

Προκλήσεις

Το λογισμικό πρέπει να ελεγχθεί αυστηρά για πολλές από τις παραμέτρους του.

Οι παράμετροι ενδέχεται να μην περιορίζονται σε:

  • Λειτουργικότητα / Συμπεριφορά.
  • Εκτέλεση.
  • Επεκτασιμότητα
  • Συμβατό με τις εν λόγω πλατφόρμες.

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

Βέλτιστες πρακτικές

  • Βεβαιωθείτε ότι έχουν δοκιμαστεί όλες οι δυνατότητες σε όλες τις πλατφόρμες.
  • Επισημάνετε τις περιοχές που δεν έχουν δοκιμαστεί ή εκείνες που χρειάζονται περισσότερες προσπάθειες δοκιμών.
  • Κρατήστε έναν πίνακα όλων των αποτελεσμάτων δοκιμής πριν από την κυκλοφορία. Η δοκιμαστική μήτρα θα δώσει μια συνολική εικόνα της σταθερότητας του προϊόντος. Θα βοηθήσει επίσης τη διοίκηση να λάβει κλήση τις ημερομηνίες κυκλοφορίας.
  • Δώστε τα σχόλιά σας / προτάσεις στην ομάδα σχετικά με τις εμπειρίες σας κατά τη δοκιμή του προϊόντος.
  • Η συμβολή σας που θεωρείτε τον εαυτό σας ως τελικό χρήστη θα ωφελήσει το λογισμικό σε μεγάλο βαθμό.
  • Λόγω του χρονικού περιορισμού ή οποιασδήποτε άλλης τέτοιας κατάστασης, είτε χάνουμε κάποιες δοκιμές είτε δεν το κάνουμε βαθιά. Μην διστάσετε να πείτε την κατάσταση δοκιμής στον διαχειριστή σας.
  • Παρουσιάστε την κάρτα υγείας της αίτησης στους ενδιαφερόμενους. Οι κάρτες υγείας πρέπει να έχουν έναν αριθμό από όλα τα καταγεγραμμένα, ανοιχτά, κλειστά, διαλείπουσα ελαττώματα με τη σοβαρότητα και την προτεραιότητά τους.
  • Συντάξτε ένα έγγραφο κυκλοφορίας και μοιραστείτε το σε όλη την ομάδα.
  • Εργαστείτε στο έγγραφο έκδοσης που ετοιμάστηκε.
  • Βελτιώστε τους τομείς που προτείνονται από τη διεύθυνση / ομάδα.

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

Πριν από την κυκλοφορία

# 6) Απελευθέρωση

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

Προκλήσεις

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

Βέλτιστες πρακτικές

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

Διαδικασία δοκιμής QA σε πραγματικό έργο - Μέθοδος καταρράκτη

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

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

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

Πραγματική διαδικασία δοκιμών σε εταιρείες

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

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

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

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

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

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

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

Βήματα στις απαιτήσεις για απελευθέρωση

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

# 1) Αναθεώρηση SRS : Αναθεώρηση των προδιαγραφών απαιτήσεων λογισμικού.

# 2) Στόχοι έχουν οριστεί για Major κυκλοφορίες.

# 3) Ημερομηνία στόχου προγραμματιστεί για τις κυκλοφορίες.

# 4) Λεπτομερές σχέδιο έργου είναι χτισμένο. Αυτό περιλαμβάνει την απόφαση σχετικά με τις προδιαγραφές σχεδίασης.

# 5) Ανάπτυξη δοκιμαστικού σχεδίου βασίζεται στις προδιαγραφές σχεδίασης.

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

# 7) Προδιαγραφές δοκιμής: Αυτό το έγγραφο περιλαμβάνει τεχνικές λεπτομέρειες (απαιτήσεις λογισμικού) που απαιτούνται πριν από τη δοκιμή.

# 8) Σύνταξη δοκιμαστικών περιπτώσεων

# 9) Ανάπτυξη: Οι ενότητες αναπτύσσονται ένα προς ένα.

# 10) Δέσμευση εγκαταστάσεων: Οι εγκαταστάτες είναι κατασκευασμένοι γύρω από το μεμονωμένο προϊόν.

καλύτερο δωρεάν τείχος προστασίας για τα παράθυρα 7

#έντεκα) Διαδικασία κατασκευής : Μια έκδοση περιλαμβάνει Εγκαταστάτες των διαθέσιμων προϊόντων - πολλαπλές πλατφόρμες.

# 12) Δοκιμή: Δοκιμή καπνού (BVT): Βασικός έλεγχος εφαρμογής για λήψη απόφασης για περαιτέρω δοκιμές.

# 13) Συνοπτική έκθεση δοκιμής

# 14) Πάγωμα κώδικα

  • Δεν προστίθενται πλέον νέες δυνατότητες σε αυτό το σημείο.

# 15) Δοκιμή: Δοκιμή δομής και παλινδρόμησης.

# 16) Απόφαση για απελευθέρωση του προϊόντος.

# 17) Σενάριο μετά την κυκλοφορία για περαιτέρω στόχους.

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

συμπέρασμα

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

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

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

Έχετε συμμετάσχει σε κάποια από τις παραπάνω φάσεις; Μη διστάσετε να μοιραστείτε τις εμπειρίες σας παρακάτω.

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

^