When starting a new software development project, many companies choose to use Jira as their project tracking tool. If you’re reading this, chances are you’re familiar with it. While Jira can be a helpful tool for tracking progress, it’s beneficial to have best practices in place to pack the most punch. Find out how to optimize your Jira QA workflow below.

Jira QA Workflow

Jira board column types aren’t a one-size-fits-all approach. Different teams might find that different conventions work for them. (To learn more, see our article on the Agile QA process.) However, the options below show the typical range of columns followed in almost any Jira testing workflow.

Here are some examples of Jira columns:

Group 1 – the “All the Columns!” Approach

Backlog / Ready for Development / In Progress / Ready for Staging / Ready for Testing / In Testing / Reopened / Ready for Production / On Production / Testing on Production / Done

Group 2 – the Basic Approach

New / In Progress / Ready for Testing / Done

As long as each column serves an effective purpose, it’s often helpful to lean towards the side of more columns. The more specific each column is, the easier it is for anyone on the team to immediately get a high-level status report with a quick glance at the Kanban board.

If you compare the groups above, you can see how the options in Group 1 provide a much clearer view into how far along a task is, versus the more bare bones approach of Group 2.

While it may seem overwhelming, it’s helpful to remember that tickets can be moved between columns with a quick drag of the mouse. As long as the team is disciplined about updating ticket statuses, detailed columns can be a huge asset to your Jira QA process.

Jira Ticket Fields

As with workflows, needs relating to Jira ticket fields can vary greatly from project to project. However, every project should ideally have the following ticket fields at minimum:

• Summary (for entering the ticket title)
• Description (for including specifics such as steps to reproduce, and a more detailed breakdown of the feature or bug)
• Issue Type (bug, feature, story, epic, etc. Typically a project manager creates features, stories, and epics, while QA creates bug report tickets)
• Assignee (a project manager or other front line reviewer can be the default Jira assignee if need be)
• Priority (low, medium, high, critical, blocker)
• Labels (this field allows for easy, custom grouping of tickets)
• Environment (for example dev, staging, or production, and the specific device model, OS, and/or browser the bug was identified on. Learn more in our guide to cross browser testing)

Additionally, if the product being tested involves a mobile app or other type of versioned software, there should be fields for Version (for example, 1.52) and Component (for example iOS, Android, Web, or API).

It can be tempting to create as many custom fields as possible. But it’s good to keep in mind that requiring too many can significantly slow down the Jira QA process. When it comes to “feature” tickets, a project or product manager usually won’t have to create dozens at a time. But for QA, ticket creation is a different ball game.

During a major round of regression testing, it’s not unheard of for QA to create 20+ bug tickets in a day. When someone has to pause and think about what to put for unnecessary or extraneous fields, the extra time and distraction end up reducing productivity. Finding that balance between having enough fields to be detailed/helpful without going overboard is key.

Bug Priorities

Encouraging QA to set the initial priority for a bug can be beneficial for the whole team. After all, QA testers specialize in user experience. As a result, they’ll often be your best bet on estimating how significant a bug will be to your customers/users. (Not sure how to go about prioritizing? Check out our guide: How to Prioritize Bug Fixes.)

Of course, with overall business goals in mind, a product manager might later change the priority. But having that initial filter as a guide can help team members at all levels review important bugs faster. QA might not always be 100% aligned with the product manager. But chances are high that a ticket QA labels a showstopper will be important to review as soon as possible.

Jira Backlog Grooming

If Urban Dictionary had a “tech” section, the definition for “backlog” would probably be something like:

A black hole in which non-urgent tickets disappear for eternity

But it doesn’t have to be this way! The Agile phrase “backlog grooming” might conjure up an image of a long, boring call or meeting in which little gets done. But if a team makes a habit of tending to the backlog regularly, the process can be painless — and even pretty satisfying.

Typically, a company’s Jira backlog mainly consists of bug tickets deemed “medium” or lower. While it’s easy to feel like minor issues don’t always need to be dealt with, they can really add up. “Death by a thousand paper cuts” can drive users away just as much as one major bug.

So what do you do if you have an ever-growing backlog of tickets that never seem to make it into a sprint? Luckily, there are several remedies:

1. Have periodic sprints dedicated to backlog bugs. You don’t need to do this every month — it can be nerve-wracking to imagine putting other priorities on hold. But if it’s been six months since the team last made a dent in the backlog, it might be time to consider it.
2. Commit to pulling in at least two backlog bugs every sprint, even if they’re small. This might not keep your overall backlog ticket number down. After all, QA might add more than two new backlog bugs during a sprint. But at least you’ll have momentum, and the process of deciding which tickets to pull in will help ensure that nothing in the backlog is ever completely forgotten. It’s also less tedious to have more frequent — but shorter — backlog grooming sessions.

Jira Estimates

Most teams will have developers provide Jira estimates (either in the form of rough hours or story points). However, it’s common for QA to be left out of the shuffle. Some testers might rejoice at this, as being asked to provide estimates can be daunting. But the alternative is usually a non-QA person making often inaccurate assumptions about the time QA will need.

By asking QA to weigh in with estimates, project managers can make sure that the sprint scope and timeline aren’t at risk. At the very least, it’s a good idea to run your assumptions by the QA team. If Marketing has started promoting a launch date for a feature that ends up being late, the company will look much worse than if they pushed the launch date by a few days before the announcement. (Not sure where to start when asked to provide an estimate? See our guide: QA Testing Estimation Techniques.)

Automated Testing and Jira

