Γιατί οι επιχειρησιακοί δοκιμαστές χρειάζονται διαφορετικά σενάρια ελέγχου
Μια δοκιμή συστήματος γίνεται από ανθρώπους που έφτιαξαν το σύστημα ή το γνωρίζουν καλά. Μια δοκιμή αποδοχής χρηστών γίνεται από ανθρώπους που το χρησιμοποιούν: ξέρουν τη δουλειά, όχι τη διαμόρφωση. Δεν ξέρουν ποιο πεδίο είναι νέο, ποια ροή εκτελείται στο παρασκήνιο ή τι εννοούσε ο προγραμματιστής.
Έτσι, ένα σενάριο ελέγχου UAT πρέπει να λειτουργεί για κάποιον που:
- ξέρει την επιχειρησιακή διαδικασία απέξω, αλλά όχι τις νέες οθόνες·
- έχει λίγες ώρες ανάμεσα σε άλλες δουλειές, όχι μια εβδομάδα·
- δεν πρέπει ποτέ να μαντεύει αν ένα βήμα πέρασε ή απέτυχε·
- θα σταματήσει και θα περιμένει όταν ένα βήμα δεν είναι σαφές, και θα χάσει χρόνο.
Κάθε ώρα που αφιερώνεται σε σαφή σενάρια ελέγχου γλιτώνει πολλές ώρες στις ημέρες δοκιμών: λιγότερες ερωτήσεις, λιγότερα ζητήματα που αποδεικνύονται παρεξηγήσεις και αποτελέσματα που μπορείτε να εμπιστευτείτε στο go/no-go.
Από user stories και διαδικασίες
Τα σενάρια ελέγχου προέρχονται από δύο πηγές και χρειάζεστε και τις δύο.
Τα user stories και τα κριτήρια αποδοχής τους
Ένα user story λέει τι θέλει να κάνει κάποιος και γιατί: Ως πωλητής θέλω να μετατρέψω ένα αξιολογημένο lead, ώστε να αποκτήσω έναν λογαριασμό, μια επαφή και μια ευκαιρία. Τα κριτήρια αποδοχής του λένε πότε έχει ολοκληρωθεί. Κάθε κριτήριο αποδοχής είναι υποψήφιο για ένα βήμα ή ένα σενάριο ελέγχου.
Ελέγξτε την κάλυψη: κάθε user story στο εύρος χρειάζεται τουλάχιστον ένα σενάριο ελέγχου. Ένα story χωρίς σενάριο ελέγχου είναι ένα κενό, και τα κενά βρίσκονται στην παραγωγή.
Επιχειρησιακές διαδικασίες, από άκρη σε άκρη
Τα user stories κόβονται μικρά για τους προγραμματιστές. Η επιχείρηση δουλεύει σε διαδικασίες που διασχίζουν πολλά stories: lead to cash, από την προσφορά στην παραγγελία, διαχείριση υποθέσεων από το email έως την επίλυση. Ένα story μπορεί να περνά μόνο του, ενώ η διαδικασία σπάει στο πέρασμα από τη μία ομάδα στην άλλη.
Γι' αυτό προσθέστε end-to-end σενάρια ελέγχου που ακολουθούν μια διαδικασία από την αρχή ως το τέλος, μέσα από διαφορετικούς ρόλους: ο πωλητής φτιάχνει την προσφορά, ο προϊστάμενος την εγκρίνει, η παραγγελία πηγαίνει στο λογιστήριο. Αυτά είναι συχνά τα σενάρια ελέγχου που μετρούν περισσότερο για την επιχείρηση.
Στο UAT StudioΔιαβάστε τα user stories από Jira ή Azure DevOps στην κάρτα User stories και επιλέξτε Only stories without test cases για να δείτε τα κενά. Με τη μονάδα AI test design, η AI προτείνει σενάρια ελέγχου από τα stories σας ή από μια περιγραφή διαδικασίας, και με το δικό μοντέλο της εταιρείας σας. Τίποτα δεν γίνεται σενάριο ελέγχου μέχρι να το εγκρίνετε. Χωρίς τη μονάδα, το Prepare with your own AI δίνει ένα prompt για να το επικολλήσετε στην AI της εταιρείας σας· τα βήματα με σήμανση [CHECK] είναι υποθέσεις προς έλεγχο.
Ένας στόχος ανά σενάριο ελέγχου
Ένα σενάριο ελέγχου δοκιμάζει μία επιχειρησιακή περίπτωση, με έναν στόχο. Ο τίτλος του λέει τι πετυχαίνει ο δοκιμαστής, με τις λέξεις της επιχείρησης:
- Μετατροπή ενός lead με υπάρχοντα λογαριασμό
- Έγκριση μιας προσφοράς με έκπτωση άνω του 20%
- Δρομολόγηση ενός email από γνωστό πελάτη στη σωστή ουρά
Όχι Δοκιμή του object lead και όχι Leads, ευκαιρίες και προσφορές. Όταν ένα σενάριο ελέγχου έχει πολλούς στόχους, μία αποτυχία τους μπλοκάρει όλους και το αποτέλεσμα λέει λίγα: τι απέτυχε και τι λειτουργεί ακόμη;
Πόσο μεγάλο είναι ένα σενάριο ελέγχου;
Κατά κανόνα, ένα σενάριο ελέγχου έχει από τρία έως δεκαπέντε βήματα και παίρνει σε έναν δοκιμαστή πέντε έως είκοσι λεπτά. Αν είναι πολύ μεγαλύτερο, μάλλον έχει περισσότερους από έναν στόχους: χωρίστε το. Αν είναι πολύ μικρότερο, ίσως ανήκει μαζί με ένα διπλανό.
Τα end-to-end σενάρια ελέγχου είναι η εξαίρεση. Ακολουθούν μια ολόκληρη διαδικασία και μπορεί να είναι μεγαλύτερα. Κρατήστε τα, αλλά φροντίστε κάθε τμήμα της διαδικασίας να έχει και το δικό του, μικρότερο σενάριο ελέγχου, ώστε μια αποτυχία να εντοπίζεται εύκολα.
Βήματα με αναμενόμενο αποτέλεσμα
Κάθε βήμα έχει δύο μέρη: μια ενέργεια (τι κάνει ο δοκιμαστής) και ένα αναμενόμενο αποτέλεσμα (τι πρέπει να συμβεί). Το αναμενόμενο αποτέλεσμα είναι αυτό που κάνει ένα βήμα ελέγξιμο. Χωρίς αυτό, ο δοκιμαστής αποφασίζει τι είναι αρκετά καλό, και δύο δοκιμαστές αποφασίζουν διαφορετικά.
Γράψτε την ενέργεια
- Μία ενέργεια ανά βήμα. Το Ανοίξτε το lead και κάντε κλικ στο Convert είναι εντάξει· πέντε κλικ σε ένα βήμα δεν είναι.
- Ξεκινήστε με ένα ρήμα: ανοίξτε, κάντε κλικ, συμπληρώστε, επιλέξτε, αποθηκεύστε.
- Χρησιμοποιήστε τις ετικέτες όπως εμφανίζονται στην οθόνη, με έντονα γράμματα ή σε εισαγωγικά.
- Πείτε τι, όχι πώς λειτουργεί εσωτερικά το σύστημα. Αποθηκεύστε την προσφορά, όχι ενεργοποιήστε τη ροή έγκρισης.
Γράψτε το αναμενόμενο αποτέλεσμα
- Πείτε τι βλέπει ο δοκιμαστής: ένα μήνυμα, μια τιμή σε ένα πεδίο, μια νέα εγγραφή, μια κατάσταση.
- Να είστε συγκεκριμένοι. Η ευκαιρία βρίσκεται στο στάδιο Qualification, όχι λειτουργεί.
- Αναφέρετε τι δεν πρέπει να συμβεί όταν αυτό έχει σημασία: Δεν δημιουργείται δεύτερος λογαριασμός.
- Για ό,τι κάνει το σύστημα μόνο του, πείτε πού να κοιτάξει ο δοκιμαστής: Η υπόθεση εμφανίζεται στην ουρά Benelux Support μέσα σε ένα λεπτό.
Δεδομένα δοκιμής και ρόλοι
Δεδομένα δοκιμών
Οι δοκιμαστές χάνουν περισσότερο χρόνο ψάχνοντας δεδομένα από οποιοδήποτε άλλο μέρος ενός UAT. Βάλτε τα δεδομένα στο σενάριο ελέγχου όπου έχουν σημασία: ποιος πελάτης, ποιο προϊόν, ποιος τιμοκατάλογος (price list ή price book), ποιο ποσό. Προετοιμάστε αυτά τα δεδομένα στο περιβάλλον δοκιμών πριν από την πρώτη ημέρα δοκιμών.
- Χρησιμοποιήστε ονόματα που δείχνουν καθαρά ότι είναι δεδομένα δοκιμής, όπως Jansen Logistics (test).
- Δώστε σε κάθε δοκιμαστή τις δικές του εγγραφές όταν αλλάζει δεδομένα, ώστε δύο άτομα να μην επεξεργάζονται την ίδια ευκαιρία.
- Προσθέστε οριακές τιμές: μια έκπτωση λίγο κάτω και λίγο πάνω από το όριο, ένα κενό υποχρεωτικό πεδίο.
- Μη χρησιμοποιείτε πραγματικά προσωπικά δεδομένα πελατών όπου μπορείτε να το αποφύγετε.
Ρόλοι
Σε ένα CRM, το τι μπορεί να δει και να κάνει ένας χρήστης εξαρτάται από τον ρόλο του: ένα προφίλ και permission sets στο Salesforce, ρόλοι ασφαλείας και μια επιχειρηματική μονάδα στο Dynamics 365. Ένα UAT αποδεικνύει ότι κάθε ρόλος μπορεί να κάνει τη δουλειά του, και μόνο τη δουλειά του. Γι' αυτό κάθε σενάριο ελέγχου λέει ποιος ρόλος το δοκιμάζει, και ο δοκιμαστής συνδέεται με έναν χρήστη δοκιμών που έχει ακριβώς αυτόν τον ρόλο.
Ποτέ μη δοκιμάζετε με διαχειριστή. Ένας διαχειριστής βλέπει και μπορεί να κάνει τα πάντα, οπότε τα προβλήματα που πρέπει να βρει ένα UAT μένουν κρυμμένα.
Στο UAT StudioΚάθε βήμα έχει μια ενέργεια, ένα αναμενόμενο αποτέλεσμα και προαιρετικά δεδομένα δοκιμής. Κάθε δοκιμαστής έχει ένα Test role και ένα Test account, που εμφανίζονται στην κορυφή των δοκιμών του ως Log in as …, και ο ρόλος εμφανίζεται δίπλα στο όνομά του σε κάθε ζήτημα που καταγράφει.
Προτεραιότητα και κίνδυνος
Δεν υπάρχει ποτέ αρκετός χρόνος για να δοκιμαστούν όλα εξίσου καλά. Σημειώστε κάθε σενάριο ελέγχου ώστε τα σημαντικά να δοκιμάζονται πρώτα και να ολοκληρώνονται ακόμη κι όταν ο χρόνος τελειώνει.
| Προτεραιότητα | Τι σημαίνει | Παράδειγμα |
|---|---|---|
| Must | Πρέπει να λειτουργεί από την πρώτη ημέρα. Αν αποτύχει, η μετάβαση σε παραγωγή κινδυνεύει. | Δημιουργία και αποστολή μιας προσφοράς· δρομολόγηση μιας υπόθεσης στη σωστή ουρά. |
| Should | Σημαντικό, αλλά η επιχείρηση μπορεί να ζήσει με μια εναλλακτική λύση για λίγο. | Ένα dashboard για τον διευθυντή πωλήσεων. |
| Could | Καλό να υπάρχει. Δοκιμάζεται όταν υπάρχει χρόνος. | Μια προβολή λίστας ταξινομημένη ανά περιοχή. |
Προσθέστε δίπλα τον κίνδυνο: τι κοστίζει αν αυτό πάει στραβά μετά τη μετάβαση σε παραγωγή. Μια λάθος τιμή σε ένα τιμολόγιο είναι υψηλός κίνδυνος· μια λάθος ετικέτα σε μια αναφορά είναι χαμηλός. Μέσα στην ίδια προτεραιότητα, οι δοκιμαστές ξεκινούν από τον υψηλό κίνδυνο.
Να είστε αυστηροί με το Must. Όταν τα μισά σενάρια ελέγχου είναι Must, η ετικέτα δεν σημαίνει τίποτα: κρατήστε την για ό,τι η επιχείρηση δεν μπορεί να κάνει χωρίς αυτό. Συμφωνήστε τις προτεραιότητες με τους υπεύθυνους των διαδικασιών: αυτοί αποφασίζουν επίσης στο go/no-go, όπου τα σενάρια ελέγχου Must που δεν πέρασαν μετρούν περισσότερο.
Στο UAT StudioΟρίστε Priority (Must, Should, Could) και Risk (High, Medium, Low) στον επεξεργαστή ή σε μια στήλη κατά την εισαγωγή. Διαβάζονται και οι τιμές άλλων εργαλείων: τα Critical και High γίνονται Must, τα Medium και Normal Should, το Low Could. Οι δοκιμαστές βλέπουν πρώτα τα σενάρια ελέγχου Must, με τον υψηλό κίνδυνο πρώτα μέσα σε κάθε προτεραιότητα.
Ένα παράδειγμα
Σενάριο ελέγχου 12: Έγκριση μιας προσφοράς με έκπτωση άνω του 20%
Προτεραιότητα Must, κίνδυνος High. User story CRM-118. Ρόλος: πωλητής (βήματα 1 έως 3) και διευθυντής πωλήσεων (βήματα 4 και 5).
| Βήμα | Action | Αναμενόμενο αποτέλεσμα | Δεδομένα δοκιμών |
|---|---|---|---|
| 1 | Ανοίξτε την ευκαιρία και δημιουργήστε μια νέα προσφορά. | Ανοίγει μια προσφορά, συνδεδεμένη με την ευκαιρία, με τα προϊόντα της. | Ευκαιρία Jansen Logistics – Support |
| 2 | Ορίστε την έκπτωση στο 25% και αποθηκεύστε. | Η προσφορά αποθηκεύεται. Εμφανίζει την κατάσταση Needs approval. | Έκπτωση 25% |
| 3 | Προσπαθήστε να στείλετε την προσφορά στον πελάτη. | Η αποστολή δεν είναι δυνατή. Ένα μήνυμα λέει ότι η προσφορά χρειάζεται έγκριση. | |
| 4 | Συνδεθείτε ως διευθυντής πωλήσεων και ανοίξτε το αίτημα έγκρισης. | Το αίτημα δείχνει την προσφορά, την έκπτωση και τον πωλητή. | Χρήστης δοκιμών Sales manager Benelux |
| 5 | Εγκρίνετε το αίτημα. | Η προσφορά εμφανίζει Approved και ο πωλητής λαμβάνει ένα email. |
Προσέξτε τι το κάνει να λειτουργεί: ένας στόχος στον τίτλο, μία ενέργεια ανά βήμα, ένα αναμενόμενο αποτέλεσμα που ο δοκιμαστής μπορεί να ελέγξει, τα δεδομένα και ο ρόλος ονομαστικά, και μια αρνητική ροή στο βήμα 3. Προσθέστε ένα δεύτερο σενάριο ελέγχου για έκπτωση κάτω από το όριο, που δεν πρέπει να χρειάζεται έγκριση.
Συνηθισμένα λάθη
- Χωρίς αναμενόμενο αποτέλεσμα, ή λειτουργεί όπως αναμένεται. Ο δοκιμαστής πρέπει να μαντέψει τι αναμενόταν.
- Τεχνική γλώσσα. Ονόματα πεδίων από τη βάση δεδομένων, ονόματα objects ή ελέγξτε ότι ενεργοποιείται το trigger. Χρησιμοποιήστε τις λέξεις της οθόνης.
- Πολλοί στόχοι σε ένα σενάριο ελέγχου. Μία αποτυχία μπλοκάρει τα υπόλοιπα και το αποτέλεσμα λέει λίγα.
- Μόνο η θετική ροή. Προσθέστε ένα υποχρεωτικό πεδίο που μένει κενό, μια τιμή πάνω από ένα όριο, έναν χρήστη που δεν πρέπει να βλέπει μια εγγραφή.
- Δεδομένα δοκιμής που λείπουν. Ανοίξτε μια ευκαιρία: ποια; Σε ποιο στάδιο, με ποια προϊόντα;
- Χωρίς ρόλο. Ο δοκιμαστής χρησιμοποιεί όποιον λογαριασμό έχει, συχνά έναν με πάρα πολλά δικαιώματα.
- Αντιγραμμένα από τη δοκιμή συστήματος. Γραμμένα για προγραμματιστές, με βήματα που οι επιχειρησιακοί δοκιμαστές δεν μπορούν να ακολουθήσουν.
- Όλα είναι Must. Τότε τίποτα δεν είναι, και οι σημαντικές δοκιμές δεν γίνονται πρώτες.
- Γράφτηκαν μία φορά, δεν διαβάστηκαν ποτέ. Σενάρια που κανείς δεν έλεγξε πριν από τις ημέρες δοκιμών είναι γεμάτα παλιές ετικέτες και λάθος μενού.
Ζητήστε από έναν βασικό χρήστη να τα ελέγξει
Πριν από τις ημέρες δοκιμών, ζητήστε από έναν βασικό χρήστη της επιχείρησης να διαβάσει τα σενάρια ελέγχου και να δοκιμάσει δύο ή τρία από αυτά στο περιβάλλον δοκιμών. Βρίσκει ό,τι δεν βλέπει αυτός που τα έγραψε: ένα βήμα που προϋποθέτει γνώσεις, μια ετικέτα που άλλαξε, μια διαδικασία που λειτουργεί διαφορετικά σε άλλη χώρα.
Ελέγξτε ταυτόχρονα ότι κάθε user story στο εύρος έχει σενάριο ελέγχου, ότι κάθε ρόλος στο εύρος δοκιμάζει κάτι και ότι τα δεδομένα δοκιμής υπάρχουν. Και κρατήστε τα σενάρια ελέγχου μετά τη μετάβαση σε παραγωγή: είναι το regression test σας για την επόμενη έκδοση του CRM.
Στο UAT StudioΕισαγάγετε σενάρια ελέγχου από Excel, Azure DevOps, Jira με Xray ή Zephyr Scale, ή TestRail, ή γράψτε τα στον επεξεργαστή. Η βιβλιοθήκη προτύπων, ένα πρόσθετο σε κάθε πακέτο επί πληρωμή, έχει έτοιμα σενάρια για Salesforce και Dynamics 365 που προσαρμόζετε στη δική σας διαμόρφωση.
Δωρεάν για χρήση
Για όλα τα υπόλοιπα που πρέπει να οργανώσετε πριν, κατά τη διάρκεια και μετά το UAT, δείτε τη λίστα ελέγχου UAT για μετάβαση CRM σε παραγωγή, επίσης ως δωρεάν αρχείο Excel.
