40+ Δημοφιλείς ερωτήσεις και απαντήσεις συνέντευξης αναλυτή QA (2021 LIST)

40 popular test qa analyst interview questions

Συνήθεις ερωτήσεις και απαντήσεις για συνεντεύξεις αναλυτή διασφάλισης ποιότητας / διασφάλισης ποιότητας:

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

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

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

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

Δημοφιλείς ερωτήσεις συνέντευξης αναλυτή δοκιμής QA

Q # 1) Ποιες είναι οι ευθύνες ενός αναλυτή QA;

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

Οι κύριες ευθύνες του QA Analyst μπορούν να καταχωριστούν ως εξής:

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

Ε # 2) Ποια είναι η κατανόησή σας σχετικά με ένα σχέδιο δοκιμών;

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

Το σχέδιο δοκιμών είναι ένα αρχείο διαδικασιών που περιλαμβάνουν:

• Εργασίες δοκιμής
• Περιβάλλον δοκιμών
• Τεχνικές σχεδιασμού
• Κριτήρια εισόδου και εξόδου
• Τυχόν κίνδυνοι κ.λπ.

Q # 3) Καταχωρίστε την προτεραιότητα των εργασιών δοκιμής που ορίζονται από την ομάδα QA στην ανάπτυξη προϊόντων.

Απάντηση: Η προτεραιότητα των εργασιών δοκιμής ορίζεται ως εξής:

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

Ε # 4) Προσκαλέστε μερικές από τις βασικές προκλήσεις που αντιμετωπίζετε κατά την εκτέλεση του Δοκιμή λογισμικού.

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

Παρακάτω αναφέρονται μερικές βασικές προκλήσεις:

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

Q # 5) Ορισμός δοκιμής περίπτωσης χρήσης.

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

Τα χαρακτηριστικά της δοκιμής περίπτωσης χρήσης αναφέρονται παρακάτω:

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

Q # 6) Ορίστε τη στρατηγική δοκιμής.

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

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

Αυτές οι προσεγγίσεις κατηγοριοποιούνται περαιτέρω ως εξής:

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

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

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

Ας κατανοήσουμε τη διαφορά με τη βοήθεια του παρακάτω πίνακα.

Ε # 8) Σύμφωνα με εσάς, πότε είναι η κατάλληλη στιγμή για να ξεκινήσετε το QA σε ένα έργο;

Απάντηση: Σύμφωνα με τον Κύκλο ζωής ανάπτυξης λογισμικού (SDLC), η φάση δοκιμών εκτελείται μετά την ολοκλήρωση της φάσης «Εφαρμογή και κωδικοποίηση». Αλλά στο σημερινό σενάριο, για να επιτευχθούν τα καλύτερα αποτελέσματα, απαιτείται να ξεκινήσετε το QA του έργου ή του προϊόντος κατά την έναρξη του έργου.

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

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

Q # 9) Διαφοροποιήστε τις διαδικασίες επαλήθευσης και επικύρωσης.

Απάντηση: Οι διαδικασίες επαλήθευσης και επικύρωσης καθορίζονται συνήθως από δύο διάσημες ερωτήσεις, δηλαδή ' Χτίζουμε το σύστημα σωστά; ' και «Χτίζουμε το σωστό σύστημα;» .

Ας δούμε την άλλη διαφορά μεταξύ αυτών των δύο διαδικασιών στον παρακάτω πίνακα:

Ερώτηση # 10) Εξηγήστε τα οφέλη του καταστρεπτικού ελέγχου.

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

Παρακάτω αναφέρονται τα οφέλη του καταστρεπτικού ελέγχου:

• Η αδυναμία του σχεδιασμού της εφαρμογής προσδιορίζεται.
• Προσδιορίστε τη διάρκεια ζωής της εφαρμογής.
• Βοηθά στη μείωση του κόστους και της αποτυχίας.

Ε # 11) Πώς διαφέρει η δοκιμή από τον έλεγχο παλινδρόμησης;

Απάντηση: Υπάρχουν αρκετές διαφορές μεταξύ δοκιμής επανάληψης και ελέγχου παλινδρόμησης.

Αυτό γίνεται εύκολα κατανοητό από τον παρακάτω πίνακα:

