When we talk about testing and QA, finding bugs is part of the job.
Once you get going and do this for a while, you figure out that knowing exactly when something is ready to be tested again can be a real challenge sometimes.
You have a team of different developers, a ticketing system, defect tickets that are linked to the ticket of the SUT (subject under test) and way more. And you should all check this on a daily basis, just to see if you can start testing again....annoying right?.
This blog post gives you a solution to easily solve this problem. With this approach, you end up with a list of tickets that are done and can be retested in your next session - no more searching through dozens of tickets.
But let me first explain the workflow we use in our team, so you can see how this fits in for you and your organization.
The Jira and QA
In our team, Jira is the heart of our workflow. We run a classic Kanban setup, where features move from In Doing into Internal QA and, hopefully, all the way to Done. Once a ticket lands in "Internal QA", our testers get to work – often using TestRail to manage and document test runs in a more structured way.
When we find defects, we log them as separate Defect Tickets in Jira – usually pushed straight from TestRail. These tickets link back to the actual feature-ticket using a “blocks” relationship. That’s the Jira’s way of saying: You can’t move your feature-ticket forward until this is fixed.
Of course, this process works just as well without TestRail. But if you’re curious about how we use it to organize and speed up our testing, you might enjoy this article: Automate your tests with Cypress and TestRail
The Problem
As testing continues, the number of defects naturally grows. Each bug gets its own ticket, each one linked to its original feature. Over time, you end up with a mountain of features that are stuck in QA because they’re still blocked by unresolved bugs.
To keep things tidy, we introduced a dedicated Jira status: Waiting for Retest. Whenever a feature is blocked by one or more defects, we move it from "Internal QA" to "Waiting for Retest". This way, it’s easy to tell which features are brand-new to be tested, and which ones are simply waiting for fixes.
It sounds neat – and it does help – but it’s not perfect. The "Waiting for Retest" list can still grow long, and not all tickets in it will become testable at the same time. Some already have all their bugs fixed, others are still waiting. And the only way to find out? Manually open each ticket and check the linked issues.
That’s the bottleneck: Even with this extra status, you still end up clicking through dozens of tickets just to discover which ones you can actually retest.
This is a tedious task that eats up valuable time and energy.
The Solution
Let's find a solution that helps us quickly identify which tickets are ready for retesting, without the need to manually check each one.
Here’s where Jira’s built-in automation comes to the rescue – no plugins required.
What we need to do is to create a rule that automatically labels tickets based on their linked defects. Whenever a defect ticket transitions to a "Done" status (whatever this may be for you), Jira checks the actual feature it blocks. If all of its linked defects in that feature-ticket are resolved, the automation adds a label: QA_RETEST_READY. If a new defect is linked later, the label is removed again.
Why this helps?
Now, instead of clicking into each ticket, I simply watch out for the QA_RETEST_READY label in my prepared filter-view in Jira. If it says it's ready, I know it’s good to go. If not, I can skip it. That means I can focus on actual testing – not ticket housekeeping.
The Automation
Let's check out the actual automation rule. First, please keep in mind, that you would need to have multiple rules to make it "perfect". Because you need different triggers such as, if a ticket is created, updated, transitioned, relinked, unlicked or deleted. To make it easier for me, I have just 2 rules with the same content - one with the trigger "Issue transitioned" that is executed during the day, when development happens. The other rule is triggered by a scheduled time in the morning, and acts as some kind of "repair" for the label, in case any other events have happened, like deleting tickets and more.
We start with a trigger in our rule. For me, this is either a scheduled time or a multi-trigger with work item updated and work item transitioned.
Then we create a branch that acts as a loop through our linked issues. We specify the Linked work items and the link type blocks. So if we update a defect ticket, this branch brings us to the actual feature ticket. Then we add a JQÖ condition to check the linked defect issues of our current feature ticket within our branch. Here is the sample query that searches all open defects, please adjust it to your needs:
issue in linkedIssues("{{issue.key}}", "is blocked by") AND status NOT IN (DONE, DECLINED, INTERNAL_QA)As a condition you can define less than 0 to check if there are no open defects. In this case we add an action afterwards to update the issue label. When setting the QA_RETEST_READY label, make sure to use the option to only add it to the ticket, to avoid removing existing labels.
Below the current branch, we add another branch where we do almost the same thing. But in this branch, we check if we have more than 0 open defects. In this case, we just remove the label QA_RETEST_READY again.
Conclusion
With this simple automation, you can easily keep track of which tickets are ready for retesting. It saves you from the hassle of manually checking each ticket and helps you focus on what really matters: testing and improving your product.
If you have a similar workflow, I highly recommend setting up this automation. If you have any questions or need help with the setup, feel free to reach out.
Links:
