Πώς να γράψετε τεκμηρίωση QA που θα λειτουργήσει πραγματικά

Ένα προϊόν λογισμικού είναι σαν ένα αεροπλάνο: πρέπει να υποβληθεί σε τεχνικό έλεγχο πριν από την εκτόξευσή του.

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

Υπάρχουν τόσοι πολλοί τύποι δοκιμών λογισμικού - αυτοματοποιημένοι και χειροκίνητοι, διερευνητικοί και λειτουργικοί, συμβατότητα, UI / UX, παλινδρόμηση, μονάδα, API και δοκιμές απόδοσης. Καλή τύχη τυλίγοντας το κεφάλι σας σε όλα αυτά!

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

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

Δημιουργήστε ένα δοκιμαστικό σχέδιο και μια έκθεση προόδου δοκιμής

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

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

Το σχέδιο δοκιμών θα σας βοηθήσει να κατανοήσετε τα εξής:

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

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

Σχέδιο δοκιμής & αναφορά

Δημιουργία δοκιμαστικών περιπτώσεων

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

Οι δοκιμαστικές περιπτώσεις είναι αρκετά απλές - αυτή η τεκμηρίωση QA αποτελείται από 7 ενότητες: Αναγνωριστικό, Περίπτωση δοκιμής, Βήματα δοκιμών, Αναμενόμενο αποτέλεσμα, Κατάσταση, Πραγματικό αποτέλεσμα και Σχόλια.

  1. Το αναγνωριστικό είναι ένας μοναδικός αριθμός που εκχωρείται στη δοκιμαστική σας υπόθεση.
  2. Στην ενότητα Test Case , επισημαίνετε τις απαιτήσεις που θα δοκιμάσετε και θα παρέχετε έναν σύνδεσμο σε αυτό στο έγγραφο προδιαγραφών.
  3. Στην ενότητα Βήματα δοκιμών , παρατίθενται όλες οι ενέργειες που απαιτούνται για την ολοκλήρωση μιας δοκιμαστικής περίπτωσης.
  4. Στην ενότητα Αναμενόμενα αποτελέσματα , συνοψίζετε το αποτέλεσμα μιας συγκεκριμένης δοκιμής εάν είναι επιτυχής.
  5. Στην ενότητα Κατάσταση , υποδεικνύετε εάν ένα συγκεκριμένο βήμα πέρασε ή απέτυχε να ελέγξει
  6. Στην ενότητα Πραγματικό αποτέλεσμα , εξηγείτε το αποτέλεσμα μιας αποτυχημένης δοκιμής.
  7. Η ενότητα Σχόλια δεν είναι υποχρεωτική, αλλά μπορείτε να την προσθέσετε για να αφήσετε μερικές επιπλέον σημειώσεις.
Θήκη δοκιμής

Συντάξτε μια αναφορά ελαττωμάτων

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

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

