Μενού

Οδηγός τεκμηρίωσης δοκιμών λογισμικού (Γιατί είναι σημαντικό)

software testing documentation guide

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

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

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

Οδηγός τεκμηρίωσης δοκιμών λογισμικού (Γιατί

Τι θα μάθετε:

Η εμπειρία μου

Απλώς θέλω να μοιραστώ την εμπειρία μου μαζί σας:

αριστερός σύνδεσμος έναντι αριστερός εξωτερικός σύνδεσμος

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

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

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

«Το μελάνι είναι καλύτερο από την καλύτερη μνήμη» - κινεζική παροιμία

Τεκμηρίωση δοκιμής: Τι είναι αυτό;

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

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

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

Το γεγονός είναι ότι Η προσεκτική τεκμηρίωση μπορεί να εξοικονομήσει χρόνο, προσπάθειες και χρήματα από έναν οργανισμό.

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

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

Όταν άρχισα να εργάζομαι, ζήτησα κάποια έγγραφα βοήθειας στον Διευθυντή και πήρα την απάντηση 'Όχι, δεν έχουμε έγγραφα' Στη συνέχεια, έκανα ένα ζήτημα γιατί επειδή ως QA ήξερα, κανείς δεν μπορεί να καταλάβει πώς να χρησιμοποιήστε το προϊόν χωρίς έγγραφα ή εκπαίδευση. Και αν ο χρήστης δεν είναι ικανοποιημένος, πώς θα βγάλουμε χρήματα από αυτό το προϊόν;

«Η έλλειψη τεκμηρίωσης γίνεται πρόβλημα αποδοχής» - Wietse Venema

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

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

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

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

Ας οργανώσουμε όλες τις συζητήσεις σε λίγα σημεία σε ποιοτική άποψη:

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

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

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

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

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

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

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

καλύτεροι δωρεάν ιστότοποι λήψης μουσικής για τηλέφωνα Android

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

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

# 1) Το QA πρέπει να εμπλέκεται στην πρώτη φάση του έργου έτσι ώστε το QA και η Τεκμηρίωση να λειτουργούν μαζί.

#δύο) Η διαδικασία που καθορίζεται από το QA πρέπει να ακολουθεί τεχνικά άτομα, αυτό βοηθά στην απομάκρυνση των περισσότερων ελαττωμάτων σε πολύ αρχικό στάδιο.

# 3) Δημιουργία και συντήρηση μόνο Πρότυπα δοκιμών λογισμικού δεν είναι αρκετό, αναγκάστε τους ανθρώπους να τα χρησιμοποιήσουν.

# 4) Μην δημιουργείτε και αφήνετε μόνο το έγγραφο, ενημερώστε όπως και όταν απαιτείται.

# 5) Η απαίτηση αλλαγής είναι μια σημαντική φάση του έργου. Μην ξεχάσετε να τα προσθέσετε στη λίστα.

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

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

# 8) Προσπαθήστε να τεκμηριώσετε τι απαιτείται για να κατανοήσετε τη δουλειά σας και τι θα πρέπει να παράγετε στους ενδιαφερόμενους σας όποτε απαιτείται.

# 9) Χρησιμοποιήστε το πρότυπο πρότυπο για τεκμηρίωση. Όπως οποιοδήποτε πρότυπο φύλλου excel ή πρότυπο αρχείου doc και κολλήστε σε αυτό για όλες τις ανάγκες του εγγράφου σας.

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

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

Σε τελική ανάλυση «η τεκμηρίωση χρειάζεται τεκμηρίωση». Δεν είναι;

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

Σημαντικά έγγραφα δοκιμής λογισμικού

Εδώ παραθέτω μερικά σημαντικά έγγραφα δοκιμών λογισμικού που πρέπει να χρησιμοποιούμε / συντηρούμε τακτικά:

1) Σχέδιο δοκιμής
2) Σχεδιασμός δοκιμών και Προδιαγραφή δοκιμής
3) Στρατηγική δοκιμών
4) Συνοπτικές εκθέσεις δοκιμών
5) Εβδομαδιαία αναφορά κατάστασης
6) Έγγραφα / Εγχειρίδια χρήστη
7) Αναφορά αποδοχής χρήστη
8) Εκτίμηση κινδύνου
9) Μητρώο δοκιμών
10) Αναφορές σφαλμάτων
έντεκα) Δεδομένα δοκιμής
12) Ανάλυση δοκιμής

Επίσης, οι υπεύθυνοι δοκιμής λογισμικού πρέπει να αναφέρονται τακτικά στα ακόλουθα έγγραφα:
1) Προδιαγραφές Απαιτήσεων Λογισμικού
2) Λειτουργικά έγγραφα

συμπέρασμα

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

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

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

Σχετικά με τον συγγραφέα: Αυτό το άρθρο γράφτηκε από μέλος της ομάδας STH Tejaswini. Εργάζεται ως διευθυντής QA σε έναν οργανισμό.

Ποια άλλα έγγραφα διατηρείτε στις καθημερινές σας δραστηριότητες δοκιμών;

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

^