Μενού

Υπάρχει όριο έναρξης και διακοπής στο ρόλο του QA στο Scrum;

is there any start stop boundary qa s role scrum

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

Τι είναι ο ρόλος της QA στο Scrum: Δραστηριότητες Scrum για τους δοκιμαστές

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

Το προηγούμενο CTO μου το έλεγε πάντα «Με την ελευθερία έρχεται ευθύνη». Εάν σας δοθεί η ελευθερία να κάνετε τη δουλειά σας με τον τρόπο σας, τότε εσείς και μόνο εσείς είστε υπεύθυνοι για την εργασία ή τις εργασίες ή τις δραστηριότητές σας.

Αυτό είναι το Scrum !! Επιτρέψτε μου να σας δώσω μια βασική ιδέα για το Scrum καθώς προχωράμε περαιτέρω.

QA ρόλος στο scrum

Τι θα μάθετε:

Επισκόπηση του Scrum

Το Scrum είναι ένα υποσύνολο του ευέλικτη μεθοδολογία και είναι ένα ελαφρύ πλαίσιο διαδικασίας που χρησιμοποιείται ευρέως.

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

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

Αλλά η μεγαλύτερη πρόκληση για ένα QA είναι ότι η διάρκεια κυκλοφορίας είναι σύντομη, το Sprint είναι κυρίως κύκλος 15 ημερών. Ως εκ τούτου, η παράδοση ενός προϊόντος «δωρεάν» σφαλμάτων το πολύ σε 4-5 ημέρες (αφαιρώντας τον χρόνο ανάπτυξης) χρειάζεται πολλές προσπάθειες και έξυπνη σκέψη.

Είμαι το QA της ομάδας μου:

Scrum

Ω Ναι, είμαι το QA της ομάδας μου και είμαι σημαντικός παίκτης της ομάδας μου. Γιατί?? Επειδή οι πελάτες, οι BA, το Scrum Master και όλοι οι άλλοι είναι ασαφής για την ποιότητα, την εμφάνιση και την αίσθηση και την απόδοση της εφαρμογής ή του προϊόντος.

Στο Scrum, καθώς η διάρκεια του σπριντ είναι μικρή, το QA πρέπει να αποδίδει με έξυπνο τρόπο και ως εκ τούτου η ανάγκη από το QA να συμμετέχει από την αρχή ο «Σχεδιασμός» καθίσταται πολύ σημαντικός. Υπάρχουν στιγμές που ένα QA μπορεί να παίξει το ρόλο ενός ιδιοκτήτη προϊόντος μεσολάβησης όταν το PO δεν είναι διαθέσιμο, βοηθώντας έτσι το BA να δημιουργήσει τα σενάρια δοκιμής κριτηρίων αποδοχής.

Οι προγραμματιστές προσεγγίζουν επίσης το QA σε περιόδους που αντιμετωπίζουν προβλήματα με τη λειτουργικότητα ή τους επιχειρηματικούς κανόνες. Στο Scrum, το επίκεντρο είναι μόνο η ομαλή και επιτυχημένη κυκλοφορία του Sprint και δεν αφορά το «Η δουλειά μου» ή το «Η δουλειά σας» να σας βοηθήσει όταν η ομάδα σας σας πλησιάσει για βοήθεια.

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

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

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

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

Δραστηριότητες που πρέπει να ακολουθηθούν

Παρακάτω αναφέρονται μερικές δραστηριότητες που θα σας πρότεινα να ακολουθήσετε ως QA στο Scrum.

τι εργαλεία χρησιμοποιούν οι επιχειρηματικοί αναλυτές

# 1) Πιο βαθιά:

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

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

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

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

# 2) Συμμετοχή σε εκτιμήσεις:

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

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

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

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

# 3) Σύζευξη Dev QA:

Στην ιδανική περίπτωση, στο Scrum, οι Ιστορίες χρηστών Sprint παραδίδονται για δοκιμή μετά την ολοκλήρωση της ανάπτυξης και μόλις ολοκληρωθεί η δοκιμή dev, αλλά το πρόβλημα εδώ είναι ότι τη στιγμή που θα παραδοθεί στο QA για δοκιμές μόλις 4-5 ημέρες στο Demo ή η κριτική παραμένει.

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

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

Τα ακόλουθα κριτήρια μπορούν να ληφθούν υπόψη για να κάνετε BVT στη ρύθμιση dev για τις ιστορίες των χρηστών:

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

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

Σύζευξη Dev QA

# 4) QA στο λευκό πίνακα:

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

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

Προτιμώ απλώς να δείξω το άτομο στο Scrum Board και να το αφήσω να το κάνουν μόνοι τους. Προτιμήστε ένα φωτεινό εξαιρετικό χρώμα για τα QA Sticky slip.

QA στο λευκό πίνακα

# 5) Τεκμηρίωση:

Αυτό είναι ένα από τα μειονεκτήματα ή τα μειονεκτήματα του Scrum ότι λόγω του μικρού μεγέθους του Sprint δεν υπάρχει πολύς χρόνος για τεκμηρίωση και δεν έχω δει ποτέ έναν τεχνικό συγγραφέα σε μια ομάδα του Scrum. Το Scrum Master / BA δεν μπορεί και δεν ενημερώνει πάντα τα έγγραφα σχετικά με τις πληροφορίες του προϊόντος.

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

Η λύση είναι να δημιουργηθεί μια ξεχωριστή εργασία σε ένα σπριντ όποτε είναι δυνατόν (κυρίως σε χαλαρούς χρόνους ή όταν ο φόρτος εργασίας είναι πολύ μικρότερος) για τεκμηρίωση, ώστε να μπορείτε να αναθεωρήσετε τα έγγραφα και να ενημερώσετε ή να ενημερώσετε το Scrum Master ή το BA.

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

# 6) Sprint Review / Sprint Demo:

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

Ένα QA μπορεί να επιδείξει από την επιχειρηματική άποψη, επειδή γνωρίζουν τις λειτουργίες, τις ροές και τους επιχειρηματικούς κανόνες. Προετοιμαστείτε καλά για το demo και προσπαθήστε να απαντήσετε σε κάθε ερώτηση που έχει η PO και τα ενδιαφερόμενα μέρη. Αυτό θα σας βοηθήσει να γίνετε το σημείο επαφής για αυτούς απουσία των Scrum Master και BA.

# 7) Δράστε σαν BA:

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

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

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

συμπέρασμα

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

Στο Scrum, δεν υπάρχει όριο έναρξης και λήξης για το ρόλο του QA. Το QA χρειάζεται και πρέπει να συμμετέχει σε κάθε δραστηριότητα από την αρχή μέχρι το τέλος, από τον Προ-προγραμματισμό έως την επισκόπηση / επίδειξη σπριντ και πρέπει να συμμετέχει σε όλες τις δραστηριότητες.

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

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

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

Μη διστάσετε να εκφράσετε τις σκέψεις / προτάσεις σας σχετικά με αυτό το ενημερωτικό άρθρο στην παρακάτω ενότητα σχολίων.

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

^