Skip to content

If you work in software engineering, you probably spend a lot of time inside Jira Software by Atlassian.

And if your team doesn’t use filters effectively, Jira can quickly feel overwhelming.

  • Too many issues.
  • Too many statuses.
  • Too much scrolling.
  • Not enough clarity.

The solution? Smart filters.

Jira filters (using JQL — Jira Query Language) allow you to instantly find exactly what you need. When used properly, they:

  • Reduce noise
  • Improve focus
  • Simplify sprint tracking
  • Support better reporting
  • Save time during meetings

Below you’ll find 10 essential filters every QA should use, not just for bugs — but for all QA-related work.

1️⃣ All Work Assigned to You (QA View)

Depending on which field is used for holding the assigned QA’s name/user id, usually it is the default assignee field, but some teams also implement custom fields to differentiate between the development assignee and the QA assignee. If your team uses a custom field, just replace assignee from the example below with your custom field. JQL queries also work with auto-complete, so don’t be shy to use it.

JQL query: assignee = currentUser()

Please keep in mind that currentUser() is a Jira function that will change the assignee’s value dynamically according to the user’s account accessing the filter. If you want to ensure that it holds your username when you share the filter to other team-members, replace it with your own name and select the account from the list that appears on auto-complete.

This is your daily starting point.
It shows:

  • Bugs
  • Tasks
  • Stories
  • Any issue assigned to you

Why it matters:
It creates a clear focus list and prevents context switching.

2️⃣Bugs Created in the Current Sprint

Usually, teams report defects in 2 different phases – pre-release and post-release. The pre-release phase is the moment when development on a ticket has concluded and the QA team is checking the acceptance criteria. In Jira, the default work type for this is the Bug work item type, but some teams can also create other work item types if they feel fit to differentiate between production bugs and development bugs.

It is important to keep track of remaining defects within the timeframe of a sprint to ensure that there is no risk in delivering the expected features. Below you will find an example, that filters Jira work items by type = Bug and looks within open sprints (so it will ignore past sprints or future sprints). There are also cases of multiple teams using the same Jira instance – which results in multiple openSprints(), so feel free to add more specificity to your results by adding filters on fields such as team, or even ensure you are filtering out production bugs – depending on how your team handles that, select a different issue type or add filter by label etc.

JQL example: issuetype = Bug AND sprint in openSprints()

Jira is rolling out a new change replacing references to issue with work so an alternative to the above query would be: worktype = Bug AND sprint in openSprints()

Why it’s useful:

  • Helps track sprint-related defects
  • Useful for daily QA checks
  • Keeps sprint visibility high
  • Great for teams practicing Agile.

3️⃣ Issues Ready for Testing

status = "Ready for testing"

Adjust status name to match your workflow and if you need to find the ones assigned to you already, add the criterion from the first example: status = "Ready for testing" AND assignee = currentUser()

Why it matters:
This becomes your active testing queue.

No confusion about what to test next.

4️⃣ High-Priority Issues

priority in (Critical, High) AND status != Done

You can adjust the status and priority to match the ones you need to filter by depending on your team’s needs.

It helps:

  • Highlight serious issues
  • Support release decisions
  • Assess risk involved
  • Focus on key-areas near production releases.

Why it matters:
Helps QA focus on risk areas during releases.

5️⃣ Active Sprint Items

The JQL example below will display all work items included in the current open sprint, or sprints if there are multiple teams on the same project. You can further filter it by team assigned to the work items, or even hardcode the sprint, however in the latter case you will need to create a new filter for each sprint, instead of reusing the same filter. As a QA, you might be interested in following only items in a specific status, so you could also adjust the query to include/exclude a specific status/list of statuses.

sprint in openSprints()

Why it matters:

  • Shows sprint scope
  • Helps during daily standups
  • Keeps testing aligned with sprint goals

6️⃣ All Unresolved Bugs

The following 2 examples cover both new terminology used by Jira (replacing issue with work) and the original terminology as well. It excludes any status assigned to the status category of Done. You can adjust it to check against a list or maybe look at the Resolution field if your team uses it and it’s mandatory.

worktype = Bug AND statusCategory != Done

issuetype = Bug AND statusCategory != Done

Why it’s useful:

  • Finds anything still open
  • Useful for reporting
  • Helps during sprint reviews
  • This filter is great for dashboards.

Why it matters?
This filter helps identify blockers in a timely manner and address its resolution with the team.

7️⃣ Regression Bugs

When the QA team is testing a release candidate in a pre-production environment, time is of the essence. So it makes a great difference to have a filter created for tracking regression defects in order to easily identify release blockers and delegate small fixes without impact to later release candidates. The entire team – engineers, QAs and product owner, should have access to this filter and make time-sensitive decisions.

Depending on how your team is differentiating between bugs found during the initial testing phase, and those found during regression, the JQL might suffer adjustments. Below I’ll provide a couple of examples based on a custom field, a label added on regression defects or by using Script Runner – a 3rd party app integration.

  1. JQL when the bug type is saved within a custom field – let’s call it Defect type: issueType = Bug AND statusCategory != Done AND defectType = "regression"
  2. JQL when the bug type is saved as a label on the bug: issueType = Bug AND statusCategory != Done AND labels IN ("regression")
    It is important to use the IN operator when it comes to labels because these can contain more than 1 value, so using IN will always pull the ticket into the results without risking to miss it.
  3. JQL inside ScriptRunner app. In order to use ScriptRunner, you need to use its dedicated section – ScriptRunner Enhanced Search, not the default Filters one from Jira.
    issueFunction in linkedIssuesOf("fixVersion = 'v1.0' ", "is blocked by") AND issueType = "Bug" AND statusCategory not in ("Done") and fixVersion IS EMPTY

    Let’s split this query piece by piece and understand what each bit does: issueFunction in linkedIssuesOf(“fixVersion = ‘v1.0’, “is blocked by”) will return the work items that block the work items which have fixVersion set to v1.0 and that have at least one linked work item with the relation of “is blocked by”. Then we filter those work items by issueType = Bug. Then it checks the statusCategory and excludes all bugs which are in a Done status category (this may contain more than 1 status such as Done, Closed, Resolved, Released etc.). And lastly, it ensures that it doesn’t have a fixVersion added to it.

Why it matters:
Regression testing and blockers becomes easy to track and manage.

It’s important to note that the filters presented as 1 and 2 would work only if the process is clear, and everyone is aware of it. Otherwise, imagine how many bugs would be returned as results if they are left as regression type (be it by label or custom field) upon a next release.

8️⃣ Bugs Reported by Current User

As a QA, you’ll probably report a fair share of defect and it may become difficult to keep track of all of them as some may be flagged as low priority and the development team will reach them later. So in order to track them and check their status, you may want to create a filter:

issueType = Bug AND reporter = currentUser()

You can opt in to exclude specific statuses or even filter by components, parent etc.

🧠 Why Filters Matter Beyond Productivity

Smart filtering isn’t just about convenience. It helps:

  • Reduce cognitive overload
  • Minimize unnecessary meetings
  • Improve transparency
  • Support Agile workflows
  • Create clearer accountability

When Jira is filtered properly, it becomes a structured workspace instead of a chaotic list. Moreover, everyone can use a saved filter to create their own or the team’s dashboard, which, in turn, transforms Jira into a visibility tool — not just a task tracker.

🎯 Final Thoughts

Mastering Jira filters is one of the fastest ways to become more effective in QA.

You don’t need to memorize everything about the tool. You just need to know how to:

  • Find what matters
  • Reduce noise
  • Stay focused
  • Track work clearly

Start with these 8 filters, adapt them to your workflow and to your needs, and build from there.