Ε # 12) Τι γνωρίζετε για τις δοκιμές βάσει δεδομένων;

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

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

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

το καλύτερο λογισμικό κειμένου σε ομιλία

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

Q # 13) Τι είναι ο πίνακας ιχνηλασιμότητας; Απαιτείται για κάθε έργο;

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

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

Οι παράμετροι του πίνακα απαιτήσεων ιχνηλασιμότητας περιλαμβάνουν:

• Κάθε ενότητα του εγγράφου απαίτησης είναι ένα σημείο που πρέπει να καλυφθεί στο RTM (Απαίτηση ιχνηλασιμότητας μήτρα).
• Ο τίτλος κάθε σημείου είναι ο τίτλος κάθε ενότητας στην προδιαγραφή απαίτησης.
• Αντιστοιχούν σε κάθε σημείο, αναφέρονται τα αναγνωριστικά περίπτωσης δοκιμής που είναι γραμμένα για τη συγκεκριμένη ενότητα.
• BUG / New Feature ID αναφέρεται επίσης σε κάθε ενότητα.
• Το πιο σημαντικό σημείο είναι ότι διατηρείται η παρακολούθηση του χαρακτηριστικού στο οποίο έχει υλοποιηθεί η κατασκευή του έργου και του χαρακτηριστικού του.
• Μια άλλη παράμετρος περιλαμβάνει εάν το τμήμα έχει δοκιμαστεί πλήρως ή βρίσκεται ακόμη σε κατάσταση δοκιμής.

Q # 14) Περιγράψτε τα οφέλη του Agile Testing.

Απάντηση: Όντας δοκιμαστής, η εστίαση γίνεται παράδοση του ποιοτικού προϊόντος σε λιγότερο χρόνο κατανοώντας τις απαιτήσεις του τελικού χρήστη και το πιο σημαντικό, δεν υπάρχουν ελαττώματα από την πλευρά του τελικού χρήστη. Εδώ, το Agile testing έρχεται στην εικόνα που ακολουθεί την αρχή της ευέλικτης ανάπτυξης λογισμικού και επικυρώνει γρήγορα τις απαιτήσεις του πελάτη.

Παρακάτω αναφέρονται τα οφέλη της δοκιμής Agile:

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

Q # 15) Τι είναι ο αρνητικός έλεγχος;

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

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

Q # 16) Διαφοροποίηση Ad-hoc Test και Exploratory Testing;

Απάντηση: Υπάρχουν αρκετές διαφορές μεταξύ δοκιμών Ad-hoc και εξερευνητικών δοκιμών.

Ας δούμε τις διαφορές στον παρακάτω πίνακα:

Q # 17) Γιατί προτιμάται ο έλεγχος αυτοματισμού σε σχέση με τη μη αυτόματη δοκιμή;

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

Παρακάτω δίνονται ορισμένες σημαντικές πτυχές λόγω των οποίων προτιμάται ο Έλεγχος Αυτοματισμού σε σχέση με τη Μη αυτόματη Δοκιμή:

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

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

Ε # 18) Τι καταλαβαίνετε από την «αποτελεσματικότητα δοκιμής» και την «αποτελεσματικότητα δοκιμής»;

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

Αυτό μπορεί να προσδιοριστεί από τον τύπο:

Δοκιμή αποτελεσματικότητας = (Αριθμός υποβληθέντων ελαττωμάτων / συνολικός αριθμός ελαττωμάτων που υποβλήθηκαν) * 100

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

Αυτό μπορεί να προσδιοριστεί από τον τύπο:

Δοκιμή αποτελεσματικότητας = (Αριθμός διαπιστωθέντων ελαττωμάτων / Αριθμός δοκιμαστικών περιπτώσεων που εκτελέστηκαν)

Q # 19) Εξηγήστε τη διαδικασία της Προσαρμογής Προγράμματος.

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

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

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

• Προσέγγιση έργου
• Στρατηγικές
• Εμπλεκόμενοι έλεγχοι και διαδικασίες
• Ρόλοι και ευθύνες

Ε # 20) Πώς διαφοροποιείτε την προτεραιότητα και τη σοβαρότητα του ελαττώματος στο έργο;

