As part of your teams 'definition of done' for user stories there will be a section on conducting through testing and fixing bugs that are found. Fixing the bugs that were found can be a tricky topic as it's usually the products owners or the teams responsibility to triage the found bugs for each user story and decide which ones need fixing. Any bugs that won't be fixed as part of the story are placed on the backlog.
While Behave Pro provides traceability functionality to track the relationships between user stories and bugs found during test sessions, it can still be possible for stray bugs to miss your teams triage process. You can setup the following workflow in Jira to enforce bugs that are reported during testing of user story are triaged before the user story can be completed or closed.
A feature of Jira’s workflow functionality is the ability to enforce the rule that an Issue cannot be transitioned (e.g. closed) while it has open sub-tasks. By enabling this rule on your projects workflow and reporting defects found during testing as a sub-task of the user story under test, you can enforce that the triage process is followed.
For the sake of clarity to users, it's best to have a dedicated sub-task issue type for reporting bugs, we recommend using 'defect or 'bug' in the name of the new issue type e.g. 'Story defect' or 'Story bug'. Behave Pro is smart, if you follow this naming convention for the sub-task issue type, it will automatically use it when reporting a defect from a test session so users don't have to remember to switch issue types.
The workflow from the users perspective
Let's consider an example, a user story with two defects found during testing and reported using the 'defect' sub-task. If the developer tries to close the user story, it won't close because it has open sub-tasks from the defects. This forces actions to be taken, the developer talks to the product owner and tester to triage the found defects.
For the first defect the product owner decides it is a major increase in story scope and should be placed on the backlog as there is little impact to the value delivered. To do this the product owner converts the 'defect' issue from a sub-task to a full Issue with appropriate type for bugs in your backlog. This means the user story only has one sub-task remaining.
For the second defect the product owner feels it is important to the story and must be fixed before the user story can be considered 'done'. The defects sub-task is simply assigned to the developer who updates and transitions (e.g. Closed) the sub-task when the fix has been implemented. Now this second sub-task has been closed the developer will be able to close the user story and it can be considered 'done'.
Whatever happens this simple workflow implementation enforces a decision to be made, and Jira captures a full audit trail of the process.
Configuring the workflow in Jira
To configure this way of working in Jira you need to make two simple changes
Add the "All sub-tasks must have one of the following statuses to allow parent issue transition" condition to the 'close' transitions in your projects workflow
Create a sub-task issue type to represent the defect and add it to your projects issue type scheme
Adding the workflow condition
Open the 'Cog menu icon' and choose Issues . Select Workflows to open the Workflow page.
Find the workflow your projects uses and select edit from the actions column
Find the transition you want to enforce the rule on and open it
Open the Conditions tab and review the existing conditions. If no rule for “All sub-tasks must have one of the following statuses to allow parent issue transition” exists click Add condition
Select Sub-Task Blocking Condition and click Add. On the next page select the status the sub-task must be in before the parent issue will successfully transition and click Add
You workflow modifications will currently be in a draft form and you will need to select Publish before they take effect on your project
Creating a new Sub-Task issue type
Open the 'Cog menu icon' and choose Issues . Select Issue Types to open the Issue Types page.
Click Add issue type button to open the Add Issue Type dialog box.
Add a appropriate name (e.g. Story defect) and select Sub-Task Issue Type before clicking the Add button
This will create the new sub-task issue type but it won't be available in your project until you add it to the correct Issue type scheme.
Choose Issue type schemes from the left hand navigation.
Find the Issue type scheme associated with your project and click edit from the action column
Find your sub-task under Available Issue Types and drag it across to Issue Types for Current Scheme. Then click save
Congratulations, you've configured the full workflow