The ticket workflow is configured defined tickets status, tickets resolution and tickets transition.
Status
The keys tickets/bug status are new, assigned, closed, reopened, infoneeded, couldnotreproduced, testrequested.
1) New: When QA files new bug.
2) Assigned: ‘Assigned to’ field is set by project lead or manager and assigns bug to developer.
3) Could not reproduce: If developer is not able to reproduce the bug by the steps given in bug report by QA then developer can mark the bug as ‘CNR’. QA needs action to check if bug is reproduced and can assign to developer with detailed reproducing steps.
4) Need more information: If developer is not clear about the bug reproduce steps provided by QA to reproduce the bug, then he/she can mark it as “Need more information’. In this case QA needs to add detailed reproducing steps and assign bug back to dev for fix.
5) Test Request: The bug should be resolved, but the QA should test and confirm.
6) Reopen: If QA is not satisfy with the fix and if bug is still reproducible even after fix then QA can mark it as ‘Reopen’ so that developer can take appropriate action.
7) Closed: If bug is verified by the QA team and if the fix is ok and problem is solved then QA can mark bug as ‘Closed’.
Resolutions
The resolutions are the reason for why a ticket was closed. The keys bug/ticket resolutions are: fixed, invalid, wontfix, duplicate, worksforme, could not reproduce, deferred.
1) Deferred: If the bug is not related to current build or can not be fixed in this release or bug is not important to fix immediately then the project manager can set the bug status as deferred.
2) Fixed: When developer makes necessary code changes and verifies the changes then he/she can make bug status as ‘Fixed’ and the bug is passed to testing team.
3) Invalid: Some times developer or team lead can mark the bug as Rejected or invalid if the system is working according to specifications and bug is just due to some misinterpretation.
The bug's life cycle and transitions are showed in the follow figure:
The workflow is configured in the trac.ini file
[ticket-workflow]
; opensource-workflow.ini
; accept action
; When you accept a ticket, you get ownership of it. (You can't accept a
; ticket on someone else's behalf.)
accept = new,assigned,accepted -> accepted
accept.operations = set_owner_to_self
accept.permissions = TICKET_MODIFY
; assign, reassign, unassign actions
assign = new -> assigned
assign.operations = set_owner
assign.permissions = TICKET_MODIFY
reassign = assigned,accepted -> assigned
reassign.operations = set_owner
reassign.permissions = TICKET_MODIFY
; Allow correcting the ownership of a closed ticket.
change_owner = closed -> closed
change_owner.name = change ownership
change_owner.operations = set_owner
change_owner.permissions = TICKET_MODIFY
unassign = assigned,accepted -> new
unassign.operations = del_owner
unassign.permissions = TICKET_MODIFY
; leave actions
leave = * -> *
leave.operations = leave_status
leave.default = 1
; resolve actions
resolve = new,assigned,accepted,couldnotreproduced,testrequested -> closed
resolve.operations = set_resolution
resolve.permissions = TICKET_MODIFY
; reopen actions
reopen = closed -> new
reopen.operations = del_resolution
reopen.permissions = TICKET_CREATE
; request info actions
requestinfo = assigned,accepted,new -> infoneeded
requestinfo.name = need more information
requestinfo.permissions = TICKET_MODIFY
provideinfo = infoneeded,testrequested -> new
provideinfo.name = provide info
provideinfo.permissions = TICKET_MODIFY
provideinfo.default = 2
;could not reproduce
couldnotreproduce = assigned,accepted,new -> couldnotreproduced
couldnotreproduce.name = could not reproduce
couldnotreproduce.permissions = TICKET_MODIFY
detailedsteps= couldnotreproduced -> new
detailedsteps.name = detailed reproducing steps
detailedsteps.permissions = TICKET_MODIFY
detailedsteps.default = 2
;test request
testrequest = assigned,accepted,new -> testrequested
testrequest.name = test request
testrequest.permissions = TICKET_MODIFY
Nessun commento:
Posta un commento