Create a Bug
Διαδικασία καταγραφής (tracking) ενός defect που αναγνωρίστηκε σε μια εφαρμογή.
Last updated
Διαδικασία καταγραφής (tracking) ενός defect που αναγνωρίστηκε σε μια εφαρμογή.
Last updated
Κατά την διαδικασία testing μιας εφαρμογής, αν ο testing engineer εντοπίσει ένα defect θα πρέπει να το καταγράψει για να δρομολογηθεί η επίλυσή του.
Το εργαλείο καταγραφής των defects είναι το Boards του Azure DevOps.
O tester θα πρέπει να πλοηγηθεί στο αντίστοιχο Azure project που θα του υποδείξει ο Solution Manager (SM) και στο Boards section να προσθέσει ένα new Working Item τύπου Bug.
Για την καταγραφή γενικών ζητημάτων του project, δείτε την ενότητα Create an Issue.
Εφόσον o tester δημιουργήσει το Bug item και συμπληρώσει τα required fields, θα πρέπει να κάνει assign το Bug στον Solution Manager. Στην συνέχεια ο SM είναι υπεύθυνος να αναθέσει το Bug στον κατάλληλο developer για την επίλυσή του.
Το assignment στον SM είναι σημαντικό διότι εξασφαλίζει οτι η επίλυση του bug δεν θα αγνοηθεί. Οι testers οφείλουν να ελέγχουν περιοδικά οτι όλα τα Bugs & Issues ενός project είναι assigned. Το παραπάνω μπορεί να γίνει αποδοτικά με την χρήση των Queries. Για την διαχείριση των Unassigned Bugs δείτε την σελίδα Create Queries.
By default όταν δημιουργούμε ένα Bug το state του ορίζεται ως Active. Αυτό αλλάζει κατά την διάρκεια ενός Bug lifecycle.
Στο Azure Boards το Bug item περιλαμβάνει 2 πεδία στα οποία ορίζονται: η βαρύτητα του Bug στην λειτουργία της εφαρμογής (severity) και η προτεραιότητα στην επίλυσή του (priority).
Το πεδίο Severity ορίζει την βαρύτητα ενός Bug στην εφαρμογή. Ο tester οφείλει να εκτιμήσει και να θέσει (στο βαθμό του εφικτού) το severity για να μπορεί η ομάδα να οργανώσει και να προτεραιοποιήσει τις εργασίες επίλυσης.
Οι διαθέσιμες τιμές του severity είναι τέσσερις:
Critical: Defects του core business μιας εφαρμογής, που καθιστούν την εφαρμογή μη χρηστική απο την πλειοψηφία των χρηστών. Στις περιπτώσεις αυτές ο χρήστης δεν μπορεί να ολοκληρώσει την επιθυμητή ενέργεια με εναλλακτικό τρόπο.
High: Defects του core business μιας εφαρμογής, που καθιστούν την εφαρμογή μη χρηστική έστω απο μια μειοψηφία των χρηστών. Ο χρήστης διαθέτει εναλλακτικό τρόπο να ολοκληρώσει την επιθυμητή ενέργεια.
Medium (Default option): Defects που προκαλούν διάφορες δυσλειτουργίες στο σύνολο της εφαρμογής αλλά οχι τόσο σημαντικές ώστε να την καθιστούν μη χρηστική.
Low: Defects τα οποία δεν δημιουργούν σημαντικά προβλήματα στην χρήση της εφαρμογής.
Αν ο tester δεν μπορεί να εκτιμήσει το severity αφήνει την default option (Medium) και επικοινωνει με τον QA Leader για επανεκτίμηση.
Ta κριτήρια για τον χαρακτηρισμός ενός Bug θα πρέπει να είναι σαφή και να μην διαφοροποιούνται ανα project ή engineer.
Η προτεραιότητα της επίλυσης ενός Bug μπορεί να τίθεται ή να μεταβάλεται και απο μη τεχνικούς παράγοντες. Υπάρχουν περιπτώσεις που το Priority ταυτίζεται με το Severity και άλλες που είναι εκ διαμέτρου διαφορετικά. Συνήθως η τιμή του αλλάζει μόνο απο τον Project manager.
Προτείνεται ο tester να αφήνει την default τιμή που ορίζει το το Azure Boards (priority 2).