Απάντηση: Τόσο η «Προτεραιότητα» όσο και η «Σοβαρότητα» αντιστοιχίζονται στο σφάλμα για την κατηγοριοποίηση των ζητημάτων / σφαλμάτων για τη σειρά με την οποία πρέπει να ληφθούν για διόρθωση. Αυτά βασίζονται σε διάφορους παράγοντες.

Ας καταλάβουμε περισσότερα μαζί με τις διαφορές τους στον παρακάτω πίνακα:

Ε # 21) Γιατί είναι απαραίτητο να γίνει Δοκιμή απόδοσης για οποιαδήποτε εφαρμογή;

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

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

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

Q # 22) Τι είναι ο έλεγχος βάσει προδιαγραφών;

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

Αυτή η μορφή δοκιμών είναι η ίδια με το «Black box testing» όπου ο χρήστης εισάγει πολλά δεδομένα και στη συνέχεια παρατηρείται η έξοδος. Είναι κατάλληλο σε όλα τα επίπεδα δοκιμών με προδιαγραφές και σχέδιο δοκιμών.

Q # 23) Εξηγήστε το CMMI.

Απάντηση: Το CMMI σημαίνει Capability Maturity Model Integration. Αυτό το μοντέλο αναπτύχθηκε από το Ινστιτούτο Μηχανικής Λογισμικού (SEI). Βασίζεται στην αρχή ότι οι διαδικασίες που σχετίζονται με τη διαχείριση και την ανάπτυξη ενός προϊόντος ή συστήματος καθορίζουν την ποιότητα.

Παρέχει επίσης οδηγίες για τη βελτίωση της διαδικασίας για το προϊόν ή ακόμη και για ολόκληρο τον οργανισμό.

Το CMMI χωρίζεται σε 5 επίπεδα όπως αναφέρονται παρακάτω:

• Επίπεδο 1: Αρχικός
• Επίπεδο 2: Διαχειρίζεται
• Επίπεδο 3: Ορίζεται
• Επίπεδο 4: Ποσοτικά διαχειριζόμενο
• Επίπεδο 5: Βελτιστοποιημένο

Q # 24) Εξηγήστε τα πλεονεκτήματα της εφαρμογής CMMI.

Απάντηση: Υπάρχουν πολλά πλεονεκτήματα στην εφαρμογή του CMMI.

Παρατίθενται ως εξής:

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

Q # 25) Καταχωρίστε μερικά εργαλεία αυτοματισμού δοκιμών.

Απάντηση: Μερικά από τα εργαλεία δοκιμών αυτοματισμού παρατίθενται παρακάτω:

• Σελήνιο
• νερό
• Ανεμόμυλος
• ΣΑΠΟΥΝΙ
• Τελλούριο

Q # 26) Μπορούμε να κάνουμε τον έλεγχο παλινδρόμησης στο Test Unit;

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

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

Ε # 27) Ποια είναι η διαφορά μεταξύ δοκιμών καπνού και δοκιμής Sanity;

Απάντηση:

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

Ε # 28 Ποιες είναι οι καθημερινές σας δραστηριότητες ως χειροκίνητος ελεγκτής στο γραφείο σας;

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

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

Q # 29) Ποιες είναι οι καθημερινές σας δραστηριότητες ως μέλος του αυτοματισμού στο γραφείο σας;

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

Ο κύκλος εκτέλεσης μπορεί να ονομαστεί Health Check, για να δείτε πόσο υγιής είναι η κατασκευή.

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

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

Q # 30) Πώς διαφοροποιείτε μια απαίτηση και ένα ελάττωμα και μια βελτίωση;

Απάντηση : ΠΡΟΣ ΤΗΝ απαίτηση είναι μια ιστορία χρηστών που είναι απαραίτητη για εφαρμογή, δοκιμή και παράδοση.
Ενα Βελτιστοποίηση είναι ένα πρόσθετο ή αυτοσχέδιο χαρακτηριστικό του υπάρχοντος.
ΠΡΟΣ ΤΗΝ ελάττωμα είναι μάλλον μια πλήρης απόκλιση από τις αναμενόμενες ιστορίες χρηστών.

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

