Bug lifecycle
Τα states του lifecycle ενός Bug που χρησιμοποιούμε στo testing & development.
Last updated
Τα states του lifecycle ενός Bug που χρησιμοποιούμε στo testing & development.
Last updated
To lifecycle ενός Bug item καθορίζεται απο το State property.
Όπως περιγράψαμε στην προηγούμενη, όταν ο tester δημιουργήσει ένα Bug ως default state τίθεται το Active. Στο testing process μας χρησιμοποιούμε συνολικά τέσσερα Bug states.
Αναλυτικά:
Το default state όταν ο tester δημιουργεί ένα Bug. Ως Active χαρακτηρίζεται ένα bug το οποίο έχει γίνει accept από τον Solution Manager και είναι σε διαδικασία επίλυσης locally από το development team. O SM αναλαμβάνει να κάνει assign το Bug στο κατάλληλο engineer για την επίλυσή του.
Στο Azure Boards το default state ενός Bug είναι το New και για να γίνει Active απαιτείται το accept απο τον Solution Manager. Στα projects μας η διαδικασία του bug acceptance παραλείπεται, για αυτό τα bugs χαρακτηρίζονται αυτόματα ως Active με χρήση custom Working Item rule.
Εφόσον το development team έχει επιλύσει το Βug locally το επόμενο βήμα είναι το deployment στο testing enviroment. Υπάρχουν 2 περιπτώσεις αναλόγως του deployment flow που χρησιμοποιείται:
Αν το project υποστηρίζει CI/CD το state Ready For Deployment παραλείπεται. Σε αυτήν την περίπτωση το Bug χαρακτηρίζεται αυτόματα ως Resolved μέσα απο την Pull request διαδικασία. Βλέπετε ενότητα Set Resolved in Pull request .
Το Ready For Deployment state αποτελεί custom Working Item state για τις ανάγκες του φιλτραρίσματος των Bugs που έχουν είναι fixed locally.
Ως Resolved χαρακτηρίζεται ένα Bug που έχει γίνει fixed locally & deployed στο test enviroment. Το Βug fix πλέον είναι visible στο test env και έτοιμο για retesting. Εφόσον το state τεθεί σε Resolved , τo working item γίνεται αυτόματα assign στον creator (συνήθως tester) για retesting.
Στα projects που υποστηρίζεται Continuous Integration ο χαρακτηρισμός του Bug ως Resolved μπορεί να γίνει αυτόματα μέσω των Pull Requests.
Υπάρχουν 2 τρόποι να αλλάξουμε το state σε ένα Pull Request και εξαρτώνται απο τον τρόπο που δημιουργήθηκε το branch που περιέχει το fix:
Αν ο developer δημιουργήσει το branch μέσα απο το Development section του Bug item, τότε το Azure προσθέτει αυτόματα το Bug στα linked items του branch.
Στην συνέχεια ο reviewer επιλέγοντας "Complete associated work items after merging" στο Complete του pull request , το Bug χαρακτηρίζεται αυτόματα ως Resolved.
Στην περίπτωση που το branch έχει δημιουργηθεί manually και δεν είναι linked σε κάποιο Working Item, τότε ο developer όταν δημιουργήσει το pull request πρέπει να ορίσει στο Description τα Bugs θα γίνουν Resolved ακολουθώντας την παρακάτω σύνταξη:
Στο παρακάτω παράδειγμα τα Working Items #300 και #301 θα τεθούν σε Resolved state όταν το pull request γίνει Completed απο τους reviewers.
Το auto assignment του Resolved Bug στον creator αποτελεί custom action που υλοποιείται με χρήση custom Working Item rule.
Ως Closed χαρακτηρίζεται ένα Bug όταν έχει γίνει retest και έχει γίνει verified απο τους testers ότι πληροί τα acceptance criteria. Τα Bugs μπορούν να χαρακτηριστούν Closed μόνο απο τους testers ή τον Solution Manager. To Bug δεν θα πρέπει να χαρακτηρίζεται Closed από το development team.
Σε αντίθετη περίπτωση που το Bug δεν πληροί τα acceptance criteria, τότε χαρακτηρίζεται ξανά ως Active και γίνεται assign στον SM για redevelop. Το Active item θα πρέπει να ακολουθήσει τα states του lifecycle απο την αρχή.
Azure Bug lifecycle example: https://learn.microsoft.com/en-us/azure/devops/boards/work-items/guidance/media/alm-pt-scrum-wf-bug.png?view=azure-devops
Αν το deployment πραγματοποιείται manually, ο dev engineer όταν ολοκληρώσει την επίλυση του Bug θέτει το state του Bug ως Ready For Deployment και κάνει assign το Bug στον SM. Στοv προκαθορισμό χρόνο του deployment στο test env, ο SM μπορεί να φιλτράρει τα working items με Ready For Deployment state και κατόπιν της ολοκλήρωσης του deployment να τα χαρακτηρίσει ως Resolved statemanually (Δείτε ενότητα )
