Αποτελεσματικές βέλτιστες πρακτικές QA

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

Υπήρξαν πολλές δύσκολες περιπτώσεις στη διαδικασία διασφάλισης της ποιότητας, στις δοκιμές, στη διαχείριση και στην ανάπτυξη και τώρα αισθάνεται πως η ομάδα μας πέρασε Per Aspera ad Astra.

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

Κατανοήστε τους επιχειρηματικούς στόχους και καθιστά σαφή τα κριτήρια αποδοχής

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

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

CI / CD - Συνεχής ενσωμάτωση / Συνεχής ανάπτυξη

Ακούγεται οικείο ... Δεν είναι; Ένα από τα κυρίαρχα πράγματα στην τρέχουσα ανάπτυξη λογισμικού το κύριο πλεονέκτημα του οποίου από την άποψη της ομάδας QA είναι ότι μπορούμε εύκολα να αποκτήσουμε ένα build με τα τελευταία χαρακτηριστικά ή διορθώσεις.

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

Δοκιμάσαμε την TeamCity και την Jenkins. Και τα δύο είναι εξαιρετικά εργαλεία. Το TeamCity έχει πιο όμορφο UI, αλλά ο Jenkins είναι απολύτως ελεύθερος, έτσι επιλέξαμε τον Jenkins.

Υπηρεσίες διανομής εφαρμογών

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

Για κινητά έργα, δοκιμάσαμε μερικές διαφορετικές υπηρεσίες όπως HockeyApp, Beta από ύφασμα (πρώην Crashlytics), Test Flight από την Apple, Play Console από την Google. Φυσικά, υπάρχουν περισσότερες υπηρεσίες, αλλά αυτές έχουν επιλεγεί ως οι πιο δημοφιλείς. Τώρα ψηφίζω για την δοκιμαστική πτήση και την κονσόλα παιχνιδιών επειδή αυτές οι υπηρεσίες είναι ευέλικτες, υποστηρίζουν λειτουργίες εσωτερικών και εξωτερικών δοκιμαστών και επίσημες υπηρεσίες από την Apple και την Google και από email μόνο οι δοκιμαστές. Ο μόνος περιορισμός εδώ είναι ότι χρειάζεστε λογαριασμό Apple και Google για προγραμματιστές που κοστίζουν 25 $ για το Google (εφάπαξ πληρωμή) και 99 $ για την Apple (ετησίως).

Άλλες υπηρεσίες όπως το HockeyApp ή το Beta έχουν κάποιες δυσκολίες με την προσθήκη νέων δοκιμαστών στο πρόγραμμα, ειδικά στο iOS. Λόγω της ασφάλειας της Apple, από τους δοκιμαστές, απαιτείται να παράσχει UDID των συσκευών τους στον προγραμματιστή και ο προγραμματιστής πρέπει να προσθέσει αυτά τα UDIDs στο έργο. Δεδομένου ότι μοιραζόμαστε το dev builds με τους πελάτες μας (οι οποίοι συνήθως έχουν πολλές διαφορετικές συσκευές και τους αλλάζουν τακτικά) όλοι μας έχουμε κουραστεί από αυτές τις δραστηριότητες συλλογής UDID. Αυτός είναι ο λόγος για τον οποίο επιλέξαμε την Test Flight and Play Console.

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

Έλεγχος τεκμηρίωσης

Μέσα από αυτά τα χρόνια η ομάδα QA βρήκε τέσσερα πολύτιμα έγγραφα που μπορούν να μοιραστούν με πελάτες ή ενδιαφερόμενους:

  • Υποστηριζόμενες πλατφόρμες
  • Σχέδιο δοκιμών
  • Δοκιμαστικές περιπτώσεις / λίστες ελέγχου
  • Σημειώσεις έκδοσης

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

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

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

Οι περιπτώσεις δοκιμών / οι λίστες ελέγχου είναι απαραίτητο για κάθε έργο. Φυσικά, χρειάζονται αρκετό χρόνο για την προετοιμασία αυτών των παραδοτέων και μπορεί να χρειαστεί πρόσθετος χρόνος για την υποστήριξη αυτής της τεκμηρίωσης, αλλά σας δίνει κάποιο είδος κορμού δέντρου και χρησιμοποιώντας αυτόν τον κορμό μπορείτε εύκολα να φανταστείτε και να δημιουργήσετε νέα σενάρια δοκιμών μόνο με την προσθήκη υποκαταστημάτων τον κορμό σας. Αργότερα, μπορείτε να μοιραστείτε τις προετοιμασμένες δοκιμαστικές περιπτώσεις με την ομάδα UAT από την πλευρά του πελάτη ή με beta testers ή ακόμη και να δείξετε περιπτώσεις δοκιμών στην ομάδα ανάπτυξης του έργου. Η ομάδα Dev μπορεί να χρησιμοποιήσει τις δοκιμαστικές περιπτώσεις ως μέρος των απαιτήσεων και πραγματικά μπορεί να τους βοηθήσει να αποφύγουν κάποια ζητήματα.

Στο Effective δοκιμάσαμε πολλά TMS (Test Management System) και επιλέξαμε το TestRail ως ένα από τα πιο δημοφιλή, προσαρμόσιμα, γρήγορα και βολικά εργαλεία για τη διαχείριση των δοκιμαστικών περιπτώσεων και τη διαχείριση των δοκιμών. Η χρήση του TestRail μας επιτρέπει να κρατάμε εύκολα τις δοκιμαστικές περιπτώσεις και τους καταλόγους ελέγχου ενημερωμένους. Για εμάς, αυτό το εργαλείο είναι εξαιρετικό, αλλά υπάρχουν ακόμα πολλές εναλλακτικές λύσεις. Η βασική συμβουλή εδώ είναι να χρησιμοποιήσετε το σωστό TMS και να μην χρησιμοποιήσετε τα Έγγραφα και τα Φύλλα Google για δοκιμαστικές περιπτώσεις και αρχεία καταγραφής δοκιμών :)

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

Διερευνητικές δοκιμές

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

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

Αποτελεσματική συνοπτική παρουσίαση των βέλτιστων πρακτικών του QA:

  • Κατανοήστε τους Επιχειρηματικούς Στόχους
  • Κάνετε τα κριτήρια αποδοχής σαφή
  • Γνωρίστε τις υποστηριζόμενες πλατφόρμες σας
  • Προετοιμασία σχεδίου δοκιμών
  • Χρησιμοποιήστε τις υποθέσεις δοκιμών / τους καταλόγους ελέγχου
  • Χρησιμοποιήστε συνεχή ενσωμάτωση + Συνεχής ανάπτυξη
  • Διατηρήστε ενημερωμένες τις υποθέσεις δοκιμών / τους καταλόγους ελέγχου
  • Μοιραστείτε τις σημειώσεις έκδοσης με τους πελάτες σας
  • Ποτέ μην ξεχνάτε την Διερευνητική Δοκιμή

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