smoke testing vs sanity testing
Εξερευνήστε λεπτομερώς τις διαφορές μεταξύ δοκιμής καπνού και δοκιμής υγιεινής με παραδείγματα:
Σε αυτό το σεμινάριο, θα μάθουμε τι είναι το Sanity Testing και το Smoke Testing στο Software Testing. Θα μάθουμε επίσης τις βασικές διαφορές μεταξύ των δοκιμών Sanity και Smoke με απλά παραδείγματα.
Τις περισσότερες φορές συγχέουμε μεταξύ της έννοιας του Sanity Testing και του Smoke Testing. Πρώτα απ 'όλα, αυτές οι δύο δοκιμές είναι τρόπος ' διαφορετικός 'Και εκτελούνται σε διαφορετικά στάδια ενός κύκλου δοκιμών.
Τι θα μάθετε:
- Δοκιμή υγιεινής
- Η εμπειρία μου
- Δοκιμή Sanity Vs Regression Testing
- Στρατηγική για δοκιμές εφαρμογών για κινητά
- Προληπτικά μέτρα
- Δοκιμή καπνού
- Παραδείγματα δοκιμής καπνού
- Σημασία στη μεθοδολογία SCRUM
- Δοκιμή καπνού Vs Δοκιμή αποδοχής
- Κύκλος δοκιμής καπνού
- Ποιος πρέπει να πραγματοποιήσει τη δοκιμή καπνού;
- Γιατί πρέπει να αυτοματοποιήσουμε τις δοκιμές καπνού;
- Πλεονεκτήματα και μειονεκτήματα
- Διαφορά μεταξύ δοκιμών καπνού και λογικής
- Συνιστώμενη ανάγνωση
Δοκιμή υγιεινής
Το Sanity Testing πραγματοποιείται όταν ως QA δεν έχουμε αρκετό χρόνο για να εκτελέσουμε όλες τις δοκιμαστικές περιπτώσεις Λειτουργική δοκιμή , UI, OS ή Πρόγραμμα περιήγησης.
Ως εκ τούτου, θα ορίσω,
'Sanity Testing ως εκτέλεση δοκιμής που γίνεται για να αγγίξει κάθε εφαρμογή και τον αντίκτυπό της, αλλά όχι διεξοδικά ή σε βάθος, μπορεί να περιλαμβάνει λειτουργικές δοκιμές, διεπαφή χρήστη, έκδοση κ.λπ., ανάλογα με την εφαρμογή και τον αντίκτυπό της.'
Δεν πέφτουμε όλοι σε μια κατάσταση κατά την οποία πρέπει να αποσυνδεθούμε σε μια ή δύο ημέρες, αλλά η έκδοση για δοκιμές εξακολουθεί να μην κυκλοφορεί;
μοντέλα κύκλου ζωής ανάπτυξης λογισμικού καταρράκτη
Ναι, στοιχηματίζω ότι πρέπει επίσης να έχετε αντιμετωπίσει αυτήν την κατάσταση τουλάχιστον μία φορά στην εμπειρία σας στη Δοκιμή λογισμικού. Λοιπόν, το αντιμετώπισα πολύ γιατί τα έργα μου ήταν κυρίως ευκίνητα και μερικές φορές μας ζητήθηκε να το παραδώσουμε την ίδια μέρα. Ωχ, πώς μπορώ να δοκιμάσω και να αποδεσμεύσω το build μέσα σε λίγες ώρες;
Συνήθιζα να τρελαίνομαι μερικές φορές γιατί ακόμα κι αν ήταν μια μικρή λειτουργικότητα, η επίπτωση θα μπορούσε να είναι τεράστια. Και ως κερασάκι στην τούρτα, οι πελάτες μερικές φορές απλώς αρνούνται να δώσουν επιπλέον χρόνο. Πώς θα μπορούσα να ολοκληρώσω ολόκληρο τον έλεγχο σε λίγες ώρες, να επαληθεύσω κάθε λειτουργικότητα, Σφάλματα και να το απελευθερώσετε;
Η απάντηση σε όλα αυτά τα προβλήματα ήταν πολύ απλή, δηλαδή μόνο με χρήση Στρατηγική δοκιμής Sanity.
Όταν κάνουμε αυτόν τον έλεγχο για μια λειτουργική μονάδα ή λειτουργικότητα ή ένα πλήρες σύστημα, το Δοκιμές για εκτέλεση επιλέγονται έτσι ώστε να αγγίζουν όλα τα σημαντικά κομμάτια του ίδιου, δηλαδή ευρεία αλλά ρηχή δοκιμή.
Μερικές φορές η δοκιμή γίνεται ακόμη και τυχαία χωρίς περιπτώσεις δοκιμών. Αλλά θυμίσου, Η δοκιμή υγιεινής πρέπει να γίνεται μόνο όταν έχετε λίγο χρόνο, μην το χρησιμοποιείτε ποτέ για τις κανονικές σας κυκλοφορίες. Θεωρητικά, αυτή η δοκιμή είναι ένα υποσύνολο του Δοκιμή παλινδρόμησης .
Η εμπειρία μου
Από τα 8+ χρόνια καριέρας μου στο Software Testing, για 3 χρόνια δούλευα Ευέλικτη μεθοδολογία και αυτή ήταν η στιγμή που χρησιμοποίησα ως επί το πλείστον ένα τεστ λογικής.
Όλες οι μεγάλες κυκλοφορίες σχεδιάστηκαν και εκτελέστηκαν με συστηματικό τρόπο, αλλά κατά καιρούς, ζητήθηκαν οι μικρές κυκλοφορίες να παραδοθούν το συντομότερο δυνατό. Δεν είχαμε πολύ χρόνο να τεκμηριώσουμε τις δοκιμαστικές θήκες, να εκτελέσουμε, να κάνουμε την τεκμηρίωση σφαλμάτων, να κάνουμε την παλινδρόμηση και να ακολουθήσουμε ολόκληρη τη διαδικασία.
Ως εκ τούτου, τα ακόλουθα είναι μερικά από τα βασικά σημεία που συνήθιζα να ακολουθώ σε τέτοιες καταστάσεις:
# 1) Καθίστε με τον διευθυντή και την ομάδα προγραμματιστών όταν συζητούν την υλοποίηση επειδή πρέπει να εργαστούν γρήγορα και ως εκ τούτου δεν μπορούμε να περιμένουμε από εμάς να μας εξηγήσουν ξεχωριστά.
Αυτό θα σας βοηθούσε επίσης να πάρετε μια ιδέα για το τι πρόκειται να εφαρμόσουν, σε ποιον τομέα θα επηρεάσει κ.λπ., αυτό είναι ένα πολύ σημαντικό πράγμα που πρέπει να κάνουμε γιατί μερικές φορές απλώς δεν συνειδητοποιούμε τις επιπτώσεις και αν υπάρχει υπάρχουσα λειτουργικότητα πρόκειται να παρεμποδιστεί (στη χειρότερη).
#δύο) Καθώς δεν έχετε χρόνο, τη στιγμή που η ομάδα ανάπτυξης εργάζεται για την εφαρμογή, μπορείτε να σημειώσετε τις δοκιμαστικές θήκες περίπου σε εργαλεία όπως το Evernote κ.λπ. Αλλά βεβαιωθείτε ότι τα γράφετε κάπου έτσι ώστε να μπορείτε να τα προσθέσετε αργότερα στο το εργαλείο δοκιμαστικής θήκης.
# 3) Διατηρήστε το δοκιμαστικό σας τραπέζι έτοιμο σύμφωνα με την εφαρμογή και αν πιστεύετε ότι υπάρχουν κόκκινες σημαίες όπως κάποια συγκεκριμένη δημιουργία δεδομένων εάν μια δοκιμαστική επιφάνεια θα χρειαστεί χρόνος (και είναι ένα σημαντικό τεστ για την κυκλοφορία), στη συνέχεια, σηκώστε αυτές τις σημαίες αμέσως και ενημερώστε τον διαχειριστή σας ή Σημείωση σχετικά με την ταυτόχρονη εμφάνιση.
Ακριβώς επειδή ο πελάτης θέλει το συντομότερο δυνατόν, δεν σημαίνει ότι ένα QA θα κυκλοφορήσει ακόμη και αν είναι μισό δοκιμασμένο.
# 4) Κάντε μια συμφωνία με την ομάδα και τον διευθυντή σας ότι λόγω της χρονικής κρίσης θα κοινοποιήσετε μόνο τα σφάλματα στην ομάδα ανάπτυξης και η επίσημη διαδικασία προσθήκης, η σήμανση των σφαλμάτων για διαφορετικά στάδια στο εργαλείο παρακολούθησης σφαλμάτων θα γίνει αργότερα για να εξοικονομήσετε χρόνο .
# 5) Όταν η ομάδα ανάπτυξης δοκιμάζει στο τέλος τους, προσπαθήστε να τα συνδυάσετε (που ονομάζεται ζεύγος dev-QA) και να κάνετε έναν βασικό γύρο στην ίδια την εγκατάστασή τους, αυτό θα βοηθήσει στην αποφυγή της μετάβασης από την κατασκευή εάν η βασική εφαρμογή αποτυγχάνει .
# 6) Τώρα που έχετε την έκδοση, δοκιμάστε πρώτα τους επιχειρηματικούς κανόνες και όλες τις περιπτώσεις χρήσης. Μπορείτε να διατηρήσετε δοκιμές όπως επικύρωση πεδίου, πλοήγηση κ.λπ. για αργότερα.
# 7) Οποιαδήποτε σφάλματα εντοπίσετε, σημειώστε όλα αυτά και προσπαθήστε να τα αναφέρετε μαζί στους προγραμματιστές αντί να αναφέρετε μεμονωμένα, επειδή θα είναι εύκολο για αυτούς να δουλέψουν σε ένα σωρό.
# 8) Εάν έχετε μια απαίτηση για το σύνολο Δοκιμή απόδοσης ή Έλεγχος πίεσης ή φόρτωσης και, στη συνέχεια, βεβαιωθείτε ότι έχετε ένα κατάλληλο πλαίσιο αυτοματισμού για το ίδιο. Επειδή είναι σχεδόν αδύνατο να τα δοκιμάσετε χειροκίνητα με ένα τεστ λογικής.
# 9) Αυτό είναι το πιο σημαντικό μέρος, και μάλιστα το τελευταίο βήμα της στρατηγικής σας για τη δοκιμή λογικής - «Όταν συντάσσετε το email έκδοσης ή το έγγραφο, αναφέρετε όλες τις δοκιμαστικές περιπτώσεις που εκτελέσατε, τα σφάλματα που εντοπίστηκαν με ένα δείκτη κατάστασης και αν είχε απομείνει κάτι μη δοκιμασμένο να το αναφέρετε με τους λόγους ' Προσπαθήστε να γράψετε μια τραγική ιστορία για τις δοκιμές σας, η οποία θα μεταφέρει σε όλους σχετικά με το τι έχει δοκιμαστεί, επαληθευτεί και τι δεν έχει γίνει.
Το παρακολούθησα θρησκευτικά όταν χρησιμοποιούσα αυτό το τεστ.
Επιτρέψτε μου να μοιραστώ τη δική μου εμπειρία:
# 1) Εργαζόμασταν σε έναν ιστότοπο και χρησιμοποιούσε αναδυόμενες διαφημίσεις βάσει των λέξεων-κλειδιών. Οι διαφημιστές έκαναν την προσφορά για συγκεκριμένες λέξεις-κλειδιά που είχαν μια οθόνη σχεδιασμένη για την ίδια. Η προεπιλεγμένη τιμή προσφοράς εμφανιζόταν ως 0,25 $, την οποία ο πλειοδότης μπορούσε να αλλάξει.
Υπήρχε ένα ακόμη μέρος όπου εμφανίστηκε αυτή η προεπιλεγμένη προσφορά και θα μπορούσε να αλλάξει και σε άλλη τιμή. Ο πελάτης ήρθε με ένα αίτημα για αλλαγή της προεπιλεγμένης τιμής από 0,25 $ σε 0,5 $, αλλά ανέφερε μόνο την προφανή οθόνη.
Κατά τη διάρκεια της συζήτησης 'brainstorming', ξεχάσαμε (;) σχετικά με αυτήν την άλλη οθόνη, επειδή δεν χρησιμοποιήθηκε πολύ για αυτόν τον σκοπό. Όμως, κατά τη δοκιμή όταν έτρεξα τη βασική περίπτωση της προσφοράς ήταν 0,5 $ και έλεγξα από άκρο σε άκρο, διαπίστωσα ότι το cronjob για το ίδιο απέτυχε επειδή σε ένα σημείο βρήκε 0,25 $.
Το ανέφερα στην ομάδα μου και κάναμε την αλλαγή και την παραδώσαμε με επιτυχία την ίδια μέρα.
#δύο) Στο ίδιο έργο (που αναφέρθηκε παραπάνω), μας ζητήθηκε να προσθέσουμε ένα μικρό πεδίο κειμένου για σημειώσεις / σχόλια για υποβολή προσφορών. Ήταν μια πολύ απλή εφαρμογή και δεσμευτήκαμε να το παραδώσουμε την ίδια μέρα.
Ως εκ τούτου, όπως αναφέρθηκε παραπάνω, δοκίμασα όλους τους επιχειρηματικούς κανόνες και χρησιμοποίησα περιπτώσεις γύρω από αυτό και όταν έκανα κάποια δοκιμή επικύρωσης, διαπίστωσα ότι όταν εισήγαγα έναν συνδυασμό ειδικών χαρακτήρων όπως, η σελίδα έπεσε.
Το σκεφτήκαμε και καταλάβαμε ότι οι πραγματικοί πλειοδότες δεν θα χρησιμοποιήσουν σε καμία περίπτωση τέτοιου είδους συνδυασμούς. Ως εκ τούτου, το κυκλοφορήσαμε με μια καλά καταρτισμένη σημείωση για το ζήτημα. Ο πελάτης το δέχτηκε ως σφάλμα αλλά συμφώνησε μαζί μας να το εφαρμόσουμε αργότερα επειδή ήταν ένα σοβαρό σφάλμα αλλά όχι ένα προηγούμενο.
# 3) Πρόσφατα, δούλευα σε ένα έργο εφαρμογής για κινητά και είχαμε την απαίτηση να ενημερώσουμε τον χρόνο παράδοσης που εμφανίζεται στην εφαρμογή σύμφωνα με τη ζώνη ώρας. Δεν ήταν μόνο να δοκιμαστεί στην εφαρμογή, αλλά και για την υπηρεσία Ιστού.
Ενώ η ομάδα ανάπτυξης εργαζόταν για την υλοποίηση, δημιούργησα τα σενάρια αυτοματοποίησης για τη δοκιμή υπηρεσίας διαδικτύου και τα σενάρια DB για αλλαγή της ζώνης ώρας του στοιχείου παράδοσης. Αυτό έσωσε τις προσπάθειές μου και θα μπορούσαμε να επιτύχουμε καλύτερα αποτελέσματα σε σύντομο χρονικό διάστημα.
Δοκιμή Sanity Vs Regression Testing
Παρακάτω αναφέρονται μερικές διαφορές μεταξύ των δύο:
Σ. Όχι. | Δοκιμή παλινδρόμησης | Δοκιμή υγιεινής |
---|---|---|
7 | Αυτή η δοκιμή έχει προγραμματιστεί μερικές φορές για εβδομάδες ή ακόμη και μήνες. | Αυτό κυμαίνεται κυρίως σε 2-3 ημέρες το πολύ. |
ένας | Ο έλεγχος παλινδρόμησης γίνεται για να επαληθευτεί ότι το πλήρες σύστημα και οι διορθώσεις σφαλμάτων λειτουργούν καλά. | Ο έλεγχος υγιεινής γίνεται τυχαία για να επαληθευτεί ότι κάθε λειτουργικότητα λειτουργεί όπως αναμένεται. |
δύο | Κάθε μικρότερο μέρος υποχωρεί σε αυτήν τη δοκιμή. | Δεν πρόκειται για προγραμματισμένη δοκιμή και γίνεται μόνο όταν υπάρχει χρονική κρίση. |
3 | Είναι μια πολύ περίπλοκη και προγραμματισμένη δοκιμή. | Δεν πρόκειται για προγραμματισμένη δοκιμή και γίνεται μόνο όταν υπάρχει χρονική κρίση. |
4 | Για αυτόν τον έλεγχο δημιουργείται μια κατάλληλα σχεδιασμένη σειρά δοκιμαστικών περιπτώσεων. | Μπορεί να μην είναι δυνατή η δημιουργία των δοκιμαστικών περιπτώσεων κάθε φορά. συνήθως δημιουργείται ένα τραχύ σύνολο δοκιμαστικών περιπτώσεων. |
5 | Αυτό περιλαμβάνει σε βάθος επαλήθευση της λειτουργικότητας, της διεπαφής χρήστη, της απόδοσης, του προγράμματος περιήγησης / δοκιμών OS κ.λπ. δηλαδή κάθε πτυχή του συστήματος έχει υποχωρήσει. | Αυτό περιλαμβάνει κυρίως την επαλήθευση των επιχειρηματικών κανόνων, τη λειτουργικότητα. |
6 | Αυτή είναι μια ευρεία και βαθιά δοκιμή. | Αυτή είναι μια ευρεία και ρηχή δοκιμή. |
Στρατηγική για δοκιμές εφαρμογών για κινητά
Πρέπει να αναρωτιέστε γιατί αναφέρομαι συγκεκριμένα στις εφαρμογές για κινητά εδώ;
Ο λόγος είναι ότι η έκδοση λειτουργικού συστήματος και προγράμματος περιήγησης για εφαρμογές ιστού ή επιτραπέζιου υπολογιστή δεν διαφέρει πολύ και ειδικά τα μεγέθη οθόνης είναι στάνταρ. Αλλά με εφαρμογές για κινητά, το μέγεθος της οθόνης, το δίκτυο κινητής τηλεφωνίας, οι εκδόσεις λειτουργικού συστήματος κ.λπ. επηρεάζουν τη σταθερότητα, την εμφάνιση και, εν συντομία, την επιτυχία της εφαρμογής σας για κινητά.
Ως εκ τούτου, μια διαμόρφωση στρατηγικής καθίσταται κρίσιμη όταν εκτελείτε αυτόν τον έλεγχο σε μια εφαρμογή για κινητά, επειδή μια αποτυχία μπορεί να σας οδηγήσει σε μεγάλο πρόβλημα. Οι δοκιμές πρέπει να γίνουν έξυπνα και με προσοχή.
Ακολουθούν ορισμένοι δείκτες που θα σας βοηθήσουν να εκτελέσετε αυτήν τη δοκιμή με επιτυχία σε μια «εφαρμογή για κινητά»:
# 1) Πρώτα απ 'όλα, αναλύστε τον αντίκτυπο της έκδοσης OS στην εφαρμογή με την ομάδα σας.
Προσπαθήστε να βρείτε απαντήσεις σε ερωτήσεις όπως, θα είναι διαφορετική η συμπεριφορά στις εκδόσεις; Η εφαρμογή θα λειτουργήσει με τη χαμηλότερη υποστηριζόμενη έκδοση ή όχι; Θα υπάρξουν προβλήματα απόδοσης για την εφαρμογή των εκδόσεων; Υπάρχει κάποιο συγκεκριμένο χαρακτηριστικό του λειτουργικού συστήματος που μπορεί να επηρεάσει τη συμπεριφορά της εφαρμογής; και τα λοιπά.
#δύο) Στην παραπάνω σημείωση, αναλύστε επίσης τα μοντέλα τηλεφώνου, δηλαδή υπάρχουν χαρακτηριστικά του τηλεφώνου που θα επηρεάσουν την εφαρμογή; Είναι η εφαρμογή αλλαγής συμπεριφοράς με GPS; Αλλάζει η συμπεριφορά εφαρμογής με την κάμερα του τηλεφώνου; κλπ. Εάν διαπιστώσετε ότι δεν υπάρχει αντίκτυπος, αποφύγετε τη δοκιμή σε διαφορετικά μοντέλα τηλεφώνου.
# 3) Εάν δεν υπάρχουν αλλαγές UI για την εφαρμογή, θα συνιστούσα να διατηρήσετε τη δοκιμή UI στην ελάχιστη προτεραιότητα, μπορείτε να ενημερώσετε την ομάδα (εάν θέλετε) ότι το UI δεν θα δοκιμαστεί.
# 4) Για να εξοικονομήσετε χρόνο, αποφύγετε τη δοκιμή σε καλά δίκτυα, διότι είναι προφανές ότι η εφαρμογή θα λειτουργήσει όπως αναμένεται σε ένα ισχυρό δίκτυο. Θα συνιστούσα να ξεκινήσετε με δοκιμές σε δίκτυο 4G ή 3G.
# 5) Αυτή η δοκιμή πρέπει να γίνει σε λιγότερο χρόνο, αλλά βεβαιωθείτε ότι κάνετε τουλάχιστον μία δοκιμή πεδίου, εκτός εάν πρόκειται για απλή αλλαγή διεπαφής χρήστη.
# 6) Εάν πρέπει να δοκιμάσετε μια μήτρα διαφορετικού λειτουργικού συστήματος και την έκδοσή τους, θα πρότεινα να το κάνετε με έξυπνο τρόπο. Για παράδειγμα, επιλέξτε τα χαμηλότερα, μεσαία και τα τελευταία ζεύγη έκδοσης OS για δοκιμή. Μπορείτε να αναφέρετε στο έγγραφο έκδοσης ότι δεν δοκιμάζεται κάθε συνδυασμός.
# 7) Σε παρόμοια γραμμή, για τη δοκιμή λογικής εφαρμογής UI, χρησιμοποιήστε μικρά, μεσαία και μεγάλα μεγέθη οθόνης για να εξοικονομήσετε χρόνο. Μπορείτε επίσης να χρησιμοποιήσετε έναν προσομοιωτή και έναν εξομοιωτή.
Προληπτικά μέτρα
Το Sanity Testing πραγματοποιείται όταν τρέχετε για λίγο χρόνο και ως εκ τούτου δεν είναι δυνατόν να εκτελέσετε κάθε δοκιμαστική θήκη και το πιο σημαντικό δεν σας έχει δοθεί αρκετός χρόνος για να σχεδιάσετε τις δοκιμές σας. Προκειμένου να αποφευχθούν τα παιχνίδια κατηγορίας, είναι καλύτερα να λάβετε προληπτικά μέτρα.
Σε τέτοιες περιπτώσεις η έλλειψη γραπτής επικοινωνίας, τεκμηρίωσης δοκιμών και απώλειας είναι πολύ συχνή.
εφαρμογή για προγραμματισμό δωρεάν αναρτήσεων στο instagram
Για να διασφαλίσετε ότι δεν θα πέσετε θύματα αυτού, βεβαιωθείτε ότι:
- Ποτέ μην αποδέχεστε μια έκδοση για δοκιμή έως ότου δεν σας δοθεί γραπτή απαίτηση που μοιράζεται ο πελάτης. Συμβαίνει ότι οι πελάτες επικοινωνούν αλλαγές ή νέες εφαρμογές προφορικά ή σε συνομιλία ή ένα απλό 1 δρομολόγιο σε ένα email και αναμένουν από εμάς να το αντιμετωπίσουμε ως απαίτηση. Αναγκάστε τον πελάτη σας να παράσχει ορισμένα βασικά σημεία λειτουργικότητας και κριτήρια αποδοχής.
- Πάντα σημειώστε τραχίες σημειώσεις των δοκιμαστικών περιπτώσεων και των σφαλμάτων σας εάν δεν έχετε αρκετό χρόνο για να τα γράψετε τακτοποιημένα. Ποτέ μην τα αφήνετε χωρίς έγγραφα. Εάν υπάρχει χρόνος, μοιραστείτε το με τον προϊστάμενό σας ή την ομάδα σας, ώστε εάν λείπει κάτι να μπορούν να το επισημάνουν εύκολα.
- Εάν εσείς και η ομάδα σας δεν έχετε χρόνο, βεβαιωθείτε ότι τα σφάλματα επισημαίνονται στην κατάλληλη κατάσταση σε ένα μήνυμα ηλεκτρονικού ταχυδρομείου; Μπορείτε να στείλετε μέσω email ολόκληρη τη λίστα σφαλμάτων στην ομάδα και να τους επισημάνετε κατάλληλα. Διατηρείτε πάντα την μπάλα στο γήπεδο του άλλου.
- Εάν έχετε Πλαίσιο αυτοματισμού έτοιμο, χρησιμοποιήστε αυτό και αποφύγετε να το κάνετε Μη αυτόματη δοκιμή , με αυτόν τον τρόπο σε λιγότερο χρόνο μπορείτε να καλύψετε περισσότερα.
- Αποφύγετε το σενάριο της 'κυκλοφορίας σε 1 ώρα' εκτός εάν είστε 100% σίγουροι ότι θα είστε σε θέση να το παραδώσετε.
- Τέλος, όπως αναφέρθηκε παραπάνω, συντάξτε ένα λεπτομερές ηλεκτρονικό ταχυδρομείο έκδοσης που θα κοινοποιεί τι έχει δοκιμαστεί, τι έχει απομείνει, λόγους, κινδύνους, ποια σφάλματα επιλύονται, τι είναι 'Latered' κ.λπ.
Ως QA, πρέπει να κρίνετε ποιο είναι το πιο σημαντικό μέρος της εφαρμογής που πρέπει να δοκιμαστεί και ποια είναι τα μέρη που μπορούν να μείνουν ή να δοκιμαστούν βασικά.
Ακόμα και σε σύντομο χρονικό διάστημα, σχεδιάστε μια στρατηγική για το πώς θέλετε να κάνετε και θα είστε σε θέση να επιτύχετε το καλύτερο στο δεδομένο χρονικό πλαίσιο.
Δοκιμή καπνού
Η δοκιμή καπνού δεν είναι διεξοδική δοκιμή, αλλά είναι μια ομάδα δοκιμών που εκτελούνται για να εξακριβωθεί εάν οι βασικές λειτουργίες της συγκεκριμένης κατασκευής λειτουργούν καλά όπως αναμενόταν ή όχι. Αυτή είναι και πρέπει πάντα να είναι η πρώτη δοκιμή που πρέπει να γίνει σε οποιαδήποτε «νέα» έκδοση.
Όταν η ομάδα ανάπτυξης κυκλοφορήσει μια έκδοση στο QA για δοκιμή, προφανώς δεν είναι δυνατό να δοκιμάσετε ολόκληρη την έκδοση και να επαληθεύσετε αμέσως εάν κάποια από τις εφαρμογές έχει σφάλματα ή εάν κάποια από τις λειτουργικές λειτουργίες έχει διακοπεί.
Υπό το πρίσμα αυτό, πώς ένα QA θα διασφαλίσει ότι οι βασικές λειτουργίες λειτουργούν καλά;
Η απάντηση σε αυτό θα είναι να εκτελέσετε ένα Δοκιμή καπνού .
Μόλις οι δοκιμές επισημανθούν ως δοκιμές καπνού (στη δοκιμαστική σουίτα) περάσουν, μόνο τότε η έκδοση γίνεται αποδεκτή από το QA για σε βάθος δοκιμές ή / και παλινδρόμηση. Εάν κάποια από τις δοκιμές καπνού αποτύχει, η έκδοση απορρίπτεται και η ομάδα ανάπτυξης πρέπει να διορθώσει το πρόβλημα και να κυκλοφορήσει μια νέα έκδοση για δοκιμή.
Θεωρητικά, η δοκιμή καπνού ορίζεται ως δοκιμή επιπέδου επιφάνειας για να πιστοποιηθεί ότι η κατασκευή που παρέχεται από την ομάδα ανάπτυξης στην ομάδα QA είναι έτοιμη για περαιτέρω δοκιμές. Αυτή η δοκιμή πραγματοποιείται επίσης από την ομάδα ανάπτυξης πριν από την κυκλοφορία του build στην ομάδα QA.
Αυτή η δοκιμή χρησιμοποιείται κανονικά στη δοκιμή ενοποίησης, στη δοκιμή συστήματος και στη δοκιμή επιπέδου αποδοχής. Ποτέ μην το αντιμετωπίζετε ως υποκατάστατο της πραγματικής ολοκλήρωσης δοκιμών από άκρο σε άκρο . Περιλαμβάνει τόσο θετικά όσο και αρνητικά τεστ ανάλογα με την υλοποίηση του build.
Παραδείγματα δοκιμής καπνού
Αυτή η δοκιμή χρησιμοποιείται συνήθως για ενοποίηση, αποδοχή και Δοκιμή συστήματος .
Στην καριέρα μου ως QA, πάντα δεχόμουν ένα build μόνο αφού είχα κάνει ένα τεστ καπνού. Ας καταλάβουμε λοιπόν τι είναι μια δοκιμή καπνού από την οπτική γωνία των τριών αυτών δοκιμών, με μερικά παραδείγματα.
# 1) Δοκιμή αποδοχής
Κάθε φορά που ένα build κυκλοφορεί στο QA, δοκιμάστε καπνό με τη μορφή Δοκιμή αποδοχής πρέπει να γίνει.
Σε αυτήν τη δοκιμή, η πρώτη και πιο σημαντική δοκιμή καπνού είναι να επαληθεύσει τη βασική αναμενόμενη λειτουργικότητα της εφαρμογής. Έτσι, θα πρέπει να επαληθεύσετε όλες τις υλοποιήσεις για τη συγκεκριμένη έκδοση.
Ας πάρουμε τα ακόλουθα παραδείγματα ως υλοποιήσεις που έγιναν σε μια κατασκευή για να κατανοήσουμε τις δοκιμές καπνού για αυτές:
- Υλοποίησε τη λειτουργία σύνδεσης για να επιτρέψει στα εγγεγραμμένα προγράμματα οδήγησης να συνδεθούν με επιτυχία.
- Υλοποίησε τη λειτουργικότητα του πίνακα ελέγχου για να δείξει τις διαδρομές που πρέπει να εκτελέσει ένα πρόγραμμα οδήγησης σήμερα.
- Υλοποίησε τη λειτουργικότητα για να εμφανίσει ένα κατάλληλο μήνυμα εάν δεν υπάρχουν διαδρομές για μια δεδομένη ημέρα.
Στην παραπάνω έκδοση, στο επίπεδο αποδοχής, η δοκιμή καπνού σημαίνει να επαληθευτεί ότι οι βασικές τρεις εφαρμογές λειτουργούν καλά. Εάν κάποιο από αυτά τα τρία είναι σπασμένο, τότε το QA θα πρέπει να απορρίψει το build.
# 2) Δοκιμή ολοκλήρωσης
Αυτή η δοκιμή πραγματοποιείται συνήθως όταν οι μεμονωμένες ενότητες εφαρμόζονται και δοκιμάζονται. Στο Δοκιμή ολοκλήρωσης επίπεδο, αυτός ο έλεγχος πραγματοποιείται για να βεβαιωθείτε ότι όλες οι βασικές λειτουργίες ολοκλήρωσης και τέλους σε λειτουργία λειτουργούν καλά όπως αναμενόταν.
Μπορεί να είναι η ενοποίηση δύο μονάδων ή όλων των ενοτήτων μαζί, επομένως η πολυπλοκότητα του τεστ καπνού θα ποικίλει ανάλογα με το επίπεδο ολοκλήρωσης.
Ας εξετάσουμε τα ακόλουθα παραδείγματα εφαρμογής ολοκλήρωσης για αυτήν τη δοκιμή:
- Εφαρμόστηκε η ενοποίηση των ενοτήτων διαδρομής και στάσεων.
- Υλοποίησε την ενοποίηση της ενημέρωσης κατάστασης άφιξης και αντικατοπτρίζει το ίδιο στην οθόνη στάσεων.
- Υλοποίησε την ολοκλήρωση της πλήρους παραλαβής μέχρι τις λειτουργικές μονάδες παράδοσης.
Σε αυτήν την έκδοση, η δοκιμή καπνού όχι μόνο θα επαληθεύσει αυτές τις τρεις βασικές υλοποιήσεις αλλά και για την τρίτη εφαρμογή, μερικές περιπτώσεις θα επαληθεύσουν και για την πλήρη ολοκλήρωση. Βοηθάει πολύ να ανακαλύψουμε τα ζητήματα που εισάγονται στην ενσωμάτωση και αυτά που δεν έγιναν απαρατήρητα από την ομάδα ανάπτυξης.
# 3) Δοκιμή συστήματος
Όπως υποδηλώνει το ίδιο το όνομα, για επίπεδο συστήματος, η δοκιμή καπνού περιλαμβάνει δοκιμές για τις πιο σημαντικές και κοινώς χρησιμοποιούμενες ροές εργασίας του συστήματος. Αυτό γίνεται μόνο αφού το πλήρες σύστημα είναι έτοιμο και δοκιμαστεί και αυτή η δοκιμή σε επίπεδο συστήματος μπορεί να αναφέρεται ως δοκιμή καπνού πριν από τη δοκιμή παλινδρόμησης.
Πριν ξεκινήσετε την παλινδρόμηση του πλήρους συστήματος, τα βασικά χαρακτηριστικά από άκρο σε άκρο δοκιμάζονται ως μέρος της δοκιμής καπνού. Η σουίτα δοκιμής καπνού για το πλήρες σύστημα αποτελείται από περιπτώσεις δοκιμής από άκρο σε άκρο που οι τελικοί χρήστες θα χρησιμοποιούν πολύ συχνά.
Αυτό γίνεται συνήθως με τη βοήθεια εργαλείων αυτοματισμού.
Σημασία στη μεθοδολογία SCRUM
Σήμερα, τα έργα ακολουθούν σχεδόν τη μεθοδολογία Waterfall στην υλοποίηση του έργου, κυρίως όλα τα έργα ακολουθούν το Agile και το ΣΚΡΩΜΑ μόνο. Σε σύγκριση με την παραδοσιακή μέθοδο καταρράκτη, το Smoke Testing κατέχει υψηλή τιμή στο SCRUM και στο Agile.
Δούλεψα για 4 χρόνια στο SCRUM . Και όπως γνωρίζουμε ότι στο SCRUM, τα σπριντ είναι μικρότερης διάρκειας και ως εκ τούτου είναι εξαιρετικά σημαντικό να γίνει αυτό το τεστ, έτσι ώστε οι αποτυχημένες κατασκευές να μπορούν να αναφερθούν αμέσως στην ομάδα ανάπτυξης και να διορθωθούν επίσης.
Παρακάτω είναι μερικά Πάρε μακριά σχετικά με τη σημασία αυτής της δοκιμής στο SCRUM:
- Από το δεκαπενθήμερο σπριντ, ο χρόνος ημιχρόνου κατανέμεται στο QA, αλλά μερικές φορές οι αυξήσεις στο QA καθυστερούν.
- Σε σπριντ, είναι καλύτερο για την ομάδα να αναφέρονται τα ζητήματα σε πρώιμο στάδιο.
- Κάθε ιστορία έχει ένα σύνολο κριτηρίων αποδοχής, επομένως ο έλεγχος των πρώτων 2-3 κριτηρίων αποδοχής ισούται με τον έλεγχο καπνού αυτής της λειτουργικότητας. Οι πελάτες απορρίπτουν την παράδοση εάν ένα κριτήριο αποτυγχάνει.
- Φανταστείτε τι θα συμβεί αν είναι 2 ημέρες που η ομάδα ανάπτυξης σας έδωσε την κατασκευή και απομένουν μόνο 3 ημέρες για την επίδειξη και συναντήσετε μια βασική αποτυχία λειτουργικότητας.
- Κατά μέσο όρο, ένα σπριντ έχει ιστορίες που κυμαίνονται από 5-10, επομένως όταν δοθεί το build είναι σημαντικό να βεβαιωθείτε ότι κάθε ιστορία εφαρμόζεται όπως αναμένεται πριν αποδεχτεί το build σε δοκιμή.
- Όταν το πλήρες σύστημα πρόκειται να δοκιμαστεί και να υποχωρήσει, ένα σπριντ είναι αφιερωμένο στη δραστηριότητα. Ένα δεκαπενθήμερο ίσως λίγο λιγότερο για να δοκιμάσετε ολόκληρο το σύστημα, επομένως είναι πολύ σημαντικό να επαληθεύσετε τις πιο βασικές λειτουργίες πριν ξεκινήσετε την παλινδρόμηση.
Δοκιμή καπνού Vs Δοκιμή αποδοχής
Το Smoke Testing σχετίζεται άμεσα με το Build Acceptance Testing (BAT).
Στο BAT, κάνουμε τον ίδιο έλεγχο - για να επαληθεύσουμε εάν το build δεν έχει αποτύχει και ότι το σύστημα λειτουργεί καλά ή όχι. Μερικές φορές, συμβαίνει ότι όταν δημιουργείται μια έκδοση, παρουσιάζονται ορισμένα ζητήματα και όταν παραδίδεται, η έκδοση δεν λειτουργεί για το QA.
Θα έλεγα ότι το BAT είναι μέρος ενός ελέγχου καπνού, επειδή εάν το σύστημα αποτυγχάνει, πώς μπορείτε ως QA να αποδεχτείτε την έκδοση για δοκιμή; Όχι μόνο οι λειτουργίες, το ίδιο το σύστημα πρέπει να λειτουργήσει πριν προχωρήσει το QA με το In-Depth Testing.
Κύκλος δοκιμής καπνού
Το παρακάτω διάγραμμα ροής εξηγεί τον Κύκλο δοκιμής καπνού.
Μόλις ένα build αναπτυχθεί σε ένα QA, ο βασικός κύκλος που ακολουθείται είναι ότι εάν περάσει ο έλεγχος καπνού, το build γίνεται αποδεκτό από την ομάδα QA για περαιτέρω δοκιμές, αλλά εάν αποτύχει, το build απορρίπτεται έως ότου επιλυθούν τα αναφερόμενα ζητήματα.
Κύκλος δοκιμής
Ποιος πρέπει να πραγματοποιήσει τη δοκιμή καπνού;
Δεν εμπλέκεται όλη η ομάδα σε αυτόν τον τύπο δοκιμών για να αποφευχθεί η σπατάλη χρόνου όλων των QA.
Το Smoke Testing εκτελείται ιδανικά από τον επικεφαλής της QA που αποφασίζει με βάση το αποτέλεσμα ως προς το αν θα περάσει το build στην ομάδα για περαιτέρω δοκιμές ή θα το απορρίψει. Ή εάν δεν υπάρχει προβάδισμα, οι ίδιοι οι QA μπορούν επίσης να πραγματοποιήσουν αυτόν τον έλεγχο.
Μερικές φορές, όταν το έργο είναι μεγάλης κλίμακας, μια ομάδα QA μπορεί επίσης να πραγματοποιήσει αυτήν τη δοκιμή για να ελέγξει για οποιοδήποτε showstoppers. Αλλά αυτό δεν συμβαίνει στην περίπτωση του SCRUM, επειδή το SCRUM είναι μια επίπεδη δομή χωρίς Leads ή Managers και κάθε δοκιμαστής έχει τις δικές του ευθύνες απέναντι στις ιστορίες τους.
Ως εκ τούτου, οι μεμονωμένοι QA εκτελούν αυτήν τη δοκιμή για τις ιστορίες που κατέχουν.
Γιατί πρέπει να αυτοματοποιήσουμε τις δοκιμές καπνού;
Αυτή η δοκιμή είναι η πρώτη δοκιμή που πρέπει να γίνει σε μια έκδοση που κυκλοφόρησε από την ομάδα ανάπτυξης. Με βάση τα αποτελέσματα αυτής της δοκιμής, γίνονται περαιτέρω δοκιμές (ή η έκδοση απορρίπτεται).
Ο καλύτερος τρόπος για να κάνετε αυτήν τη δοκιμή είναι να χρησιμοποιήσετε ένα εργαλείο αυτοματισμού και να προγραμματίσετε την εκτέλεση της σουίτας καπνού όταν δημιουργείται μια νέα έκδοση. Μπορεί να σκέφτεστε γιατί πρέπει να το κάνω 'Αυτοματοποιήστε τη σουίτα δοκιμών καπνού';
Ας δούμε την ακόλουθη περίπτωση:
Ας υποθέσουμε ότι απέχετε μια εβδομάδα από την απελευθέρωσή σας και από τις συνολικά 500 δοκιμαστικές περιπτώσεις, η σουίτα δοκιμής καπνού αποτελείται από 80-90. Εάν αρχίσετε να εκτελείτε χειροκίνητα όλες αυτές τις δοκιμαστικές περιπτώσεις 80-90, φανταστείτε πόσο χρόνο θα χρειαστείτε; Νομίζω 4-5 ημέρες (ελάχιστο).
Αλλά αν χρησιμοποιείτε αυτοματοποίηση και δημιουργείτε σενάρια για να εκτελέσετε όλες αυτές τις δοκιμαστικές περιπτώσεις 80-90 τότε ιδανικά, αυτές θα εκτελούνται σε 2-3 ώρες και θα έχετε τα αποτελέσματα μαζί σας αμέσως. Δεν σας έσωσε τον πολύτιμο χρόνο σας και σας έδωσε τα αποτελέσματα σχετικά με το ενσωματωμένο πολύ λιγότερο χρόνο;
5 χρόνια πίσω, δοκίμασα μια εφαρμογή οικονομικής προβολής, η οποία έλαβε πληροφορίες σχετικά με τον μισθό σας, τις αποταμιεύσεις σας κ.λπ. και προέβλεψα τους φόρους, τις αποταμιεύσεις, τα κέρδη σας ανάλογα με τους οικονομικούς κανόνες. Μαζί με αυτό, είχαμε προσαρμογή για χώρες που εξαρτώνται από τη χώρα και οι φορολογικοί κανόνες της χρησιμοποιούνται για αλλαγή (στον κώδικα).
Για αυτό το έργο, είχα 800 περιπτώσεις δοκιμών και 250 περιπτώσεις δοκιμής καπνού. Με τη χρήση του Σεληνίου, θα μπορούσαμε εύκολα να αυτοματοποιήσουμε και να πάρουμε τα αποτελέσματα αυτών των 250 δοκιμαστικών περιπτώσεων σε 3-4 ώρες. Δεν έσωσε μόνο το χρόνο μας, αλλά μας έδειξε το συντομότερο δυνατόν για τους θεατές.
Ως εκ τούτου, εκτός εάν είναι αδύνατο να αυτοματοποιηθεί, λάβετε τη βοήθεια του αυτοματισμού για αυτόν τον έλεγχο.
Πλεονεκτήματα και μειονεκτήματα
Ας ρίξουμε πρώτα μια ματιά στα πλεονεκτήματα, καθώς έχει πολλά να προσφέρει σε σύγκριση με τα λίγα μειονεκτήματά του.
Πλεονεκτήματα:
- Εύκολη εκτέλεση.
- Μειώνει τον κίνδυνο.
- Τα ελαττώματα εντοπίζονται σε πολύ πρώιμο στάδιο.
- Εξοικονομεί προσπάθειες, χρόνο και χρήμα.
- Τρέχει γρήγορα εάν αυτοματοποιηθεί.
- Λιγότεροι κίνδυνοι και ζητήματα ενσωμάτωσης.
- Βελτιώνει τη συνολική ποιότητα του συστήματος.
Μειονεκτήματα:
- Αυτή η δοκιμή δεν είναι ίση ή υποκατάστατη πλήρους λειτουργικής δοκιμής.
- Ακόμα και αφού περάσει η δοκιμή καπνού, ενδέχεται να βρείτε σφάλματα.
- Αυτός ο τύπος δοκιμών είναι ο καλύτερος κατάλληλος εάν μπορείτε να αυτοματοποιήσετε αλλιώς αφιερώνεται πολύς χρόνος για τη μη αυτόματη εκτέλεση των δοκιμαστικών περιπτώσεων, ειδικά σε έργα μεγάλης κλίμακας που έχουν περίπου 700-800 δοκιμαστικές θήκες.
Ο έλεγχος καπνού πρέπει σίγουρα να γίνεται σε κάθε έκδοση καθώς επισημαίνει τις μεγάλες αποτυχίες και τους θεατές σε πολύ πρώιμο στάδιο. Αυτό ισχύει όχι μόνο για νέες λειτουργίες, αλλά και για την ενσωμάτωση ενοτήτων, την επίλυση θεμάτων και τον αυτοσχεδιασμό. Είναι μια πολύ απλή διαδικασία για να εκτελέσετε και να λάβετε το σωστό αποτέλεσμα.
Αυτή η δοκιμή μπορεί να θεωρηθεί ως σημείο εισόδου για πλήρη λειτουργική δοκιμή λειτουργικότητας ή συστήματος (στο σύνολό της). Αλλά πριν από αυτό, η ομάδα QA θα πρέπει να είναι πολύ σαφής σχετικά με το ποιες δοκιμές πρέπει να γίνουν ως δοκιμές καπνού . Αυτή η δοκιμή μπορεί να ελαχιστοποιήσει τις προσπάθειες, να εξοικονομήσει χρόνο και να βελτιώσει την ποιότητα του συστήματος. Κατέχει μια πολύ σημαντική θέση στα σπριντ, καθώς ο χρόνος στα σπριντ είναι λιγότερο.
Αυτή η δοκιμή μπορεί να γίνει τόσο χειροκίνητα όσο και με τη βοήθεια εργαλείων αυτοματισμού. Αλλά ο καλύτερος και προτιμώμενος τρόπος είναι να χρησιμοποιήσετε εργαλεία αυτοματισμού για να εξοικονομήσετε χρόνο.
Διαφορά μεταξύ δοκιμών καπνού και λογικής
Τις περισσότερες φορές συγχέουμε μεταξύ της έννοιας του Sanity Testing και του Smoke Testing. Πρώτα απ 'όλα, αυτές οι δύο δοκιμές είναι τρόπος ' διαφορετικός »Και εκτελέστηκε σε διαφορετικά στάδια ενός κύκλου δοκιμών.
Σ. Όχι. | Δοκιμή καπνού | Δοκιμή υγιεινής |
---|---|---|
ένας | Δοκιμή καπνού σημαίνει να επαληθεύσετε (βασικά) ότι οι υλοποιήσεις που γίνονται σε μια κατασκευή λειτουργούν καλά. | Το Sanity testing σημαίνει ότι οι λειτουργίες που προστέθηκαν πρόσφατα, σφάλματα κ.λπ. λειτουργούν καλά. |
δύο | Αυτή είναι η πρώτη δοκιμή στην αρχική έκδοση. | Έγινε όταν η κατασκευή είναι σχετικά σταθερή. |
3 | Έγινε σε κάθε έκδοση. | Έγινε σε σταθερές εκδόσεις μετά την παλινδρόμηση. |
Ακολουθεί μια διαγραμματική αναπαράσταση των διαφορών τους:
ΔΟΚΙΜΗ ΚΑΠΝΟΥ
- Αυτή η δοκιμή προήλθε από το σκεύη, εξαρτήματα δοκιμάστε την πρακτική της ενεργοποίησης ενός νέου υλικού για πρώτη φορά και θεωρώντας την επιτυχία εάν δεν πάρει φωτιά και καπνό. Στον κλάδο του λογισμικού, αυτή η δοκιμή είναι μια ρηχή και ευρεία προσέγγιση σύμφωνα με την οποία δοκιμάζονται όλοι οι τομείς της εφαρμογής χωρίς να μπουν σε πολύ βαθιά.
- Ένα τεστ καπνού είναι σενάριο, είτε χρησιμοποιώντας ένα γραπτό σύνολο δοκιμών είτε ένα αυτοματοποιημένο τεστ
- Μια δοκιμή καπνού έχει σχεδιαστεί για να αγγίζει κάθε μέρος της εφαρμογής με έναν συντομότερο τρόπο. Είναι ρηχό και φαρδύ.
- Αυτή η δοκιμή διεξάγεται για να διασφαλιστεί εάν λειτουργούν οι πιο κρίσιμες λειτουργίες ενός προγράμματος, αλλά δεν ενοχλούνται με τις λεπτότερες λεπτομέρειες. (Όπως η επαλήθευση έκδοσης).
- Αυτός ο έλεγχος είναι ένας φυσιολογικός έλεγχος υγείας για τη δημιουργία μιας εφαρμογής, προτού την δοκιμάσετε σε βάθος.
ΔΟΚΙΜΗ SANITY
- Το τεστ λογικής είναι ένα τεστ στενής παλινδρόμησης που επικεντρώνεται σε έναν ή λίγους τομείς λειτουργικότητας. Το Sanity Testing είναι συνήθως στενό και βαθύ.
- Αυτή η δοκιμή είναι συνήθως χωρίς εγγραφή.
- Αυτή η δοκιμή χρησιμοποιείται για να προσδιοριστεί ότι ένα μικρό τμήμα της εφαρμογής εξακολουθεί να λειτουργεί μετά από μια μικρή αλλαγή.
- Αυτή η δοκιμή είναι δοκιμή με κέρσορα, πραγματοποιείται κάθε φορά που μια δοκιμασία δείκτη είναι επαρκής για να αποδείξει ότι η εφαρμογή λειτουργεί σύμφωνα με τις προδιαγραφές. Αυτό το επίπεδο δοκιμών είναι ένα υποσύνολο των δοκιμών παλινδρόμησης.
- Αυτό γίνεται για να επιβεβαιωθεί εάν πληρούνται οι απαιτήσεις ή όχι, ελέγχοντας πρώτα όλες τις δυνατότητες.
Ελπίζω να είστε ξεκάθαροι για τις διαφορές μεταξύ αυτών των δύο τεράστιων και σημαντικών τύπων δοκιμών λογισμικού. Μη διστάσετε να μοιραστείτε τις σκέψεις σας στην παρακάτω ενότητα σχολίων !!
Συνιστώμενη ανάγνωση
- Τα καλύτερα εργαλεία δοκιμής λογισμικού 2021 [QA Test Automation Tools]
- Διαφορά μεταξύ Desktop, Client Server Testing και Web Testing
- Λειτουργική δοκιμή εναντίον μη λειτουργική δοκιμή
- Testing Primer eBook Λήψη
- Δοκιμή άλφα και δοκιμή beta (Ένας πλήρης οδηγός)
- Οδηγός δοκιμής φορητότητας με πρακτικά παραδείγματα
- Τύποι δοκιμών λογισμικού: Διαφορετικοί τύποι δοκιμών με λεπτομέρειες
- Λειτουργική δοκιμή έναντι δοκιμής απόδοσης: Πρέπει να γίνει ταυτόχρονα;