Bug lifecycle
Τα states του lifecycle ενός Bug που χρησιμοποιούμε στo testing & development.
To lifecycle ενός Bug item καθορίζεται απο το State property.
Which state should I use?
Όπως περιγράψαμε στην προηγούμενη, όταν ο tester δημιουργήσει ένα Bug ως default state τίθεται το Active. Στο testing process μας χρησιμοποιούμε συνολικά τέσσερα Bug states.
Αναλυτικά:
Active state
Το default state όταν ο tester δημιουργεί ένα Bug. Ως Active χαρακτηρίζεται ένα bug το οποίο έχει γίνει accept από τον Solution Manager και είναι σε διαδικασία επίλυσης locally από το development team. O SM αναλαμβάνει να κάνει assign το Bug στο κατάλληλο engineer για την επίλυσή του.
Ready For Deployment state
Εφόσον το development team έχει επιλύσει το Βug locally το επόμενο βήμα είναι το deployment στο testing enviroment. Υπάρχουν 2 περιπτώσεις αναλόγως του deployment flow που χρησιμοποιείται:
Continuous Delivery supported (deployment via CI/CD)
Αν το project υποστηρίζει CI/CD το state Ready For Deployment παραλείπεται. Σε αυτήν την περίπτωση το Bug χαρακτηρίζεται αυτόματα ως Resolved μέσα απο την Pull request διαδικασία. Βλέπετε ενότητα Set Resolved in Pull request .
Manually deployment
Αν το 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 (Δείτε ενότητα Create Queries)
Resolved state
Ως Resolved χαρακτηρίζεται ένα Bug που έχει γίνει fixed locally & deployed στο test enviroment. Το Βug fix πλέον είναι visible στο test env και έτοιμο για retesting. Εφόσον το state τεθεί σε Resolved , τo working item γίνεται αυτόματα assign στον creator (συνήθως tester) για retesting.
Set Resolved in Pull request
Στα projects που υποστηρίζεται Continuous Integration ο χαρακτηρισμός του Bug ως Resolved μπορεί να γίνει αυτόματα μέσω των Pull Requests.
Υπάρχουν 2 τρόποι να αλλάξουμε το state σε ένα Pull Request και εξαρτώνται απο τον τρόπο που δημιουργήθηκε το branch που περιέχει το fix:
Bug item is linked to branch (branch created via Working Item)
Αν ο developer δημιουργήσει το branch μέσα απο το Development section του Bug item, τότε το Azure προσθέτει αυτόματα το Bug στα linked items του branch.
Στην συνέχεια ο reviewer επιλέγοντας "Complete associated work items after merging" στο Complete του pull request , το Bug χαρακτηρίζεται αυτόματα ως Resolved.
Bug item has no connection to branch (branch created manually)
Στην περίπτωση που το branch έχει δημιουργηθεί manually και δεν είναι linked σε κάποιο Working Item, τότε ο developer όταν δημιουργήσει το pull request πρέπει να ορίσει στο Description τα Bugs θα γίνουν Resolved ακολουθώντας την παρακάτω σύνταξη:
{state value}: #IDΣτο παρακάτω παράδειγμα τα Working Items #300 και #301 θα τεθούν σε Resolved state όταν το pull request γίνει Completed απο τους reviewers.
Closed state
Ως 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
External links
Last updated