Ε # 31) Τι κάνετε όταν ο προγραμματιστής σας αρνείται να διορθώσει ένα σφάλμα που υποβάλατε;

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

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

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

Q # 32) Τι κάνετε όταν ο προγραμματιστής σας αρνείται ότι αυτό που έχετε υποβάλει ΕΙΝΑΙ ΔΙΑΚΟΠΗ;

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

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

Q # 33) Τι έρχεται η πρώτη δοκιμή Re-testing ή Regression;

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

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

Q # 34) Ποια είναι μια εναλλακτική λύση για το Beta Testing;

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

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

Q # 35) Ποια είναι τα μειονεκτήματα της εφαρμογής / μεθοδολογίας Agile που αντιμετωπίσατε;

Απάντηση : Τα μειονεκτήματα έχουν ως εξής:

1. Οι σπριντ συνήθως περιορίζονται σε πολύ προθεσμία.
2. Η τεκμηρίωση δεν είναι η προτεραιότητα
3. Η εναλλαγή μεταξύ PBIs (Προϊόν καθυστέρησης προϊόντος) μπορεί να είναι συχνή.

Q # 36) Γιατί είναι σημαντική η ανάλυση επιπτώσεων;

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

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

Ε # 37 Με τη βοήθεια ενός παραδείγματος κάθε Δοκιμή απόδοσης, Δοκιμή πίεσης και Δοκιμή φορτίου;

Απάντηση : Η καλύτερη περίπτωση που μπορεί να ληφθεί είναι ένας ζωντανός ιστότοπος.

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

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

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

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

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

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

Για παράδειγμα, ο χρόνος για τη λήψη διαθεσιμότητας θέσης για ένα τρένο αυξάνεται σταδιακά όταν πλησιάζει ο χρόνος κράτησης Tatkal, δεδομένου ότι ο αριθμός των χρηστών στη συνέχεια εισήλθε στο σύστημα αυξάνεται με την ώρα κράτησης Tatkal κοντά στις 10 π.μ. ή 11 π.μ.

Ε # 38) Ποια ήταν μια από τις μεγαλύτερες προκλήσεις σας κατά τη δοκιμή παλινδρόμησης;

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

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

Q # 39) Εάν σας ζητηθεί να τεκμηριώσετε τα σενάρια δοκιμής, τις περιπτώσεις δοκιμής, τα σχέδια δοκιμών, τη στρατηγική δοκιμών με τι θα ξεκινήσετε και με ποια ακολουθία θα ακολουθήσουν οι υπόλοιποι;

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

Q # 40) Τι γίνεται αν χάσω την τεκμηρίωση ενός από τα παραπάνω; Ας πούμε ότι μου λείπει η τεκμηρίωση του σχεδίου δοκιμών ποιες θα είναι οι συνέπειες;

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

Q # 41) Πώς θα αρχίσατε να δοκιμάζετε το build που έχετε πρόσφατα: Υπάρχει κάποια προσέγγιση που ακολουθείτε π.χ. πρώτα ξεκινήστε τη δοκιμή καπνού και μετά τη δοκιμή Sanity;

Απάντηση : Δοκιμή καπνού> Δοκιμή υγιεινής> Εξερευνητικές δοκιμές> Δοκιμή λειτουργικότητας> Δοκιμή παλινδρόμησης και επικύρωση τελικού προϊόντος.

Q # 42) Εξηγήστε τη μορφή της αναφοράς σφάλματος που ακολουθήσατε;

Απάντηση :

Μια αναφορά σφάλματος πρέπει να περιέχει τις ακόλουθες πληροφορίες:

• Αναγνωριστικό σφάλματος
• Αντιστοίχιση σε Απαίτηση / Βελτίωση / Υφιστάμενο σφάλμα
• Περίληψη / τίτλος σφαλμάτων
• Μια έκδοση του προϊόντος
• Προτεραιότητα
• Διαμόρφωση (προδιαγραφές συστήματος)
• Προαπαιτούμενα
• Βήματα
• Αναμενόμενο αποτέλεσμα
• Πραγματικό αποτέλεσμα
• Κούτσουρα. Στιγμιότυπα, βίντεο κλιπ
• Κατάσταση
• Άλλες παρατηρήσεις

