Updated November 2022.
Many teams across many industries have come to use Jira for tracking issues, tasks, and other work items. Jira enables teams to plan, track projects, release software, generate reports, and automate processes. The project management tool also integrates with many test management tools for a more seamless quality assurance process.
Although Jira has become the industry standard for project management software among Agile teams, like most complex tools, one size does not always fit all. Jira can also be tricky to work with if you work on the testing or QA team. In this post, we aim to cover common Jira problems that QA teams face, the biggest complaints teams have about Jira, and what you can do to address them.
How to search for issues in Jira
“I can’t find anything in Jira!”
Every bug and every great idea your team has is logged somewhere in Jira, but no one knows how to find them — it’s a legitimate complaint. Between sprint boards, backlogs, projects, and roadmaps, there are many places where issues can hide. However, there are some solutions.
Finding work items in Jira starts outside of Jira
Step 1: Establish common terms and language.
Your team needs to agree on the words they’ll use to describe the work you do. If you call the new feature the “onboarding widget” and I call it the “new user flow,” both may be accurate. However, using different terms is inefficient, our team is likely to get confused, and the conflicting terminology will make it difficult to find, analyze, and organize work. A common language provides clarity throughout the project and will improve communication, collaboration, and organization.
Step 2: Make issues easy to find.
It would be best if you defined your work using unique and searchable terms. “Onboarding” is going to be a more concise term to look for later, whereas “flow” and “user” might get used in several places — making your searches confusing and inefficient.
The team should also agree on the definitions for items like the status field in Jira, so that the search criteria and filters for all project aspects are effective and use a common language just like titles and keywords. For example, what is your team’s definition of “done” for a status of “RESOLVED”? If different team members define “RESOLVED” in different ways, you can imagine how quickly your project management would fall into disarray.
Step 3: Use key terms in the titles of your work items.
Try to begin the name of every item you log with a term universally understood by the team. This term will indicate specific features or areas of the code that allow you to search and sort based on a set of meaningful terms for the team.
For example, a team working on a new address form feature might start all of their Jira items with something like “[address],” “(address),” or “Address -.” Whether you use square brackets, parenthesis, or a dash to distinguish this key term from the rest of the title does not matter as long as the team uses the same format consistently.
Remember, your team needs to be able to access information without your help. If you use language that is only meaningful to you, then:
- No one else can search effectively, and your work may be lost
- Work that should be grouped together might get missed when someone else searches for it
- You become a bottleneck because you’re the only one who can ever find anything!
Step 4: Know how to search Jira
There’s more than one way to conduct a search in Jira, and it’s important to know which is the best method for your needs. Jira has powerful advanced search options that utilize its own Jira Query Language (JQL) — but for our purposes, we’re going to be focusing on more basic searches. Most QA team members will be able to find what they need in Jira using a general quick search, an issue search, or a board search.
- A Jira quick search searches issues, boards, projects, queues, recent items, and more — across all Jira items that you has access to. This is the broadest way to search within Jira.
- A Jira issue search allows users to filter and search all of the issues within a single project, including issues that you’ve marked as “done” in the past. You can also utilize Advanced Search to search and filter issues across multiple projects.
- A Jira board search searches or filters only within the selected board. This is a useful way for you to quickly find timely issues — for example, work assigned to them during the current sprint.
How to create labels in Jira
Besides establishing meaningful terms and categories for your work, you can use issue fields like labels to add more contextual information to your issues and make them easier to find later. You can use as many labels as you want on a ticket. Once you have some stored, they show up as you start typing, so it’s easy to reuse them.
These labels can be product-related or engineering-focused. On your team, any given ticket might have the labels “buy flow,” “fees,” “order history,” or “customer reported.” These may seem generic, but each term has meaning to the team and points to specific pages, functionality, and visibility.
Once you label everything, you can build better queries. You can search for all “buy flow” tickets and add “customer reported” to that list. Keep an organized spreadsheet of your labels so that your team knows what each term means. Set expectations that everyone contributes so that there’s a common agreement on the same language to describe the team’s work. This kind of documentation can seem unwieldy, especially for new team members — so be sure to add a reminder to your onboarding checklist to walk through how the team uses Jira and where to find the common terms everyone uses.
How to manage Jira tickets
“The backlog is a mess!”
It’s easy to create a chaotic pile of tickets that turns into a never-ending backlog of issues. Worse yet, duplicate items are entered and start adding to the mess. It becomes challenging to get anything done, and at that point, the system begins to break down. Implementing a prescribed process to filter, sort, and focus your backlog items is the answer.
Jira Epics
Epics are great for organizing, but they’re not just a label. The epic helps you manage smaller tasks that are part of a larger deliverable or milestone. Depending on the type of Jira project you’re using, you can set the epic tag to show up in the backlog, which helps you quickly identify items that belong together. Although no team plans to have hundreds of items in the project backlog, for many, it inevitably happens. When you create epics, you help your teammates spot any tickets that might be evaluated together.
Another helpful feature of an epic is that all the linked issues display in a filtered list. You can quickly scan through that list, see the status of everything, and add a description that explains the goals and purpose of that group of tickets.
If you have the roadmap feature enabled on your Jira project, you can also view and plan Epics in a Gantt chart-style “roadmap view,” allowing you to see deadlines, dependencies, and team capacity at a glance.
An example of how one team member’s Jira tickets are falling across Q3 sprints
Sprints
Sprints are another way to plan work and provide a focus for the team using time-boxing to complete a set amount of work. Common sprint timeframes are two weeks, one week, or one month, with the goal being for the team to assign themselves no more than the work they can complete within that sprint timeframe, commit to finishing that work within the allotted time, and reject any other projects that come up along the way. When assigning work to a sprint, you can view tickets on a kanban board with custom status columns, and suddenly progress becomes obvious. If you’re working on an Agile team and using Jira, this is likely your team’s main view.
An active sprint in Jira (Image via atlassian.com)
Here’s another hint for those who can’t find anything in Jira (including the sprint board): If your team has a dedicated Slack channel for the current project, try setting the channel topic as the link to the Jira sprint board.
Creating a Jira permission scheme
“I can’t change that field!”
One of the hardest decisions an administrator faces when setting up a tool for a team is what powers you grant to each user. Jira allows granular options for permissions and access. You can trust widely and keep everything as open as possible, or you can restrict everything down to just the permissions someone needs for their role.
It’s easy to understand why having access to too much could be distracting and potentially dangerous. However, when working on collaborative teams, it’s important to train and trust. It can be frustrating to a team member to learn that Jira administrators can do all kinds of things that make their jobs easier, and they can’t.
Admins should leave certain options open for their team and take advantage of some Jira abilities to make things easier.
Bulk update Jira tickets
Bulk updating is a powerful feature that some teams restrict. You might be tempted to restrict this because someone once updated a bunch of tickets incorrectly, or you might feel strongly that developers and testers should be adding comments to provide some information every time they interact with a ticket. But even the most detailed teams need shortcuts sometimes.
For example, status is a common field that everyone on the team needs to update — and often on several tickets at once. Perhaps it’s a bunch of tickets that are deployed to a staging environment and ready to test. It may be that you want to split apart an existing epic or add a new label to several tickets. Whatever the reason, teams need to be able to move quickly. The more administrative work you require, the more people will feel frustrated with the tool.
Moving issues in Jira
Everyone on the team needs to be able to move issues. In Jira, this means changing the project designation or the issue type. Most QA teams have different workflows for different issue types, so you need to offer your team the flexibility to change any logged issue to fit the work required.
A common example is a subtask created in a user story. Once the developer digs into a subtask, they learn more about the work. Sometimes what looked like a simple task turns out to be more complex than originally expected. In cases like this, it may make sense to break out this task into its own story instead.
Moreover, if you want your team to track their work and close out stories at the end of a sprint, then you have to allow them to modify tickets.
Create a Jira status workflow
The status of an issue in Jira can be incredibly valuable in understanding what work has been done and what work needs to come next.
Create a basic workflow that utilizes common statuses, like To Do, In Progress, Code Review, Testing, Ready for Deploy, and Done. These may vary depending on your environment but most tickets move predictably through these different stages. Work with your QA team to build a column flow that’s simple enough to be completed reliably, but also provides enough insight into the testing process to provide needed visibility. Ideally, the tool is smart enough to suggest the next step in the flow for you.
An example Jira status workflow
Problems arise when you want to do anything that doesn’t nicely adhere to the desired flow. This happens in all kinds of ways. You may have a developer who falls behind on updating tickets. The ticket stays in the To Do status even though it’s already been completed and it’s in code review. If you require that the ticket move through each step, you just have more administrative overhead to keep things up to date.
Forcing someone to adhere to a specific flow doesn’t fix process and communication problems. Ask yourself, is it more important that the work is complete or if the board is up to date? If the team agrees that proper status on the board is vital, then discuss why — and decide on a strategy for moving the workflow along without bogging anyone down with administrative work that may not be mission-critical.
Sometimes the work changes after you get started. Steps that you previously imagined necessary end up being optional to complete the work. Or, what you thought might need three separate user stories gets done in one and now you’re moving three tickets forward for one ticket’s progress.
You can set up Jira to suggest the next step but allow the user to pick any status for the times you just need to skip a step or even backtrack.
Capturing data in Jira ticket fields
“What do I really need to include in my Jira ticket?”
When creating a new Jira ticket, you can provide a template of suggested information or create custom fields to capture all the data you want. Ask for everything important to you, but don’t require anything beyond the most basic pieces. Some basic fields you require might be project, issue type, title, and description. That isn’t enough information in most cases, but it is enough to get started.
Often, team members are logging notes about an issue they discovered while they were in the middle of something else. Make it easy for someone to record their thoughts quickly and come back when they have more time. Besides, not every work item that gets logged will require every field that you could possibly want.
Some commonly used Jira fields in software development are:
- Release version
- Fix version
- Components
- Severity
- Priority
- Labels
- Estimate
- Platform
- Environment
Custom Jira Fields
For ticket information that requires more space or complexity than the detail fields allow, such as acceptance criteria, you can also add additional custom description fields to allow free-text entry. This empowers your developers to provide additional clarity and context to your QA team around the goals of their testing! Acceptance criteria should proactively clear up any confusion for your testing team around what to test, where to test, and what the user story should be doing.
Adding an “Acceptance Criteria” description field in a new Jira task
You may be tempted to require specific fields or specific parts of the workflow in order to address process or staff problems. If you have a staff member who regularly doesn’t report enough information in the items that they log, that’s not going to change just because you add additional fields or provide a template. It is far more compelling to explain to that team member why you need that information and how it helps the team than to force them into a workflow that will require it.
Ultimately, the tool is there to enhance team communication. Jira is not a replacement for standups, questions, discussions, and constructive feedback!
Link bugs to Jira stories
Whenever logging a bug in Jira, it’s vital to tie it to the issue that you were testing when the bug was discovered. You can do this by either linking the two issues or creating bugs as a child issue under the original parent story.
Creating bugs as new Jira issues and linking them to the story that was being tested when the bug was found is a common way to approach this. If that sounds like a lot of administrative work, then an integration with your testing platform might help. For example, the TestRail Jira integration that we’ll talk about in the next section has built-in support for issue linking, which will automatically link the bug issue and parent story and upload all relevant testing data to Jira when you push defects from TestRail.
An example of TestRail test cases linked to a Jira story
Some teams prefer to add bugs/defects as a child issue under the original story, which accomplishes the same goals — but keep in mind that if you link your bugs this way, you’ll be unable to close the parent story without resolving the child bug issues.
Both methods are perfectly valid — it’s just a matter of choosing which one is the best for your team and using it consistently. Getting into the practice of consistently linking issues and using references between Jira and your test management tool will also allow you to quickly run reports to check the status of test cases associated with Jira stories at-a-glance. Additionally, good linking and reference hygiene prevents versioning confusion and ensures all tests are being run on the correct version of your software.
Integrate Jira with your tech stack
“Why do I have to post the same information in so many places?”
If you’re regularly using tools that have integrations with Jira, explore those. Integrations help you to connect information from various systems you use so you don’t need to update everything everywhere. Here are a few tools your team may be using alongside Jira.
Slack Jira Integration
This integration allows you to set certain projects to update in different project channels. This way, when anyone types a ticket number in Slack, the link to the corresponding Jira ticket follows. This makes it easy to collaborate with others on any given ticket so team members can find and follow up on any issue that makes it into a Slack discussion.
GitHub Jira Integration
Integrating Jira with your GitHub code allows you to reduce administrative overhead and increase visibility by linking Jira tickets with GitHub organizations and repositories. When all relevant Jira information is displayed in GitHub and vice versa, your whole team can see all of the latest updates and info at-a-glance without having to leave their primary platform.
GitLab Jira Integration
Jira can also integrate with your GitLab code repositories. This way, if a developer mentions a Jira issue in a commit, links will post automatically in the ticket. At the very least this shows that work has been done on an item. Utilized properly, the corresponding link will provide additional context about the changes.
Zendesk Jira Integration
If your customer service team uses Zendesk to track support issues, you can also set up a Jira integration to link any Zendesk tickets to a related Jira item. This allows the engineering team to more accurately determine impact based on how many tickets are linked. It also empowers the support team to follow the links and review the comments and status of the Jira ticket in order to observe progress that has been made toward a fix.
TestRail Jira Integration
The TestRail integration for Jira provides a two-way sync between issues in Jira (bugs and requirements) and tests in TestRail so that you can build traceability, identify coverage gaps, and streamline processes using the tools that already work for your team’s unique workflows. This integration allows you to fully track traceability between your requirements in Jira and your test executions in TestRail and generate insightful reports at all stages of testing.
The TestRail-Jira integration allows you to connect Jira tickets and TestRail test cases for synchronized visibility from both platforms
Jira tickets can be updated directly from TestRail, reducing admin work
For a real-world example of how this integration helps teams improve visibility and prioritization, check out this case study from OSIV, a Swiss government healthcare system.
Communicate Clearly and Empower Everyone
The goal for Jira is to have actionable information that enables your team to get work done.
Work with your team to develop a common language, use that for everything that you log in to Jira, and then use those terms to create more powerful searches. Group the work in a way that makes sense for the team, allow your team to change the way the work is tracked and integrate with your other tools as much as possible to minimize redundant work.
These suggestions can lessen frustration with Jira as a tool, help your team track information better, and empower everyone working on a project together to share important information and updates with the team at large.
Like in all collaborative systems, you want to make sure you spend your time on what is most valuable to your end goals. Always remember to ask yourself: Is it merely interesting, or is it actionable? Let go of what you no longer need. And don’t force a tool into the job of fixing your processes and communication!
