what is user story acceptance criteria
Ένας τέλειος οδηγός για Κριτήρια αποδοχής ιστοριών χρηστών με σενάρια πραγματικής ζωής:
Στη βιομηχανία ανάπτυξης λογισμικού, η λέξη «Απαίτηση» καθορίζει ποιος είναι ο στόχος μας, τι ακριβώς χρειάζονται οι πελάτες και τι θα κάνει την εταιρεία μας να αυξήσει τις δραστηριότητές της.
Είτε πρόκειται για εταιρεία προϊόντων που κατασκευάζει προϊόντα λογισμικού ή εταιρεία παροχής υπηρεσιών που προσφέρει υπηρεσίες σε διάφορους τομείς λογισμικού, η βασική βάση για όλα αυτά είναι η απαίτηση και η επιτυχία καθορίζεται από το πόσο ικανοποιούνται οι απαιτήσεις.
Ο όρος «απαίτηση» έχει διαφορετικά ονόματα σε διαφορετικές μεθοδολογίες έργου.
Σε Υδατόπτωση , αναφέρεται ως « Έγγραφο απαιτήσεων / προδιαγραφών ', σε Ευκίνητο ή SCRUM αναφέρεται ως «Επικό», «Ιστορία χρήστη».
Σύμφωνα με το μοντέλο Waterfall, τα έγγραφα Απαίτησης είναι τεράστια έγγραφα 200 ή περισσότερων σελίδων καθώς ολόκληρο το προϊόν υλοποιείται σε μία φάση. Αλλά αυτό δεν συμβαίνει με το Agile / SCRUM επειδή σε αυτές τις μεθοδολογίες οι απαιτήσεις παρέχονται για μικρές λειτουργίες ή χαρακτηριστικά καθώς το προϊόν παρασκευάζεται με βήμα προς βήμα τρόπο.
Σε αυτό το άρθρο, έχω δοκιμάσει το καλύτερο δυνατό για να μοιραστώ και τα 4 χρόνια εμπειρίας μου σχετικά με τη συνεργασία με ιστορίες χρηστών και τα σχετικά κριτήρια αποδοχής τους, καθώς και εύκολα και απλά σενάρια πραγματικής ζωής για την καλύτερη κατανόησή σας.
Ας επανεξετάσουμε πρώτα τα βασικά.
Τι θα μάθετε:
- Τι είναι μια ιστορία χρήστη;
- Τι είναι τα κριτήρια αποδοχής;
- Ανακαλύπτοντας τις ιστορίες χρηστών
- Ενδιάμεση ματιά στα Κριτήρια Αποδοχής
- Σημασία της εύρεσης ασυμφωνιών στην Ιστορία χρήστη / Κριτήρια αποδοχής
- συμπέρασμα
- Συνιστώμενη ανάγνωση
Τι είναι μια ιστορία χρήστη;
Μια ιστορία χρήστη είναι απαίτηση για οποιαδήποτε λειτουργικότητα ή χαρακτηριστικό που καταγράφεται σε μία ή δύο γραμμές και έως και 5 γραμμές. Μια ιστορία χρήστη είναι συνήθως η απλούστερη δυνατή απαίτηση και αφορά μόνο μία και μόνο λειτουργικότητα (ή μία λειτουργία).
Η πιο συχνά χρησιμοποιούμενη τυπική μορφή για τη δημιουργία ιστορίας χρήστη αναφέρεται παρακάτω:
Σαν
Παράδειγμα:
Ως χρήστης του WhatsApp, θέλω ένα εικονίδιο κάμερας στο πλαίσιο εγγραφής συνομιλίας να τραβά και να στέλνω εικόνες, ώστε να μπορώ να κάνω κλικ και να μοιραστώ τις εικόνες μου ταυτόχρονα με όλους τους φίλους μου.
Τι είναι τα κριτήρια αποδοχής;
Ένα κριτήριο αποδοχής είναι ένα σύνολο αποδεκτών όρων ή επιχειρηματικών κανόνων τους οποίους η λειτουργικότητα ή το χαρακτηριστικό πρέπει να πληρούν και να πληρούν, προκειμένου να γίνουν αποδεκτοί από τον Κάτοχο του προϊόντος / τους Συμμετόχους.
Αυτό είναι ένα πολύ σημαντικό μέρος της ολοκλήρωσης της ιστορίας των χρηστών και πρέπει να μελετηθεί πολύ καλά από τον Ιδιοκτήτη Προϊόντων και τον Αναλυτή Επιχειρήσεων, επειδή η έλλειψη ενός κριτηρίου μπορεί να κοστίσει πολύ. Αυτή είναι μια απλή αριθμημένη ή κουκκίδα λίστα.
Η μορφή του έχει ως εξής:
' Με δεδομένη την προϋπόθεση όταν κάνω κάποια ενέργεια τότε περιμένω το αποτέλεσμα '.
πώς να ανοίξετε ένα αρχείο bin στον υπολογιστή
Παράδειγμα (w.r.t στην παραπάνω ιστορία χρήστη):
- Ας υποθέσουμε ότι συζητάω με έναν φίλο και θα πρέπει να μπορώ να τραβήξω μια φωτογραφία.
- Όταν κάνω κλικ σε μια εικόνα, θα πρέπει να μπορώ να προσθέσω μια λεζάντα στην εικόνα πριν την στείλω.
- Εάν υπάρχει κάποιο πρόβλημα με την εκκίνηση της κάμερας του τηλεφώνου μου, ένα μήνυμα σφάλματος όπως 'Δεν ήταν δυνατή η εκκίνηση της κάμερας'. κ.λπ., θα πρέπει να εμφανίζονται αναλόγως.
Ως εκ τούτου, η Ιστορία χρήστη καθορίζει την απαίτηση για οποιαδήποτε λειτουργικότητα ή χαρακτηριστικό, ενώ τα Κριτήρια Αποδοχής ορίζουν τον «ορισμό του ολοκληρωμένου» για την ιστορία του χρήστη ή την απαίτηση.
Ως QA, είναι πολύ σημαντικό να κατανοήσουμε βαθιά την ιστορία του χρήστη και τα κριτήρια αποδοχής του, χωρίς να παραμείνει ούτε μια αμφιβολία κατά την «έναρξη της δοκιμής». Προς τα εμπρός ας καταλάβουμε γιατί είναι εξαιρετικά σημαντικό να σκάψουμε 'βαθιά' στις ιστορίες των χρηστών και στα κριτήρια αποδοχής.
Ανακαλύπτοντας τις ιστορίες χρηστών
Καταρχάς, ας κατανοήσουμε πρώτα τη σημασία μιας «σε βάθος» μελέτης ενός βασικού και θεμελιώδους πράγμα, δηλαδή Ιστορίες χρηστών.
Οι ακόλουθες περιπτώσεις είναι οι δικές μου πραγματικές εμπειρίες.
Περίπτωση # 1:
Πριν από 3 χρόνια, δούλευα σε ένα Mobile Application Project και το προϊόν ήταν μια εφαρμογή που είχε σχεδιαστεί για άτομα παράδοσης.
Θα είχατε δει ένα άτομο παράδοσης να έρχεται στο μέρος σας για παράδοση. Και έχουν ένα κινητό τηλέφωνο στο οποίο σας ζητούν να δώσετε την υπογραφή σας μετά την παράδοση. Αυτή η υπογραφή αντικατοπτρίζεται στην πύλη των παρόχων υπηρεσιών ταχυμεταφορών, όπως DTDC, FedEx κ.λπ.
Ας υποθέσουμε ότι η εφαρμογή για κινητά μόλις κυκλοφόρησε και οι πύλες τους είναι ήδη διαθέσιμες και πάνω.
Πρόβλημα: Για ένα Sprint, ο κάτοχος του προϊόντος έχει μια ιστορία χρήστη για αυτήν την εφαρμογή για κινητά που 'Ως Διαχειριστής πύλης, θα πρέπει να μπορώ να βλέπω την υπογραφή που έχει λάβει το άτομο παράδοσης κατά τη στιγμή της παράδοσης' . Εδώ η πύλη (εφαρμογή ιστού) αλλάζει και ενημερώνεται ανάλογα ώστε να αντικατοπτρίζει την υπογραφή.
Ως QA πρέπει να επαληθεύσετε εάν η υπογραφή που καταγράφεται στην εφαρμογή για κινητές συσκευές αντικατοπτρίζει όπως αναμένεται στην πύλη.
Αν κοιτάξετε αυτήν την ιστορία χρηστών, φαίνεται απλή, αλλά υπάρχει μια κρυφή απαίτηση εδώ: 'Για ιστορικές παραδόσεις, δεν υπήρχε λειτουργικότητα αντανάκλασης υπογραφών, οπότε τι θα έπρεπε να συμβεί αν οι πύλες βλέπουν ιστορικές παραδόσεις;' Πρέπει τα ιστορικά δεδομένα να εξαλειφθούν; Πρέπει να επιτρέψουμε σφάλματα ή σφάλματα για τέτοια δεδομένα;
Φυσικά όχι καθόλου, αυτό πρέπει να αντιμετωπιστεί με ευγένεια.
Λύση: Όταν οι αντίστοιχοι πίνακες DB ενημερώνονται για να προσθέσουν μια νέα στήλη για την τοποθεσία υπογραφής, τα παλιά δεδομένα θα πρέπει να έχουν τιμή NULL ή 0 που θα πρέπει να ελεγχθεί και θα πρέπει να εμφανίζεται ένα μήνυμα που να αναφέρει «Δεν υπάρχει υπογραφή».
Αυτό μπορεί να χαρακτηριστεί ως απώλεια από τον Ιδιοκτήτη προϊόντος ή τον Αναλυτή Επιχειρήσεων, αλλά αυτό πρέπει να γίνει. Η εφαρμογή ενός χαρακτηριστικού με επιτυχία, αλλά το να σπάσεις κάτι μαζί του δεν είναι επιθυμητό από τους πελάτες. Αυτό πρέπει να γίνει μαζί με την ίδια ιστορία χρήστη και στο ίδιο σπριντ.
Περίπτωση # 2
Πριν από 6 χρόνια, δούλευα σε μια εφαρμογή χρηματοδότησης συνταξιοδότησης (χωρίς BA), η οποία ήταν μια παγκόσμια εφαρμογή όπου χρηματοοικονομικοί άνθρωποι όπως η CA, οι χρηματοοικονομικοί σύμβουλοι θα μπορούσαν να το χρησιμοποιήσουν για διαφορετικά νομίσματα για να προβάλουν τα επενδυτικά σχέδια, τις αποταμιεύσεις κ.λπ. μεγάλη περίοδο στους πελάτες τους.
Πρόβλημα: Ο Κάτοχος προϊόντος σας δίνει μια Ιστορία χρήστη «Ως Σύμβουλος, θέλω να δω την αναφορά του πελάτη μου με βάση τις οικονομικές λεπτομέρειες που παρέχονται».
Εδώ υπήρχαν 2 κρυμμένες απαιτήσεις και θα το έλεγα ως ατελή ιστορία γιατί:
προς την] Οι αναφορές θα πρέπει να λαμβάνουν υπόψη το ημερήσιο ποσοστό μετατροπής νομίσματος και όχι το ιστορικό όπως στην τελευταία προβολή και
σι] Εάν το νόμισμα αλλάξει μετά την παροχή των οικονομικών στοιχείων του πελάτη, οι αναφορές θα πρέπει να εμφανίζονται στο αλλαγμένο νόμισμα.
Λύση: Έθεσα αυτήν την ανησυχία απευθείας στον Κάτοχο προϊόντων μας και τον ενημέρωσα ότι και τα δύο πρέπει να γίνουν το συντομότερο δυνατό. Συμφώνησε μαζί μου και δημιούργησε 2 διαφορετικές ιστορίες για τα επερχόμενα σπριντ με προτεραιότητα.
Πάρε μακριά: Αυτά πιάστηκαν επειδή όλοι γνωρίζαμε πολύ καλά τα προϊόντα, το σχεδιασμό τους, τη δομή τους κ.λπ. Τέτοιες γνώσεις μπορούν να επιτευχθούν μόνο με την πλήρη κατανόηση του προϊόντος, με την κατανόηση της διαλειτουργικότητας των ενοτήτων και με την προσεκτική μελέτη της ιστορίας των χρηστών ακόμη και αν είναι μια επένδυση 2.
Δημιουργήστε σημειώσεις για να διευκολύνετε τα πράγματα και συζητήστε με τους BA και τους προγραμματιστές σχετικά με τη σκέψη τους.
Ενδιάμεση ματιά στα Κριτήρια Αποδοχής
Η κατανόηση των κριτηρίων αποδοχής και όλων των άλλων προϋποθέσεων και κανόνων είναι ακόμη πιο σημαντική από την υποτίμηση της ιστορίας ενός χρήστη. Επειδή εάν μια απαίτηση είναι ελλιπής ή αόριστη, μπορεί να χρησιμοποιηθεί στο επόμενο σπριντ, αλλά εάν λείπει ένα κριτήριο αποδοχής, τότε η ίδια η ιστορία του χρήστη δεν μπορεί να κυκλοφορήσει.
Υποθέτω ότι όλοι θα χρησιμοποιούσαμε το net banking κάποια στιγμή και οι περισσότεροι από εμάς το χρησιμοποιούμε καθημερινά και κατεβάζω τις ιστορικές μου δηλώσεις πολύ. Εάν το παρατηρήσετε προσεκτικά, υπάρχουν συγκεκριμένες συγκεκριμένες επιλογές για τη λήψη τους.
Υπάρχει μια επιλογή για να επιλέξετε τον τύπο αρχείου για τη λήψη της δήλωσής σας. Υπάρχει μια επιλογή για να επιλέξετε εάν θέλετε να κάνετε λήψη μόνο των πιστώσεων / χρεωστικών / και των δύο.
Τώρα φανταστείτε ότι ο Κάτοχος προϊόντος σας δίνει αυτήν την ιστορία χρήστη «Ως πελάτης, θέλω να κατεβάσω το αντίγραφο κίνησης του λογαριασμού μου, ώστε να μπορώ να δω όλες τις συναλλαγές μου που έγιναν για μια συγκεκριμένη περίοδο».
Με τα ακόλουθα Κριτήρια Αποδοχής:
- Δεδομένου ότι βρίσκομαι στη σελίδα λήψης ιστορικών καταστάσεων, πρέπει να επιλέξω την περίοδο για την οποία θέλω να πραγματοποιήσω λήψη της δήλωσης.
- Δεδομένου ότι βρίσκομαι στη σελίδα λήψης ιστορικών καταστάσεων, θα πρέπει να επιλέξω τον λογαριασμό για τον οποίο θέλω να κατεβάσω τη δήλωση.
- Δεδομένου ότι βρίσκομαι στη σελίδα λήψης ιστορικών δηλώσεων, δεν θα πρέπει να λαμβάνω τη δήλωση για μελλοντική ημερομηνία «Προς».
- Δεδομένου ότι βρίσκομαι στη σελίδα λήψης ιστορικών δηλώσεων, δεν πρέπει να μου επιτρέπεται να επιλέξω ημερομηνία 'Από' 10 χρόνια μετά το παρελθόν.
- Λαμβάνοντας υπόψη ότι κατεβάζω τη δήλωσή μου, θα πρέπει να μπορώ να δω το ληφθέν αρχείο.
- Λαμβάνοντας υπόψη ότι βρίσκομαι στη σελίδα λήψης ιστορικών δηλώσεων, θα πρέπει να μπορώ να κατεβάσω τη δήλωσή μου σε μορφές doc, excel και pdf.
Εάν περάσετε από αυτήν την αποδοχή, υπάρχουν 3 πράγματα που λείπουν εδώ:
- Όνομα και μορφή του ονόματος αρχείου που θα ληφθεί.
- Ποιες πληροφορίες (ονόματα στηλών) θα εμφανίζονται στο αρχείο.
- Η λίστα επιλογών για να επιλέξετε τι είδους συναλλαγή επιθυμεί ο πελάτης, δηλαδή μόνο χρεώσεις ή μόνο πιστώσεις ή και τα δύο.
Τέτοιες περιπτώσεις μπορεί να συμβούν περιστασιακά, ωστόσο εξακολουθείτε να μελετάτε καλά για κάθε κριτήριο αποδοχής και να προσπαθείτε να το οπτικοποιήσετε με αναφορά στην ιστορία του χρήστη. Όσο περισσότερο μελετάτε βαθιά για τους όρους και τους επιχειρηματικούς κανόνες, τόσο περισσότερες θα είναι οι γνώσεις σας σχετικά με τη λειτουργία.
Τα σφάλματα που εντοπίστηκαν στο αρχικό στάδιο δεν κοστίζουν τίποτα σε σύγκριση με το κόστος στο στάδιο «δοκιμών».
Σημασία της εύρεσης ασυμφωνιών στην Ιστορία χρήστη / Κριτήρια αποδοχής
Είναι πάντα σημαντικό να κάνετε μια βαθιά βουτιά στις ιστορίες των χρηστών και στα κριτήρια αποδοχής σε πρώιμο στάδιο πριν από την έναρξη της ανάπτυξης ή της δοκιμής.
Επειδή περιλαμβάνει:
# 1) Σπατάλη του χρόνου:
Εάν οι αποκλίσεις ή τα λάθη στο κριτήριο της ιστορίας / αποδοχής του χρήστη εντοπιστούν κατά τη διάρκεια της ανάπτυξης ή της δοκιμής, τότε ίσως χρειαστεί να γίνει πολλή επανεργασία στον υπόλοιπο χρόνο σπριντ.
Δεν συμβαίνει ότι ακόμη και αν ο Κάτοχος προϊόντος χάσει λίγα πράγματα, θα μεταφέρει την ιστορία του χρήστη στο επόμενο σπριντ. 95% πιθανότητες είναι να ζητήσουν από την ομάδα να κάνει την απαραίτητη εφαρμογή και να την αφήσει στο ίδιο σπριντ.
Ως εκ τούτου, γίνεται εφιάλτης για την ομάδα καθώς πρέπει να περνούν περισσότερο χρόνο, να έρχονται τα Σαββατοκύριακα ή να εργάζονται αργά το βράδυ. Αυτό μπορεί να αποφευχθεί με τη μελέτη και τη συζήτηση των κριτηρίων ιστορίας / αποδοχής του χρήστη στο νωρίτερο δυνατό στάδιο.
# 2) Σπατάλη των προσπαθειών:
Οι προγραμματιστές και το QA πρέπει να επανεξετάσουν τον κώδικα και τις περιπτώσεις δοκιμών που έχουν εφαρμοστεί ξανά. Η ενημέρωση, η προσθήκη και η κατάργηση σύμφωνα με την απαίτηση δεν είναι εύκολη υπόθεση. Γίνεται πολύ επώδυνο καθώς υπάρχει ήδη πίεση για παράδοση στην ώρα τους.
Σε μια τέτοια κατάσταση, υπάρχουν πιθανότητες λαθών στο στάδιο ανάπτυξης ή δοκιμής. Εάν συναντήσετε μια τέτοια κατάσταση, πηγαίνετε στο 'DevQA Pairing'. Ως κερασάκι στην τούρτα, ενδέχεται να μην λάβετε αποζημίωση για την επιπλέον εργασία.
συμπέρασμα
Η βαθιά κατανόηση της Ιστορίας Χρήστη και των κριτηρίων αποδοχής μπορεί να επιτευχθεί μόνο αφιερώνοντας πολύ χρόνο στη μελέτη της.
Δεν υπάρχει διαθέσιμο συγκεκριμένο εργαλείο ή μάθημα στην αγορά για να το κάνετε αυτό για εσάς, καθώς πρόκειται για λογική σκέψη, εμπειρία και γνώση σχετικά με το προϊόν.
Συμμετέχοντας ενεργά στη συνάντηση προ-προγραμματισμού, μιλώντας στο BA, σπουδάζοντας μόνοι σας μπορεί να σας βοηθήσει μόνο να το επιτύχετε. Όσο περισσότερες προσπάθειες καταβάλλετε, τόσο περισσότερο μαθαίνετε και μεγαλώνετε.
Είτε πρόκειται για QA είτε για προγραμματιστές, όλοι πρέπει να βρίσκονται στην ίδια σελίδα σχετικά με τις ιστορίες των χρηστών και τα κριτήρια αποδοχής τους, μόνο τότε οι προσδοκίες του πελάτη μπορούν να επιτευχθούν με επιτυχία.
Έχετε κάτι νέο να μοιραστείτε μαζί μας σχετικά με τις εμπειρίες σας σχετικά με τη συνεργασία με τις Ιστορίες χρηστών; Παρακαλώ εκφράστε τις σκέψεις σας παρακάτω !!
Συνιστώμενη ανάγνωση
- MongoDB Δημιουργία χρήστη και εκχώρηση ρόλων με παραδείγματα
- Δείγμα προτύπου για αναφορά δοκιμής αποδοχής με παραδείγματα
- Έλεγχος ταυτότητας χρήστη στο MongoDB
- Παράμετρος δεδομένων JMeter με χρήση μεταβλητών καθορισμένων από τον χρήστη
- Δικαιώματα Unix: Δικαιώματα αρχείων στο Unix με παραδείγματα
- Τι είναι ο έλεγχος αποδοχής (ένας πλήρης οδηγός)
- Τι είναι ο έλεγχος αποδοχής χρήστη (UAT): Ένας πλήρης οδηγός
- Εκμάθηση Python DateTime με παραδείγματα