Q # 43) Πώς επιλέγετε περιπτώσεις δοκιμής παλινδρόμησης ή σχηματίζετε τη σουίτα δοκιμής παλινδρόμησης;

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

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

Q # 44) Μπορείτε να έρθετε με ένα παράδειγμα των παρακάτω ελαττωμάτων

• Ελάττωμα χαμηλής προτεραιότητας χαμηλής προτεραιότητας
• Ελάττωμα υψηλής προτεραιότητας και χαμηλής σοβαρότητας

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

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

Q # 45) Γράψτε μια αποτελεσματική δοκιμαστική θήκη για να ελέγξετε εάν ένα δεδομένο χαρτί είναι λευκό χαρτί;

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

Σημείωση: Υπάρχουν πολλές άλλες απαντήσεις σε αυτήν την ερώτηση. Μπορείτε να σκεφτείτε οποιαδήποτε τέτοια έγκυρη απάντηση με την υποκείμενη λογική.

Q # 46) Τι είναι ο έλεγχος του Χάρτη;

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

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

Q # 47) Ποια είναι η προσέγγισή σας όταν έχετε μια κυκλοφορία υψηλής προτεραιότητας που θα παραδοθεί σε πολύ σύντομο χρονικό διάστημα;

Απάντηση: Σε τέτοιες περιπτώσεις, ένα καλά μελετημένο σχέδιο μπορεί να είναι επωφελές.

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

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

Q # 48) Να γράψετε δοκιμαστικές θήκες σε οποιαδήποτε συσκευή / αντικείμενο που υπάρχει γύρω (Παράδειγμα: μια καρέκλα);

Απάντηση: Μια συμβουλή εδώ θα ήταν: Ξεκινάτε πάντα με τις απαιτήσεις συγκέντρωσης. Δείχνει την ωριμότητα σας προς τον Κύκλο Ζωής Ανάπτυξης Λογισμικού. Μη διστάσετε να κάνετε ερωτήσεις αφού επιλέξετε το αντικείμενο.

Σε αυτήν την περίπτωση:-

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

Οι δοκιμαστικές περιπτώσεις θα διέφεραν για κάθε τύπο καρέκλας, κάτι που απομένει καλύτερα για την ικανότητα σκέψης σας ( Για παράδειγμα, σκοπός της καρέκλας, διαστάσεις ανάλογα με τον τύπο της καρέκλας, φορητές μη πόσιμες, ελαφριές, επιλογές αγοράς).

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

Q # 49) Μπορούν όλα να αυτοματοποιηθούν;

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

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

συμπέρασμα

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

Ως εκ τούτου, είναι πάντοτε σκόπιμο να ασκείστε μια ψεύτικη συνέντευξη με το pre-hand, έτσι ώστε η συνέντευξη να αποδειχθεί μια win-win κατάσταση τόσο για τον ερευνητή όσο και για τον υποψήφιο. Θυμηθείτε ότι ένας αναλυτής ποιότητας είναι κάτι περισσότερο από έναν μηχανικό δοκιμών, του οποίου τα σχόλια είναι σημαντικά όχι μόνο για την ποιότητα του προϊόντος, αλλά και για τη διαδικασία που ακολουθείται για τη δοκιμή του λογισμικού.

Ευχαριστώ και καλή τύχη με τις συνεντεύξεις!

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

• Ερωτήσεις και απαντήσεις συνέντευξης
• 25+ πιο δημοφιλείς ερωτήσεις και απαντήσεις συνέντευξης ADO.NET
• 25 καλύτερες ερωτήσεις και απαντήσεις συνέντευξης δοκιμών ευκίνητων
• Ερωτήσεις συνέντευξης Spock με απαντήσεις (πιο δημοφιλείς)
• Ερωτήσεις και απαντήσεις συνέντευξης δοκιμών ETL
• 20 πιο δημοφιλείς ερωτήσεις και απαντήσεις στη συνέντευξη TestNG
• Κορυφαίες 30+ δημοφιλείς ερωτήσεις και απαντήσεις συνέντευξης αγγουριών
• Κορυφαίες 50 πιο δημοφιλείς ερωτήσεις και απαντήσεις συνέντευξης CCNA