Αναφορά ελαττωμάτων

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

  1. Σε κάθε συγκεκριμένο ζήτημα λογισμικού εκχωρείται ένας μοναδικός αριθμός - το αναγνωριστικό . Βελτιστοποιεί την πλοήγηση μέσω εγγράφων QA και διευκολύνει την επικοινωνία μεταξύ προγραμματιστών, υπεύθυνων δοκιμών και PM.
  2. Στην ενότητα περίληψης , παρέχετε μια συνοπτική απάντηση σε τρεις απλές ερωτήσεις: τι συνέβη, πού και υπό ποιες συνθήκες.
  3. Στην ενότητα περιγραφής , περιγράφετε λεπτομερώς το σφάλμα. Πρέπει να πείτε για τα πραγματικά αποτελέσματα και τα αναμενόμενα. Είναι χρήσιμο να παρέχετε έναν σύνδεσμο για τις απαιτήσεις λογισμικού σας.
  4. Στη συνέχεια, γράφετε για τα βήματα αναπαραγωγής (STR) . Αυτό δείχνει στους προγραμματιστές ακριβώς πώς να αναπαραγάγουν το ζήτημα. Μην χάσετε ένα βήμα, διαφορετικά η αναφορά σας ενδέχεται να σας επιστρέψει.
  5. Στην ενότητα αναπαραγωγιμότητας , διευκρινίζετε εάν το σφάλμα εμφανίζεται κάθε φορά που ακολουθείτε το STR. Θα πρέπει να χρησιμοποιήσετε αριθμούς για να δείξετε κατά προσέγγιση πιθανότητες, για παράδειγμα 7 φορές στα 10.
  6. Στην ενότητα σοβαρότητας , εξηγείτε πόση βλάβη μπορεί να προκαλέσει το σφάλμα στο έργο. Με άλλα λόγια, δείχνει τον τεχνολογικό βαθμό επιρροής του ελαττώματος σε ολόκληρο το σύστημα. Ακόμη και ένα μικρό ζήτημα μπορεί να επηρεάσει άσχημα ολόκληρη την εφαρμογή.
  7. Η προτεραιότητα δείχνει πόσο σημαντική είναι μια συγκεκριμένη αναφορά ελαττωμάτων. Η προτεραιότητα μπορεί να δηλωθεί με τη βοήθεια των γραμμάτων - "A" για το πιο επείγον και "Z" για το λιγότερο επείγον, αριθμοί - "1" για το πιο επείγον και "9" για το λιγότερο επείγον, ή απλά λέξεις όπως "υψηλή "," Μεσαίο "ή" χαμηλό ".
  8. Στην ενότητα περιβάλλοντος , πρέπει να ορίσετε ποια λειτουργικά συστήματα ή εκδόσεις προγράμματος περιήγησης επηρεάστηκαν.
  9. Τέλος, τα συνημμένα περιλαμβάνουν τη λίστα βίντεο, στιγμιότυπων οθόνης ή αρχείων καταγραφής κονσόλας που προστέθηκαν στην αναφορά ελαττωμάτων.

Διατηρήστε αυτές τις χρήσιμες συμβουλές για τη σύνταξη αναφοράς ελαττωμάτων

  1. Γράψτε μια επαρκή και επαρκή περίληψη. Δεν έχει σημασία αν είναι μακρύ ή μικρό. Αυτό που έχει σημασία είναι ότι πρέπει να είναι σαφές.
  2. Ρίξτε μια ματιά στη σύνοψη και την περιγραφή. Φαίνονται σχεδόν το ίδιο; Πρέπει να έχετε ξεχάσει να περιγράψετε τα αναμενόμενα και πραγματικά αποτελέσματα στην περιγραφή και να προσθέσετε τον σύνδεσμο στις απαιτήσεις.
  3. Καταγράψτε το πρόβλημα με τη βοήθεια ενός στιγμιότυπου οθόνης. Μπορεί να σας σώσει και την ομάδα ανάπτυξης πολύ χρόνο. Μερικές φορές, μια ματιά στην εικόνα αρκεί για να κατανοήσουμε την κατάσταση.
  4. Πριν αναφέρετε το ζήτημα, προσπαθήστε να το αναπαραγάγετε τουλάχιστον 3 φορές για να βεβαιωθείτε ότι υπάρχει.
  5. Αναφέρετε το ζήτημα το συντομότερο δυνατόν και ενημερώστε τον διαχειριστή του έργου σας ή τον κάτοχο του προϊόντος εάν το πρόβλημα είναι σημαντικό.
  6. Ελέγξτε για γραμματικά λάθη στην τεκμηρίωσή σας QA, ώστε να μην σας καταργηθούν από την αστυνομία γραμματικής.
  7. Όσο κωμικό κι αν ακούγεται, βεβαιωθείτε ότι το πρόβλημα δεν είναι χαρακτηριστικό - ελέγξτε ξανά την τεκμηρίωση!
  8. Μην χάσετε σημαντικές πληροφορίες στα βήματα αναπαραγωγής σας.

Υποβάλετε μια αναφορά ελαττωμάτων

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

Κύκλος ζωής αναφοράς ελαττωμάτων

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

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

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

Για να ολοκληρώσετε

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

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

Χρειάζεται να βελτιώσετε την ποιότητα του λογισμικού σας;

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

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

ΥΣΤΕΡΟΓΡΑΦΟ

Το αρχικό άρθρο που δημοσιεύτηκε στο KeenEthics blog βρίσκεται εδώ: Πώς να γράψετε τεκμηρίωση QA που θα λειτουργήσει;