Skip to main content
Stop Bugs Found During Testing

This simple Jira Workflow can be used to enforce your teams triage process for bugs found during user story testing

Alan Parkinson avatar
Written by Alan Parkinson
Updated over 3 years ago

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

Did this answer your question?