For automated tests to be effective, the scripts need to be written on completed features. If QA creates automation for a feature that is still in progress, many (if not all) aspects will need to be updated later. Because of this, one of the most productive ways to implement automated testing is to have the automator work on tickets one sprint out. That is, to automate completed tickets from the previous sprint.

When an Agile scrum team uses this strategy, managing the automation progress can sound difficult at first. How will the team keep track of the automator’s progress if the tickets aren’t in the current sprint? By following some simple rules, the process can actually be even more efficient.

Prior to a Sprint Planning meeting, the automation tester(s) can create Jira tickets based on the previous sprint’s features. To avoid confusion from other team members, they can simply label these as Automation tickets. Once these cards are added to the sprint, the Jira workflow is exactly the same as a developer’s.

As an additional benefit, this process also allows manual and automated QA to test the same features without stepping on each other’s toes. It’s even better if the manual QA tester(s) had time to write test cases during the previous sprint. In that case, the automator can also save time by using the test cases as a guide of what to automate.

Jira Comments

The comments section of a Jira ticket is the stuff of legends. Okay, that might be going a little far. But a team’s commenting process can make or break their Jira experience. Relevant, detailed ticket comments can be extremely helpful for QA to review when the feature is ready for testing. But there are a few best practices to keep in mind:

If the comment isn’t going to clearly help anyone down the workflow, discuss it elsewhere.

When a testing timeline is tight (which is usually the case!), a QA Engineer having to read through 100+ comments is going to take time that just isn’t there. Instead, it’s a good idea to use email, Slack, or any other platform to discuss tentative details of a feature. Then you can come back and update the ticket description with the final requirements.

Tag!

If you’re adding a comment with important details about a ticket, it’s important to tag the QA tester(s) in the comment. This is true even if the ticket isn’t ready for QA yet. It will help them prepare for testing it properly, or enable them to bring up potential issues with the approach. QA might have even started writing test cases already, so having early access to additional info can be a game-changer.

Decide on an order, and stick to it.

Some teams prefer to have Jira comments set to display in ascending order. Others are #TeamDescending (a hashtag that probably won’t be trending on Twitter anytime soon). Whichever choice you make, be sure the entire team is aware. This may sound minor, but it can have a real impact. It’s very easy to see a list of comments and assume the most recent are at the top (or vice-verse). Acting on the wrong assumption can result in QA testing based on out of date information.

Decide as a team whether it’s okay for QA to reopen a feature ticket with a comment detailing a bug.

The alternative to this is having bugs go in separate tickets 100% of the time. Being able to add a comment with bug details saves time. But bugs can get lost in the shuffle this way. Additionally, if the developer’s fix attempt isn’t successful – or if there are multiple bugs – the list of back and forth comments can quickly become unwieldy.

Jira Sub-Tasks

Sub-tasks are another area where everyone has their own approach. When a bug is related to a feature ticket, some teams have a rule of using sub-tasks. For example, if QA tested a profile section and found that the name field was broken, they might create this bug ticket as a sub-task under the profile feature ticket. In theory, this makes perfect sense. But in practice, it can result in a less Agile Jira process for the following reasons:

• When a product/project manager reviews the main board, sub-tasks are not always clearly visible.
• Sometimes the business will decide to publish the feature, even with some minor bugs. In this situation, Jira users will want the ability to mark the feature ticket as “Done” and track the related bugs separately.

On the other hand, if a bug is related to a feature, you’ll want to make sure that it’s easy to track the association. The easy solution for this is to create separate bug tickets, but mark them as “Linked,” “Caused By,” or any form of Jira relation to the feature ticket. That way you’ll still be able to see a list of relevant bugs from the feature ticket – without negatively affecting board views/usability as a whole.

Assigning Jira Tickets

Assigning tickets is easy in and of itself. But everyone slips up now and then. Here are some of the assignee issues that tend to come up, with potential solutions:

• Developers being unsure who to assign a ticket to when there are multiple QA testers. This can be solved in several ways. The first is to have a go-to assignee in this situation. This could either be a QA lead, who will decide how to split up the work, or a project manager. (If there’s a QA manager, that’s another great option.) An alternative is to assign the ticket to one person, but tag the other(s) in a ticket comment.
• QA testers being unsure of which developer to assign bug tickets to. This is generally an issue during the early stages of a project, or when there are multiple developers within the same component (for example, three Android developers). If the issue is that QA (or a developer) is new to the project, the solution is to provide a centrally located list of team members and their roles. If the issue is having multiple developers in the same area, this can be solved in the same manner as the issue above — having a go-to assignee who will vet the ticket further. This could either be a project manager, or the lead developer.
• Team members changing the status of a ticket (ie: from “In Progress” to “Ready for Testing”) without updating the assignee. The relevant person might notice the Kanban board update eventually. But they’ll be able to start work much more quickly if they receive the assignee email notification. Everyone makes mistakes, but the solution here is to consistently remind anyone who slips up.

Another best practice is to add QA to the “Watchers” list for any relevant ticket. That way they will see updates even if someone forgets to update a tag or assignee.

Optimizing Jira for QA

Jira can feel unnecessarily complicated when you first get started, no matter what role you’re in. But if you optimize your Jira testing workflow and follow these best practices, you’ll be setting the stage for a more efficient process, happier teams, and a better end product.

Take Your Jira QA Process to the Next Level

Need consulting for your QA process? Check out our on-demand QA testing services. We also do Agile consulting, and can help optimize your Jira QA process.